Embed Size (px)
Citation preview
1
INSTITUTO POLITÉCNICO NACIONAL
UNIDAD PROFESIONAL INTERDISIPLINARIA DE INGENIERÍA Y
CIENCIAS SOCIALES Y ADMINISTRATIVAS
SECCIÓN DE ESTUDIOS DE POSGRADO E INVESTIGACIÓN
PATRONES ARQUITECTÓNICOS PARA PROGRAMACIÓN DISTRIBUIDA
T E S I S
PARA OBTENER EL GRADO DE MAESTRO EN CIENCIAS EN INFORMÁTICA
P R E S E N T A
MICHAEL ROJAS RODRÍGUEZ
DIRECTORES:
MC. ELIZABETH ACOSTA GONZAGA MC. JESÚS ANTONIO ALVAREZ CEDILLO
MEXICO, D.F. 2010
2
3
CARTA CESIÓN DE DERECHOS En la Ciudad de México D.F el día 26 el mes de Noviembre del año 2010, el que suscribe Michael
Rojas Rodríguez alumno del Programa de Maestría en Ciencias en Informática con número de
registro B081882, adscrito a la Sección de Estudios de Posgrado de la UPIICSA-IPN, manifiesta
que es autor intelectual del presente trabajo de Tesis bajo la dirección de la M. en C. Elizabeth
Acosta Gonzaga y el M. en C. Jesús Antonio Álvarez Cedillo y cede los derechos del trabajo
intitulado “Patrones Arquitectónicos Para Programación Distribuida”, al Instituto Politécnico
Nacional para su difusión, con fines académicos y de investigación.
Los usuarios de la información no deben reproducir el contenido textual, gráficas o datos del trabajo
sin el permiso expreso del autor y/o director del trabajo. Este puede ser obtenido escribiendo a la
siguiente dirección [email protected] Si el permiso se otorga, el usuario deberá dar el
agradecimiento correspondiente y citar la fuente del mismo.
INSTITUTO POLITÉCNICO NACIONAL
SECRETARÍA DE INVESTIGACIÓN Y POSGRADO
4
AGRADECIMIENTOS El principal agradecimiento es a mis padres quienes siempre me han apoyado y han
creído en mi en todo momento, siempre los tengo presentes y en verdad sin ellos no seria
la persona que ahora soy, todo el esfuerzo y motivación ellos me lo han otorgado. Muchas
gracias Papá y Mamá por sus sabios y sinceros consejos.
A mis hermanos Connie y Sergio quienes me guían y apoyan. Se que puedo contar con
ustedes siempre.
A mis profesores quienes con sus conocimientos, consejos y ayuda he podido lograr un
paso más en mi carrera profesional.
A mis directores, Maestra Elizabeth Acosta gracias por todo el apoyo y buenos y sabios
consejos que me ha dado. Maestro Jesús Álvarez, por la buena disposición y el apoyo en
todo momento.
Finalmente quiero agradecer a la vida, al destino y a Dios por darme la oportunidad de
concluir un paso mas en mi carrera profesional y por ponerme en mi camino siempre a
todas las personas que me han guiado.
Muchas Gracias
Michael Rojas Rodríguez
5
Índice
Resumen .............................................................................................................................. 12
Summary .............................................................................................................................. 13
Introducción .......................................................................................................................... 14
Planteamiento de la problemática ....................................................................................... 16
Objetivos .............................................................................................................................. 17
Justificación .......................................................................................................................... 18
Alcances ............................................................................................................................... 19
Resultados Esperados ......................................................................................................... 20
Limitaciones ......................................................................................................................... 20
Marco teórico ....................................................................................................................... 21
CAPITULO 1, Una visión esencial de la arquitectura de software y patrones .................... 24
Sistemas de información distribuidos ............................................................................... 25
Arquitectura de Software .................................................................................................. 31
Vistas Arquitectónicas....................................................................................................... 39
Patrones ............................................................................................................................ 42
Tipos de Patrones ............................................................................................................. 44
Patrones de diseño ........................................................................................................ 44
Patrones de creación ..................................................................................................... 46
Patrones estructurales ................................................................................................... 46
Patrones de comportamiento ......................................................................................... 47
Patrones arquitectónicos .................................................................................................. 49
El Futuro de los Patrones ................................................................................................. 51
Lenguajes de Descripción Arquitectónica (ADL’s) ........................................................... 54
Lenguaje Acme-Armi ..................................................................................................... 58
CAPITULO 2, Patrones Arquitectónicos desde perspectivas actuales ............................... 60
Patrón Arquitectónico Modelo Vista Controlador (MVC) .................................................. 61
Modelo (Model): ............................................................................................................. 61
Vista (View): ................................................................................................................... 61
Controlador (Controller): ................................................................................................ 62
Patrón Arquitectónico Broker ............................................................................................ 63
Objetivo del patrón Broker ............................................................................................. 64
6
Motivación ...................................................................................................................... 64
Usos Conocidos del patrón arquitectónico Broker ........................................................ 65
Características Benéficas del Patrón Arquitectónico Broker ......................................... 66
Patrón Arquitectónico Pipes and Filters ........................................................................... 67
Contexto ......................................................................................................................... 67
Motivación ...................................................................................................................... 67
Usos Conocidos ............................................................................................................. 68
CAPITULO 3. Propuesta de solución usando el Patrón Arquitectónico Piramidal y la
Arquitectura Piramidal de Sistemas Distribuidos ................................................................ 69
El Patrón Piramidal ........................................................................................................... 70
Características de Niveles ............................................................................................. 71
Flujo de Operación del Patrón Piramidal ....................................................................... 72
Características Generales ............................................................................................. 74
Ventajas del Patrón Piramidal ....................................................................................... 75
El Patrón Piramidal desde una perspectiva genérica .................................................... 77
Introducción al caso de estudio ........................................................................................ 78
Modelo Básico de Operación ......................................................................................... 78
Procesamiento de Medios de Pago Electrónicos .......................................................... 80
Problemática .................................................................................................................. 80
Explicación Técnica de la Problemática ........................................................................ 81
Propuesta de Solución a la problemática ...................................................................... 82
Flujo de Implementación del Patrón Piramidal .............................................................. 89
CAPÍTULO 4, Implementando el Patrón Piramidal. ............................................................ 92
Consideraciones Previas .................................................................................................. 93
Nivel Base ...................................................................................................................... 93
Nivel de Interpretación ................................................................................................... 94
Nivel Fuente ................................................................................................................... 94
Primer Paso, Especificar Reglas a Nivel Base de Datos ................................................ 95
Definición de Elementos de la Base de Datos .............................................................. 96
Nombre de la Instancia ............................................................................................. 96
Bases de Datos ......................................................................................................... 96
Tablespace ................................................................................................................ 97
Tablas........................................................................................................................ 97
Columnas .................................................................................................................. 98
7
Vistas......................................................................................................................... 99
Índices ....................................................................................................................... 99
Llaves foráneas ...................................................................................................... 100
Cluster .................................................................................................................... 100
Trigger .................................................................................................................... 100
Procedimiento ........................................................................................................ 101
Función .................................................................................................................. 101
Secuencia .............................................................................................................. 101
Ligas de base de datos (database link) ................................................................. 102
Sinónimo ................................................................................................................ 102
Paquete .................................................................................................................. 102
Usuario ................................................................................................................... 102
Role ........................................................................................................................ 103
Profile ..................................................................................................................... 103
Segundo Paso, Manipulación de la Base de Datos ...................................................... 104
Tercer Paso, Análisis y Desarrollo del Web Service ..................................................... 106
Cuarto Paso, Protocolos de Comunicación y Conexión con servicios .......................... 110
Protocolo de comunicación ......................................................................................... 110
Estándar ISO 8583, Conexión con el procesador bancario ....................................... 111
Quinto paso, Lenguaje y medio de comunicación entre el nivel base e interpretación 117
Esquemas XSD como Lenguaje de Interpretación .................................................... 117
Atributos ................................................................................................................. 118
Ejemplo de un esquema XSD ................................................................................ 119
Notación XSD para el nivel de interpretación ............................................................. 120
Solicitud de Cobro bancario ................................................................................... 123
Solicitud de cancelación de un Cobro ................................................................... 128
Solicitud de Reimpresión ....................................................................................... 130
Solicitud de Consulta de Transacciones ................................................................ 132
Sexto Paso, Generar Programas Cliente ...................................................................... 133
Creando Objetos para interacción con el nivel de interpretación ............................... 134
Componente Activex DLL ...................................................................................... 134
Solicitud de Cobro bancario a Nivel Base con Activex ...................................... 137
Solicitud de cancelación de un Cobro a Nivel Base con Activex ....................... 139
Solicitud de Reimpresión a Nivel Base con Activex ........................................... 140
8
Solicitud de Consulta de Transacciones a Nivel Base con Activex ................... 141
Interfaces a las que aplica el control Activex ..................................................... 142
Descripción de Métodos de clases .................................................................... 146
Descripción de Beans de operación .................................................................. 147
Beans de Función .............................................................................................. 147
Interfaces a las que aplica el componente JAR. ................................................ 148
Resultados Obtenidos.................................................................................................... 149
Conclusiones..................................................................................................................... 150
Glosario ............................................................................................................................. 153
Bibliografía ........................................................................................................................ 157
9
Índice de Tablas
Tabla 1, Características del patrón arquitectónico Broker .................................................. 64
Tabla 2, Herramientas del Nivel Base ................................................................................. 93
Tabla 3, Herramientas del Nivel de Interpretación .............................................................. 94
Tabla 4, Herramientas del Nivel Fuente .............................................................................. 94
Tabla 5, Descripción de Procedimientos .......................................................................... 105
Tabla 6, Descripción de Clases ........................................................................................ 106
Tabla 7, Descripción de los Métodos de la Clase XMLServices ...................................... 107
Tabla 8, Descripción de los Métodos de la Clase ISOServices ....................................... 107
Tabla 9, Descripción de los Métodos de la Clase ValidateService .................................. 108
Tabla 10, Descripción de los Métodos de la Clase DBService ........................................ 108
Tabla 11, Descripción de los Métodos de la Clase SecurityService ................................ 108
Tabla 12, Descripción de los Métodos de la Clase LogService ....................................... 109
Tabla 13, Descripción de los Métodos de la Clase ComServices .................................... 109
Tabla 14, Descripción de los Métodos de la Clase TransactionServices ........................ 109
Tabla 15, BitMap de un mensaje ISO 8583 ...................................................................... 114
Tabla 16, Definición de campos de los Data Elements. ................................................... 115
Tabla 17, elementos del tag business .............................................................................. 122
Tabla 18, Elementos del tag “transacction” de una solicitud de cobro ............................. 127
Tabla 19, Elementos del tag “transacction” de una cancelación ...................................... 130
Tabla 20, tags complementarios de una reimpresión ...................................................... 131
Tabla 21, Flujo de Operación control Activex del Nivel Base ........................................... 136
Tabla 22, Descripción de Clases ...................................................................................... 145
Tabla 23, Descripción de Métodos de Clases .................................................................. 146
Tabla 24, Descripción de Beans de Operación ................................................................ 147
Tabla 25, Beans de Función ............................................................................................. 148
10
Índice de Figuras
Figura1, Arquitectura de un Sistema de Venta de Productos. ............................................ 32
Figura 2, Arquitectura CORBA ............................................................................................ 33
Figura 3, Modelo Vista Controlador ..................................................................................... 34
Figura 4, Pantalla de AcmeStudio. ...................................................................................... 59
Figura 5, Diagrama de secuencias que muestra gráficamente el patrón MVC. ................. 62
Figura 6. Niveles del Patrón Piramidal ................................................................................ 70
Figura 7, Patrón Piramidal, un enfoque genérico ................................................................ 77
Figura 8, Partes que conforman el modelo base ................................................................. 79
Figura 9, Arquitectura Actual de la aplicación de cobros bancarios ................................... 82
Figura 10, Procesamiento Electrónico de Transacciones. .................................................. 84
Figura 11, Componentes del Nivel Base ............................................................................. 85
Figura 12, El Lenguaje XML ................................................................................................ 86
Figura 13, Componentes del Nivel de Interpretación .......................................................... 87
Figura 14, Componentes del Nivel Fuente .......................................................................... 88
Figura 15, Patrón Piramidal ................................................................................................. 89
Figura 16, Flujo de Implementación del Patrón Piramidal. .................................................. 91
Figura 17, Agrupación de tablas transaccionales y no transaccionales ............................. 95
Figura 17 Protocolo de Comunicación entre el nivel de interpretación y el nivel fuente . 110
Figura 18, Pasó de mensajes IS0 8583 entre niveles de interpretación y fuente. ........... 111
Figura 19, El estándar ISO 8583 ...................................................................................... 113
Figura 20, elemento business de los esquemas del nivel de interpretación .................... 120
Figura 21, Esquema XSD para la operativa de cobros bancarios ................................... 123
Figura 22, Esquema para la cancelación de un cobro ..................................................... 129
Figura 23, Esquema para la reimpresión de un voucher ................................................. 131
Figura 24, Referencia a componentes ............................................................................. 133
Figura 25, Flujo de Operación control Activex del Nivel Base ......................................... 137
Figura 26, Funciones de entrada en la DLL para generar un mensaje de cobro ............ 138
Figura 27, Funciones de entrada en la DLL para generar un mensaje de cancelación .. 139
Figura 28, Funciones de entrada en la DLL para generar un mensaje de reimpresión... 140
Figura 29, Funciones de entrada en la DLL para generar un mensaje de consulta ........ 141
Figura 30, Aplicación a 32bits del Nivel Base .................................................................. 142
11
Figura 31, Aplicación basada en Mobile ........................................................................... 143
Figura 32, Aplicación Web del Nivel Base ........................................................................ 143
Figura 33, Aplicación TPV Nivel Base .............................................................................. 148
Figura 34, Patrón Piramidal de Venta de Tiempo Aire ..................................................... 151
12
Resumen
Hoy en día muchos de los grandes sistemas son pensados para operar en forma
distribuida, con el fin de centralizar la información y así de llevar cada vez más orden y
control en la operación de los comercios, el problema es que normalmente no se piensa
en que tan fácil o difícil sería para un comercio adaptarse al sistema.
En este trabajo vamos a referirnos principalmente a la arquitectura de sistemas
distribuidos y orientados a servicios, en los cuales la misma arquitectura pueda plantearse
para diferentes problemas, con esto se pretende llegar a generar un patrón que sirva
como base para generar soluciones tomando sus elementos.
Los patrones en la ingeniería de software sirven principalmente para dar orden a
soluciones y plantear estructuras orientadas a resolver problemas recurrentes. Así
también se tiene que los patrones arquitectónicos son un modelo a seguir para lograr
objetivos y con esto basar las soluciones en experiencia que ya ha sido probada y en
buenas practicas.
Dicho lo anterior en este trabajo se pretende también exhortar al uso y creación de
patrones con el fin evitar orientar la solución a los problemas en aplicaciones sumamente
específicas y en lugar de estos hacer soluciones flexibles y orientadas a la reutilización.
Es uno de los principales fines de este trabajo obtener un patrón base y flexible que
permita ser implementado en sistemas distribuidos con información centralizada que
pretendan ofrecer servicios a una gran cantidad de comercios sin importar que algún
comercio maneje alguna infraestructura especial, es decir se pretende que existan
componentes adaptables a diferentes necesidades. En resumen tener un patrón genérico
a soluciones distribuidas orientadas a servicios.
13
Summary
Today many large systems are designed to operate in a distributed way, in order to
centralize information and have more order and control in the operation of businesses, the
problem is that usually we don´t think it would be easy or difficult for trade adapt to the
system.
In this paper we refer mainly to the architecture of distributed systems and service-
oriented, in which the same architecture may be suggested for different problems, with this
we pretend to eventually generate a pattern that serves as a basis to build solutions taking
its elements.
Patterns in software engineering are mainly used to give order to bring solutions and
structures for solving recurring problems. This also has the architectural patterns that are a
model for achieving this objective and solutions based on experience that has already
been proven and best practices.
Also in this paper, we encourage the use and creation of patterns to avoid, guiding the
solution to the problems in very specific applications and instead they can create flexible
solutions designed for reusing.
One of the main purposes of this paper to obtain a flexible base pattern, which allows it to
be implemented in distributed systems with centralized information seeking to provide
services to a large number of businesses regardless of any trade drive a special
infrastructure, it was use to said, intended to be components adaptable to different needs.
In short, having a generic pattern for distributed solutions, service oriented.
14
Introducción
La intención de este trabajo nace del esfuerzo de continuar con la creación de generar
soluciones genéricas para problemas o situaciones recurrentes y para generación de
soluciones que puedan masificarse, principalmente basadas en servicios.
Si un mismo problema se presenta en un entorno diferente no se tenga que diseñar de
nuevo otra solución.
Nace con la necesidad de que un evento se presenta recurrentemente en varios contextos
y se puede dar solución una sola vez y con base a un patrón poder reutilizar esa solución
exitosamente. Hablamos de la solución como un todo como el esqueleto o la estructura,
es decir, se piensa combatir el problema desde una perspectiva más amplia y general.
Tenemos que existen situaciones que se pueden presentar en diferentes escenarios y en
forma recurrente dentro de un contexto distribuido.
Las situaciones pueden ser:
• Nuevas funcionalidades.
• Creación de componentes o módulos.
• Mejoras a las funcionalidades.
• Para lo cual se propone una forma estándar para crear un patrón arquitectónico
que permita replicar una solución de una situación específica dentro de un
contexto distribuido.
Para lo cual se deben tomar en cuenta varias situaciones que a continuación se
describen:
1. Conocer la situación, es decir, hacer un análisis.
2. Identificar si se trata realmente de algo recurrente y se está dando en un contexto
distribuido.
15
3. Verificar si existen varios escenarios en los que pueda ser aplicada la solución o se
trata de una situación única.
4. Evaluar los escenarios en los que se presenta, con el fin de analizar la forma en
que podría comportarse el patrón.
5. Identificar si ya existen patrones que puedan adaptarse.
6. Generar una pseudo solución de la situación, es decir hacer un primer
acercamiento a la solución.
7. Generar un formato o utilizar uno ya existente para el patrón (GoF, IBM), o incluso
hacer una combinación productiva y adaptable
8. Generar el patrón con su conjunto de pasos.
9. Probar el patrón en los diferentes escenarios y evaluar el comportamiento.
10. Hacer una retroalimentación si así lo requiriera.
11. Y por último implementar el patrón.
12. Documentación con respecto a la implementación y mantenimiento.
16
Planteamiento de la problemática
Es interesante pensar que a menudo en el ámbito empresarial se presentan diversas
situaciones en forma recurrente ya sea en el mismo entorno o en entornos distintos, es
decir, muchas empresas en ocasiones presentan problemas parecidos en sus procesos
de negocio o con sus clientes por ejemplo el llevar en orden un inventario suele ser un
problema que presentan más de una empresa de producción de artículos.
Es aún más interesante cuando son empresas más grandes o que cuentan con
sucursales, es difícil controlar un problema y en ocasiones como anteriormente se
menciona suelen presentarse situaciones recurrentes en diferentes entornos.
El problema se centra que muchas veces se diseña una solución a la medida para cada
entorno y depende de la magnitud de la empresa los módulos, herramientas,
infraestructura, costos y funcionalidades adicionales, lo que ocasiona que si el mismo
problema se presenta en un entorno diferente se tenga que diseñar de nuevo otra
solución para dicho entorno.
En las empresas consultoras cuando se enfrentan al diseño de una solución para alguno
de sus clientes, a menudo los líderes de proyecto piensan en generar la solución más
óptima en el menos tiempo posible, lo que en muchas ocasiones deriva a que se olviden
del aspecto de reutilizar y no hablemos exactamente del código o de los componentes
sino de la solución como tal.
Muchas veces cuando se construye una solución a la medida no se piensa más allá de
que satisfaga las necesidades específicas del cliente en ese momento, muchas veces no
se considera la reutilización o más común no se piensa en una arquitectura como tal al
momento de estar generando la solución.
17
Objetivos
Motivar al uso y construcción de patrones arquitectónicos principalmente enfocados al
desarrollo de aplicaciones distribuidas en problemas empresariales.
Demostrar que la construcción correcta de un patrón arquitectónico lleva a la reutilización
de la solución en casos recurrentes y su representación en formas como imágenes y
diagramas.
Exponer los elementos esenciales que debe incluir un patrón arquitectónico al momento
de estar siendo construido.
Mostrar los diferentes tipos de patrones arquitectónicos y entender en qué momento
pueden ser aplicados.
Sugerir una técnica para la construcción de patrones arquitectónicos enfocados al
desarrollo de aplicaciones distribuidas, con el fin de que al implementar esta sugerencia
de técnica se pueda llegar a un mismo resultado en diferentes contextos.
18
Justificación
En la actualidad por el crecimiento de las empresas y en general por las nuevas
necesidades y la masificación del internet y otros recursos, el tipo de soluciones para una
empresa está más enfocado al desarrollo de aplicaciones distribuidas, es decir, que
funcionen en componentes por separado y que se encuentren en diversas capas, no
obstante al momento de generar dichas soluciones es necesario contemplar la posibilidad
de reutilizar dicha solución, lo que implica el uso de patrones arquitecticos aplicados a
soluciones distribuidas.
Con el uso de patrones se abre la posibilidad de llevar una solución a diversos entornos
empresariales, implicar a los patrones como parte del diseño y construcción de una
aplicación pone en ventaja a la empresa desarrolladora de la solución.
En muchas organizaciones que se dedican al desarrollo de sistemas distribuidos la
mayoría de las veces no se considera el uso de patrones arquitectónicos, ya que como se
comentaba anteriormente, se prefiere basar los esfuerzos en el desarrollo de aplicación
rápidas y totalmente a la medida, muchas veces no se considera invertir el tiempo
suficiente en diseñar un patrón que en su momento al encontrar algún problema similar
puede aplicarse sin volver a centrar esfuerzos en el diseño, puesto que en ese caso la
estructura de la aplicación ya estaría lista.
Es importante considerar que si una vez se trabaja como se debe no habrá necesidad de
hacer lo mismo de nuevo, más cuando el problema se presenta de forma recurrente.
19
Alcances
Partiendo de la definición de patrones arquitectónicos, que dice que son aquellos que
definen la estructura de un sistema software, los cuales a su vez se componen de
subsistemas con sus responsabilidades, también tienen una serie de directivas para
organizar los componentes del mismo sistema, con el objetivo de facilitar la tarea del
diseño de tal sistema, tenemos que este trabajo tiene como fin aportar la idea de la
construcción de patrones arquitectónicos principalmente en el desarrollo de aplicaciones
distribuidas, con el fin de mostrar que si se trabaja una vez de forma adecuada en el
futuro no es necesario centrar todos los esfuerzos en la parte de la construcción y diseño
de la solución.
El trabajo mostrará los elementos esenciales de un patrón arquitectónico, las formas
conocidas de hacerlo y se propondrá una alternativa basada en tres escenarios reales
distintos, con el propósito de mostrar que es posible reutilizar una solución si se tiene
desde un principio un enfoque genérico.
Se mostrará la forma en la que abordan el tema las dos principales empresas dedicadas
al software, Microsoft y Sun Microsystems.
Es tema de este trabajo el representar los patrones propuestos a través de un ADL
(Lenguaje de Descripción Arquitectónica - Architecture Description Language), con el fin
de formalizar la forma de representarlo. Adicionalmente a de los ADL también se
mostrarán otras formas de representar a los patrones arquitectónicos.
Se expondrán los diferentes tipos de patrones y en los casos que estos pueden ser
aplicados de marea exitosa. Así de las ventajas y desventajas que tiene la construcción
de patrones arquitectónicos en la programación distribuida.
20
Resultados Esperados
Se espera demostrar que el uso de patrones arquitectónicos en la construcción de
aplicaciones específicamente distribuidas es muy importante y permite construir una sola
vez la solución para problemas recurrentes recomendablemente en diversos contextos.
Se pretende sugerir una técnica en la construcción de patrones para aplicaciones
distribuidas. Así también se pretende partir de patrones ya existentes para que sirva como
apoyo en la construcción de la técnica sugerida.
Se espera demostrar a través de un experimento en tres organizaciones con el mismo
problema y aplicando el mismo patrón que es posible lograr la solución del problema
planteado en todos los casos.
Limitaciones
• No se expondrán a detalle patrones existentes.
• No se mostrarán a detalle especificaciones propias de los lenguajes ADL.
• No se estudiarán a detalle casos de patrones arquitectónicos no orientados a
sistemas distribuidos.
• No se considerarán patrones arquitectónicos para programación paralela.
21
Marco teórico
En este trabajo se pretende hacer una investigación a base de experimentos para
demostrar que la construcción y uso de patrones arquitectónicos enfocados al desarrollo
de aplicaciones distribuidas permite la reutilización de la solución en diferentes contextos
donde se presente un problema similar o recurrente.
El tipo de investigación que se tomará en este trabajo es la investigación aplicada ya que
está basada en la búsqueda intencionada de conocimiento o soluciones a problemas y
básicamente lo que en este trabajo se está buscando.
Se considera que esta investigación es aplicada, porque está relacionada con la
generación de conocimientos en forma de teoría o métodos que se estima que en un
período mediato podrían desembocar en aplicaciones al sector productivo.
Al momento de plantear el método para generar la técnica sugerida para la construcción
de patrones arquitectónicos se tomará en cuenta el formato GoF, el cual consiste en
encontrar elementos o secciones de una situación que es recurrente. Dicho formato
consiste en la consideración de los siguientes elementos:
• Name
• Classification
• Intent
• Also Known As
• Motivation
• Structure
• Participants
• Collaborations
• Consequences
• Implementation
• Sample Code
• Known Uses
• Related Pattern
22
Por otra parte se tomará apoyo de otro formato propuesto por F. Buschmann, R. Meunier,
H. Rohnert, P.Sommerlad, y M. Stal, John Wiley and Sons para la construcción de
patrones arquitectónicos, el cual consiste en los siguientes elementos:
• Name
• Problem
• Context
• Forces
• Solution
• Resulting Context
• Examples
• Rationale
• Related Patterns
• Known Uses
Se tomará en cuenta también para tomar como base el formato expuesto en el documento
U.S. Treasury Architecture Development Guidance (TADG) y que es formalmente
conocida como the Treasury Information System Architecture Framework ( TISAF), esta
especificación describe el fundamento, estructura y taxonomía para patrones
arquitectónicos y considera algunas arquitecturas de patrones enfocados a los sistemas
concurrentes y distribuidos y algunos patrones enfocados a sistemas de tiempo real, lo
que a este trabajo sirve como referencia para poder proponer la construcción de patrones
arquitectónicos basados en aplicaciones distribuidas.
El formato definido en el documento TADG para patrones arquitectónicos, especifica que
deben contener los siguientes elementos:
• Name
• Problem
• Rationale
• Assumptions
• Structure
• Interactions
• Consequences
• Implementation
23
El document TADG, considera tambien patrones ya definidos, los cuales en estre trabajo
se tomarán en cuenta para apoyo a la aportación.
• Client-Proxy Server
• Customer Support
• Reactor
• Replicated Servers
• Layered Architecture
• Pipe and Filter Architecture
• Subsystem Interface
24
CAPITULO 1, Una visión esencial de la arquitectura de software y
patrones
En este capítulo se expondrán temas esenciales referentes a la arquitectura de software y
de los patrones, así también se busca generar una visión global del tema principal de esta
tesis.
También se pretende mostrar los enfoques de estudiosos del tema como David Garlan,
Paul Clements, entre otros y exponer lo que se llama el estado del arte.
Así bien en este capítulo se tocan temas como la Arquitectura de Software desde
diferentes perspectivas, definición y tipos de patrones, vitas arquitectónicas, lenguajes de
descripción arquitectónica, etcétera.
25
Sistemas de información distribuidos
Cuando sale a la luz el tema de los patrones arquitectónicos es posible recurrir a las
aplicaciones o sistemas en los que su arquitectura está basada en programación
distribuida, actualmente la mayoría de los sistemas son basados en arquitecturas
distribuidas, son muy pocos los sistemas que se encuentran bajo una arquitectura
monolítica.
Un sistema de información distribuido es un sistema en el cual sus componentes se
transmiten información, del tipo que sea mediante mensajes, pueden intervenir varios
actores, los cuales de alguna manera participan en el proceso de circulación de la
información entre ellos, de forma independiente el uno del otro.
También es posible comentar que un sistema de información distribuido es una colección
de elementos de que se encuentran físicamente separados y no comparten una memoria
común, se comunican entre sí a través del intercambio de mensajes utilizando un medio
de comunicación.
En un sistema distribuido, podemos considerar ciertos factores característicos que los
definen y distinguen de otros sistemas, los cuales pueden ser:
• Cada elemento tiene su propia memoria y su propio Sistema Operativo.
• Control de recursos locales y remotos.
• Sistemas Abiertos
• Plataforma no estándar.
• Medios de comunicación.
• Capacidad de Procesamiento en paralelo.
• Dispersión y parcialidad.
26
Para que un sistema de información sea construido, deben influir ciertos factores que en
su conjunto crean la necesidad de implementar un sistema distribuido, dichos factores
pueden ser los siguientes:
• Avances Tecnológicos.
• Nuevos requerimientos.
• Globalización.
• Aspectos Externos.
• Integración.
Al momento de construir un sistema basado en patrones arquitectónicos distribuidos
tenemos ciertas características que adquiere dicho sistema y que por ende lo hacen
distinto a otro que no esté basado en este tipo de patrones. Entre dichas características
están las siguientes:
• Las estaciones satisfacen las necesidades de los usuarios.
• Uso de nuevas interfaces.
• Disponibilidad de elementos de Comunicación.
• Desarrollo de nuevas técnicas.
• Respuesta Rápida.
• Ejecución Concurrente de procesos.
• Empleo de técnicas de procesamiento distribuido.
• Disponibilidad y Confiabilidad.
• Sistema poco propenso a fallas de arquitectura o definición.
• Mayores servicios que elevan la funcionalidad.
• Inclusión rápida de nuevos recursos.
• Los recursos actuales no afectan.
27
Es obvio pensar que el tener sistemas distribuidos implica tanto características benéficas
como contraproducentes, entre las cuales podemos citar las siguientes:
• Se requiere poner más atención al momento del procesamiento de las
instrucciones.
• La velocidad de propagación de información, en ocasiones dependiendo de la
infraestructura tiende a ser lenta.
• Servicios de replicación de datos y servicios con posibilidades de fallas.
• Se debe poner más atención a los controles de acceso y a la seguridad de las
aplicaciones, debido a que se encuentran más propensas a posibles hackeos o
introducción de usuarios malintencionados.
• La administración suele complicarse más.
• Los costos de construcción y mantenimiento pueden ser elevados, dependiendo
la planeación y negociación.
Los elementos estructurales incluyen la organización de un sistema como la composición
de componentes; estructuras de control global, protocolos de comunicación, la asignación
de funcionalidad a los elementos de diseño, distribución física, desempeño. Este es el
nivel de arquitectura de software del diseño.
La arquitectura de software de un sistema es la estructura o estructuras del sistema, que
comprenden componentes de software, las propiedades de esos componentes visibles
externamente, y sus relaciones.
Las propiedades visibles externamente refieren a los supuestos que ciertos componentes
pueden hacer sobre otro, como servicios, performance, manejo de errores, etcétera. Los
sistemas pueden tener más de una estructura.
La arquitectura de software define componentes, agrupa información sobre cómo los
componentes interactúan entre sí lo cual revela la diferencia existente entre la arquitectura
de un sistema y su descripción o especificación, el comportamiento de cada componente
es parte de ella en tanto es observable o deducible desde el exterior.
28
Entre los elementos estructurales que deben tomarse en cuenta existen los supuestos
sobre el entorno, es decir el ambiente sobre el cual trabajará el sistema, la confiabilidad,
la seguridad, la robustez, requerimientos de espacio, compatibilidad con estándares, etc.
Otros aspectos que deben ser considerados son, la naturaleza de las interacciones entre
componentes, es decir la manera en la que por definición o implícitamente van a funcionar
los componentes del sistema entre sí, el empaquetamiento de los componentes incluye el
tipo del componente y los tipos de las interacciones que soporta, la elección es en general
independiente de la funcionalidad, pero deben ser empaquetados de formas compatibles
si se espera cooperación entre ellos.
A la hora de comenzar con el diseño de un patrón arquitectónico, se deben considerar dos
elementos necesarios los cuales son los componentes y los conectores, estos pueden
definirse como los primeros bloques de construcción de la arquitectura, se entiende que
un componente es una entidad computacional que se encuentra activa, como un proceso,
un objeto, etc.
Un conector se refiere al mecanismo que actúa como intermediario de la comunicación,
coordinación o cooperación entre componentes.
Es importante mencionar que un patrón permite caracterizar una familia de sistemas que
están relacionadas por compartir ciertas propiedades. Un patrón se puede considerar
como conjunto de restricciones sobre una arquitectura.
Los patrones arquitectónicos en un ambiente distribuido, permiten con facilidad estructurar
los componentes de un sistema.
Un buen diseño de un sistema de información distribuido basado en patrones
arquitectónicos debe de contar con una serie de elementos tales como la transparencia,
es decir cuando las peticiones de los usuarios son satisfechas, utilizando una variedad de
servidores y además dichos usuarios no notan si existe un cambio en alguno de estos
servicios.
En otras palabras la transparencia, significa diseñar la interfaz de llamadas al sistema de
modo que no sea visible la existencia de varios procesadores.
Otro aspecto que se debe considerar en el diseño de sistemas distribuidos es la
flexibilidad, es decir, al momento de ser implementado el sistema permitir cambios de
29
manera sencilla sin impactar su estructura primordial, en otras palabras debe ser
adaptable.
Los sistemas distribuidos deben tomar en cuenta el aspecto de confiablidad, esto quiere
decir que si una máquina falla, alguna otra debe encargarse del trabajo, esto quiere decir
que el sistema siempre debe estar disponible y brindar cierta seguridad a los usuarios que
lo explotan, ósea, un aspecto de la confiabilidad es la disponibilidad, que se refiere a la
fracción de tiempo en que se puede utilizar el sistema.
Los datos no deben perderse o mezclarse y si los archivos se almacenan de manera
redundante en varios servidores, todas las copias deben ser consistentes.
Otro aspecto de la confiabilidad general es la seguridad, lo que significa que los archivos y
otros recursos deben ser protegidos contra el uso no autorizado.
Un aspecto también relacionado con la confiabilidad es la tolerancia a fallas, según la cual
las fallas se deben ocultar brindando una recuperación transparente para el usuario,
aunque haya cierta degradación de la performance.
El desempeño es también un factor fundamental a la hora del diseño de sistemas
distribuidos, esto quiere decir que cuando se ejecuta una aplicación en un sistema
distribuido no debe parecer diferente o peor que si se ejecuta de forma aislada.
El desempeño se puede parametrizar tomando algunas métricas como el tiempo de
respuesta, el rendimiento, cantidad consumida de la capacidad de la red, entre otras.
Para garantizar un buen desempeño a la hora de realizar peticiones entre los módulos del
sistema, se tiene que considerar el uso de protocolos de comunicación en los
procesadores que intervienen en la comunicación, esto implica que se incremente el
consumo del procesador.
Por lo tanto se debe considerar la minimización del número de mensajes, lo difícil es que
la mejor forma de mejorar el desempeño es tener muchas actividades en ejecución al
mismo tiempo, es decir, ejecución paralela en distintos procesadores.
La escalabilidad es otro aspecto, que se debe de tratar en el diseño de sistemas
orientados a la programación distribuida, la tendencia indica que el tamaño de los
sistemas distribuidos es hacia cientos y miles de usuarios conectados, esto implica la
30
existencia de problemas como los cuellos de botella los cuales se debe intentar evitar,
algunos de estos problemas son:
• Componentes centralizados.
• Tablas centralizadas.
• Algoritmos centralizados.
Es por ello que se deben utilizar algoritmos contrarios es decir descentralizados y que
cuenten con ciertas características para garantizar que un sistema distribuido cuente con
un grado alto de escalabilidad.
• Ninguna máquina tiene la información completa acerca del estado del sistema.
• Las máquinas toman decisiones solo en base a la información disponible de
manera local.
• El fallo de una máquina no arruina el algoritmo.
• No existe una hipótesis implícita de la existencia de un reloj global.
31
Arquitectura de Software
Existen muchas definiciones acerca de lo que es arquitectura de software, puesto que es
posible agregar el tema de Arquitectura de software desde un enfoque de ingeniería o de
diseño de sistemas.
Sin embargo existe una definición reconocida y aceptada de Paul Clements (Paul
Clements, 1996), quien dice que: La Arquitectura de Software a grandes rasgos, es una
vista del sistema que incluye los componentes principales del mismo, la conducta de esos
componentes según se le 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.
Por su parte tenemos que David Garlan (David Garlan, 2000) establece que la
Arquitectura de Software constituye un puente entre el requerimiento y el código,
ocupando el lugar que en los gráficos antiguos se reservaba para el diseño, esto puede
ser considerado como un enfoque demasiado amplio.
No obstante se tiene una definición formal de Arquitectura de software la cual ofrece el
documento de IEEE Estándar 1471-2000 y dice de la siguiente manera:
La arquitectura de software es un conjunto de decisiones al momento del diseño del
software que deben ser ejecutadas correctamente porque de lo contrario podrían cancelar
todo el proyecto, es decir es un conjunto de consideraciones y de decisiones que deben
ser tomadas en cuenta.
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.
A continuación se muestra una figura que describe la arquitectura de un sistema de venta
de productos y se muestra la interacción que existe entre sus diferentes componentes,
desde un punto de vista de la operación del sistema.
32
Esta arquitectura se compone de cinco componentes los cuales son:
• El usuario quien es la persona física que opera el sistema y que puede ser uno o
varios individuos.
• La PC que cuenta con tres periféricos, los cuales son un lector de código de barras,
una impresora de tickets y un lector de tarjetas bancarias y se encargan de enviar
datos al cliente procesables para el servidor. La PC también tiene instalado el
software cliente que se comunica con el servidor para enviar y recibir peticiones
durante la operación, pueden existir muchas PC’s con las mismas características.
• El servidor, el cual tiene instalada la base de datos donde se registran todas las
operaciones realizadas por los clientes, también cuenta con salida a internet, para
proveer de servicios a los clientes conectados y para enviar y recibir mensajes del
componente autorizador.
• Autorizador, el cual se encarga de comunicarle al servidor el resultado de una
transacción realizada con tarjeta bancaria, este es un solo componente.
• Banco es la entidad que recibe los datos del autorizador y los procesa para enviarle
el resultado de la transacción, es importante mencionar que pueden existir varios
bancos los cuales se comunican con el autorizador.
Figura1, Arquitectura de un Sistema de Venta de Productos.
33
Por otra parte tenemos que Mary Shaw y David Garlan (Mary Shaw, 1995), al ver que
existen múltiples definiciones y enfoques de Arquitectura de Software optaron por explicar
las diferencias entre las definiciones con base a distintas clases de modelos:
• Modelos Estructurales.
• Modelos de Framework.
• Modelos Dinámicos.
• Modelos de Proceso.
• Modelos Funcionales.
En cuanto a los Modelos Estructurales sostienen que la Arquitectura de Software está
compuesta por componentes, conexiones entre ellos y otros aspectos tales como
configuración, estilo, restricciones, semántica, análisis, propiedades, racionalizaciones,
requerimientos, necesidades de los participantes, el trabajo en este modelo está
caracterizado por el desarrollo de lenguajes de descripción arquitectónica. Como ejemplo
podemos tomar el Sistema de la Venta de productos (Figura 1).
Para los Modelos de Framework, encontramos cierta similitud con el concepto estructural,
solo que se enfoca principalmente en la estructura coherente del sistema completo, en
lugar de concentrarse en su composición. Los modelos de Framework normalmente se
refieren a dominios o clases de problemas específicos, es decir arquitecturas de software
específicas de dominio, tales como CORBA (Figura 2).
Interfaz con el ORBPlantilla IDLInvocación Dinámica Adaptador del ObjetoEsqueleto DinámicoEsqueleto IDL Estátio
Cliente Implementación del Objeto
Nucleo ORB
Figura 2, Arquitectura CORBA
34
Los modelos dinámicos, se concentran en la conducta de los sistemas, lo cual puede
referirse a cambios en la configuración de los mismos, y su fin específicamente es que las
configuraciones que contenga sean parametrizables y no fijas.
En cuanto a los modelos de proceso, estos concentran su atención en la construcción de
la arquitectura y en los pasos o procesos involucrados en esa construcción, para este
modelo la arquitectura de software es el resultado de seguir un script o argumento de
proceso.
Los modelos funcionales ven a la arquitectura como un conjunto de componentes
funcionales que se encuentran en forma de capas las cuales proporcionan servicios hacia
arriba, es decir hacia los componentes que invocan a los que proporcionan el servicio, un
ejemplo común de este tipo de modelo es el modelo vista controlador (Figura 3).
Figura 3, Modelo Vista Controlador
35
Para esta tesis principalmente se hará un enfoque a los modelos Estructurales basados
en los ADLs y en los modelos de Framework.
Así también esta tesis está orientada a la Arquitectura basada en Patrones, que bien es
un modelo que se encuentra vinculado a UML en cuanto al modelado y expresión gráfica
de los componentes, en general la Arquitectura basada en patrones consiste en identificar
y articular patrones preexistentes, que se definen en forma similar a los estilos
arquitectónicos.
En el campo del software, la arquitectura nos identifica los elementos más importantes de
un sistema así como sus relaciones. Es decir nos da una visión global del sistema.
Definir una arquitectura de software es importante porque se necesita para entender el
sistema, organizar su desarrollo, plantear la reutilización del software y hacerlo
evolucionar.
Generalmente las metodologías de desarrollo indican principios para identificar y diseñar
una arquitectura, aunque la ayuda real que ofrecen es muy limitada al basarse en
principios muy genéricos. La arquitectura de un sistema no precisamente responde
requisitos estructurales, sino que está relacionada con aspectos de rendimiento,
usabilidad, reutilización, restricciones económicas y tecnológicas, e incluso cuestiones
estéticas.
Actualmente existen muchas metodologías de desarrollo de software, desde métodos muy
pesados y burocráticos, métodos ajustables al proyecto y a las condiciones de desarrollo
y métodos ligeros que surgen como respuesta a los excesos formales de otros métodos.
Evidentemente, partiendo de los principios de diversas metodologías es muy difícil sacar
una visión unificada sobre el diseño arquitectónico. Sin embargo sí es posible destacar
una serie de elementos comunes.
De estos elementos comunes podemos decir que el primero es la existencia de una fase
en la que se establece o diseña una arquitectura base el segundo elemento es la
36
dependencia que definen entre los casos de uso y la arquitectura, definiendo un caso de
uso como una interacción (secuencia de acciones) típica entre el usuario y el sistema.
Desde un punto de vista arquitectónico, no todos los casos de uso tienen la misma
importancia, destacando aquellos que nos ayudan a mitigar los riesgos más importantes y
sobre todo aquellos que representan la funcionalidad básica del sistema a construir.
Esta arquitectura base estará especificada por diagramas que muestren subsistemas,
interfaces entre los mismos, diagramas de componentes, clases, descripciones diversas,
y por el conjunto de casos de uso básicos. Este conjunto de especificaciones permiten
validar la arquitectura con los clientes y los desarrolladores, y asegurar que es adecuada
para implementar la funcionalidad básica deseada.
Una visión alternativa sería identificar el tipo de sistema que se quiere construir. Es sabido
que no hay dos aplicaciones iguales, pero que existen claros paralelismos entre las
aplicaciones construidas para resolver problemas similares. El tomar atención en
aplicaciones del mismo tipo tiene muchas ventajas ya que ayuda a entender las
necesidades del cliente y las soluciones ya encontradas por otros.
Mientras que usar una metodología tradicional de desarrollo permite centrarse únicamente
en parte del problema, obviando cuestiones como rendimiento, seguridad, protocolos de
comunicación, restricciones de hardware, software, y económicas. Una metodología
tradicional proporciona una visión estrecha, ya que frecuentemente el cliente no expone
adecuadamente todos sus requisitos porque no los conoce.
Suponiendo que estamos desarrollando un portal web. La experiencia nos dice que a
partir de cierto número de páginas, es útil desarrollar un sistema basado en plantillas, por
la disminución de costos de mantenimiento. Esto es algo que ningún requisito funcional
proporcionaría, y que probablemente tampoco surgiría de forma natural en los modelos de
diseño.
A este tipo de soluciones (patrón de diseño) se llega por la experiencia en el desarrollo de
sistemas y por el conocimiento de las tecnologías existentes en el mercado. Gracias a
esta experiencia, desde el inicio del desarrollo de una aplicación, es posible buscar
componentes que implementen ciertas tecnologías o funcionalidades, y por lo tanto
37
integrar la búsqueda de componentes y su uso dentro del proceso de desarrollo de
software.
Identificar el tipo de sistema a construir permite examinar la arquitectura de sistemas ya
construidos, comprender los requisitos a los que se enfrentan, y constatarlos con usuarios
finales. Si se tiene en cuenta que en cualquier tipo de sistema existen necesidades
similares, muchos de los componentes que se usan en su desarrollo suelen ser los
mismos.
Las metodologías que gestionen de forma directa a los aspectos arquitectónicos y
estructurales de un sistema, podrán producir no solo productos de mayor calidad, sino a
un menor costo y en menos tiempo, esto se debe a que los riesgos arquitectónicos del
proyecto son menores y están mucho más controlados, y que al poder integrar una visión
orientada a componentes, las posibilidades de reutilizar software ya desarrollado son
mucho mayores, con las ventajas que ello implica.
Construir una arquitectura es tanto una actividad donde desarrollar ideas nuevas como
una oportunidad de usar la experiencia acumulada, siendo casi siempre responsabilidad
del desarrollador crear un producto de calidad y por tanto conocer el tipo de sistema a
construir. Afortunadamente para esto último, los lenguajes de patrones (ADL’s) nos
pueden proporcionar mucha ayuda.
Los Lenguajes de descripción arquitectónica (ADL’s) se pueden definir como "La
especificación de una serie de elementos y sus relaciones de modo que permiten describir
buenas soluciones a los diferentes problemas que aparecen en un contexto específico"
(Clements, 1996).
Los patrones de diseño tienen como objetivo capturar buenas prácticas que nos permitan
mejorar la calidad del diseño de un sistema, determinando elementos que soporten roles
útiles en dicho contexto, encapsulando complejidad, y haciéndolo más flexible.
Por otro lado, con frecuencia se dice que la función define a la forma, es decir, que la
estructura o la arquitectura de cualquier sistema está muy relacionada con lo que dicho
sistema tiene que hacer. Esta es la razón por la que los sistemas con objetivos similares
38
comparten también una arquitectura común, unos procesos bien definidos, y un conjunto
de elementos similares, similar funcionalidad y servicio, similar estructura.
Cuando se desarrolla un sistema que se encuadra dentro de cierto tipo, es muy útil
consultar lenguajes de patrones que traten el dominio en el que estamos. Un lenguaje de
patrones sirve como referencia conceptual del dominio del problema, ya que éstos parten
como solución a un conjunto de casos de uso, e interacciones con actores específicos.
Además constituyen también un marco conceptual en el diseño de la arquitectura de los
sistemas, ya que como la función define a la forma, sintetizan por lo general soluciones
arquitectónicas y estructurales bien probadas y muy útiles dentro del tipo de problemas
que modelan.
De alguna forma, los patrones nos permiten identificar y completar los casos de uso
básicos expuestos por el cliente, comprender la arquitectura del sistema a construir así
como su problemática, y buscar componentes ya desarrollados que cumplan con los
requisitos del tipo de sistema a construir.
Un lenguaje de patrones que modele un tipo de sistema debe de ser descrito incluyendo
la siguiente información:
• Características básicas que lo definen y diferencian.
• Definición de los actores principales que participan en dicho sistema así como sus
casos de uso básicos, descritos evidentemente de forma genérica.
• Especificación de los principales componentes funcionales del sistema así como
las relaciones entre ellos.
• Arquitectura lógica y flujos de información, que estructuran los diferentes
subsistemas, el intercambio de información entre los mismos, etc.
• Arquitectura de componentes. Consiste en mapear los componentes funcionales en
la arquitectura lógica de la aplicación.
• Arquitectura física. Especificación del despliegue de los componentes.
Los ADL’s deben tener una visión orientada a la construcción de software y a constituirse
como elementos integrables en el proceso de desarrollo de las aplicaciones, más adelante
en este capítulo se mencionaran más a detalle.
39
Vistas Arquitectónicas
Las vistas son formas que sirven para representar un aspecto parcial de una Arquitectura
de Software mostrando propiedades específicas de un sistema. Se les puede considerar
como parte de los bloques de un sistema.
Existen gran número de Vistas bien conocidas, cada una de las cuales revela ciertos
aspectos a ser analizados de la arquitectura. Una arquitectura debe ser descrita en varias
Vistas arquitectónicas relevantes.
Las Vistas pueden ser descritas gráficamente como una cantidad de componentes y
conexiones, pero la semántica de estos artefactos difiere entre Vistas. De igual manera,
diferentes Vistas pueden ser utilizadas para diferentes análisis.
Así también al tener un enfoque arquitectónico, tenemos que la arquitectura de un sistema
consta de múltiples vistas, asociadas a diferentes dimensiones o perspectivas del sistema
y ninguna de estas en particular constituye la arquitectura del sistema como tal. Estas
vistas bien se encuentran dirigidas a usuarios en particular.
Tomando un enfoque del modelo de 4+1 vistas de Philippe Kruchten (Philippe Kruchten,
1995), que como su propuesta lo menciona, las vista de una arquitectura son divididas en
cuatro:
• Vista Lógica.
• Vista de Proceso.
• Vista de Desarrollo.
• Vista Física.
En cada una de las vistas es notable ciertas características, como el aspecto del sistema,
a quien va dirigida particularmente cada vista, así también su notación, es decir el
conjunto de elementos y conectores, esenciales para generar diagramas de cada vista.
40
Cabe mencionar que para cada proyecto no todas las vistas son necesarias e
importantes, pueden existir proyectos en los que por premura de tiempo, se quedan solo
en Vista de Desarrollo o que se saltan la vista de proceso, etcétera.
Abundando acerca del modelo de vistas propuesto por Philippe Kruchten, tenemos que se
basa mucho en la abstracción.
Por su parte la Vista Lógica, se refiere a la abstracción de las funciones del sistema y sus
relaciones, la Vista Lógica se descompone en una serie de abstracciones clave, tomadas
principalmente del dominio del problema en la forma de objetos o clases de objetos y se
aplican los principios de abstracción, encapsulamiento y herencia.
Philippe Kruchten, considera la notación Rational/Booch, para representar la vista lógica,
mediante diagramas de clases y plantillas de clases, los diagramas de clases muestran un
conjunto de clases así como sus relaciones lógicas, asociaciones, uso, composición,
herencia y más elementos de la Programación Orientada a Objetos (POO). Las plantillas
de clases principalmente se centran en cada clase en forma individual y enfatizan las
operaciones principales de la clase e identifican las principales características de los
objetos.
La Vista de Procesos, toma en cuenta algunos requisitos no funcionales tales como la
performance y la disponibilidad, principalmente esta vista se enfoca en la concurrencia y
distribución, integridad del sistema y tolerancia a fallas.
En la Vista de Procesos se describe en varios niveles de abstracción donde cada nivel
está enfocado a distintos intereses, se tiene que un proceso es una agrupación de tareas
que forman una unidad ejecutable. Los procesos representan el nivel al que la
arquitectura de procesos puede ser controlada tácticamente. Además, los procesos
pueden replicarse para aumentar la distribución de la carga de procesamiento, o para
mejorar la disponibilidad.
La Vista de Desarrollo, se centra en la organización de los módulos generados en
ambiente de desarrollo, el software es empaquetado en pequeñas partes llamados
subsistemas o bibliotecas de programas que pueden ser desarrollados por uno o más
desarrolladores. Dichos subsistemas se organizan jerárquicamente en forma de capas y
41
cada capa proporciona una interfaz o componente que va apuntando hacia otras capas
que se encuentra en un nivel arriba de la jerarquía.
Esta Vista, toma en cuenta aspectos como la facilidad de desarrollo, administración del
software, reutilización y restricciones impuestas por el lenguaje de programación.
La Vista de Desarrollo de un sistema se debe representar en diagramas de módulos o
subsistemas, la vista de desarrollo solo puede describirse completamente cuando todos
los elementos han sido identificados.
Por otra parte en cuanto a la Vista Física, esta vista principalmente se refiere al mapeo del
software y el hardware y sus aspectos distribuidos. Esta vista toma en cuenta requisitos
que no tienen que ver con la funcionalidad del sistema como la disponibilidad,
confiabilidad, performance y la escalabilidad.
En este caso como lo es el enfoque distribuido se tiene que el software se ejecuta sobre
una red donde sus elementos tales como procesos, tareas y objetos, requieren ser
mapeados sobre varios nodos. Con esta vista se espera que diferentes configuraciones
puedan ser utilizadas, algunas para desarrollo y pruebas, otras para emplazar el sistema
en varios sitios para diferentes usuarios, es por esto que el mapeo del software en los
nodos requiere ser flexible y tener un mínimo impacto sobre el código fuente, es decir, sin
tener que recompilar los módulos.
42
Patrones
Existen muchas definiciones alrededor del tema de los patrones así también muchos
enfoques ya que como es sabido el tema de patrones puede aplicarse a muchas áreas del
conocimiento como la arquitectura civil, la industria textil, la mecánica, etcétera. En su
forma más genérica un patrón en si es un modelo a seguir que puede ser tomado en
cuenta al momento de realizar algo.
Siendo exigentes con la anterior definición tenemos que en lugar de decir que el patrón se
puede tomar en cuenta para hacer algo deberíamos decir que el patrón se debe tomar en
cuenta el momento de hacer algo, con el fin de llevar un cierto orden y llegar a la
construcción correcta de lo que se esté haciendo. Los patrones surgen de la experiencia
de los seres humanos de tratar de lograr ciertos objetivos.
Los patrones son el modelo a seguir para lograr un objetivo y así basar la solución en
experiencia probada y en buenas prácticas. Dicho lo anterior los patrones capturan la
experiencia existente y probada para promover buenas prácticas. Los patrones fueron
inicialmente concebidos por el arquitecto Christopher Alexander en su libro A Pattern
Language (C. Alexander, 1977), como una manera de formalizar la solución a problemas
comunes a muchos proyectos de arquitectura.
Vista la eficacia de los patrones en el campo de la arquitectura, otras disciplinas los
añadieron a su repertorio de herramientas. La informática no ha sido una excepción y la
adaptación de este concepto a la ingeniería del software fue con la aportación de Ward
Cummingham y Kent Beck (Kent Beck, 1987) quienes adaptaron ideas de Christopher
Alexander a la Ingeniería de Software y crearon cinco patrones para el diseño de las
interfaces y en el año de 1995 Gamma, Helm, Johnson, Vlissides más conocidos como la
pandilla de los cuatro “Gang of Four”, publican su libro Desing Patterns (Gamma, 1995),
en donde hacen una recopilación de 23 patrones comunes en el diseño de software
orientado a objetos. Tenemos que los patrones son una guía para la correcta arquitectura,
diseño y desarrollo del software.
43
En si la generación de patrones de software se basa en capturar la experiencia de la
solución a problemas que surgen en un contexto y la documentación de dicha
experiencia, con el fin de que al momento de presentarse de nuevo un problema de esa
índole se pueda recurrir al patrón que ayuda a la solución del problema.
Dicho de otra manera un patrón intenta capturar la experiencia, de modo que la forma
correcta de resolver un problema dado pudiera ser transmitida a otras personas que aún
no se ha encontrado con el problema, se trata de formalizar soluciones a distintas
situaciones de modo que puedan ser entendidas por otras personas. Por lo tanto, un
patrón no es más que la descripción detallada de una solución adecuada a un problema
concreto.
El objetivo básico que se persigue con la idea de patrón es no tener que rehacer las cosas
cada vez que se presente una cierta situación. Los patrones capturan soluciones a
situaciones de especial interés, ya sea por ser muy comunes o por ser especialmente
complejas. Normalmente, un patrón está compuesto por el enunciado del problema y una
o varias propuestas de solución.
Para formalizar estas soluciones, se necesita una notación expresiva y rica en semántica
que permita plasmar eficientemente los atributos de las mismas, para ello se utilizan
herramientas como el UML o los ADL, de los cuales se hablará más a detalle.
Para que una solución sea considerada un patrón debe poseer ciertas características, una
de ellas es que debe haber comprobado su efectividad resolviendo problemas similares
en ocasiones anteriores. Otra es que debe ser reusable, lo que significa que es aplicable
a diferentes problemas de diseño en distintas circunstancias.
44
Tipos de Patrones
No existe una sola clasificación como tal, pueden ser de varios enfoques tales como:
• Patrones de Procesos (Organización, Administración, Análisis Diseño y Pruebas).
• Patrones de producto de Software (Análisis, Arquitectura, Diseño y Lenguaje de
programación).
• Conjuntos de Patrones (Lenguaje de Patrones, Catalogo de Patrones, Sistema de
Patrones).
• Patrones Arquitectónicos (Patrones aplicables a sistemas distribuidos).
• Patrones de diseño.
Patrones de diseño
Cuando nos referimos a patrones de diseño tenemos que son maneras de solucionar
muchos problemas parecidos de una misma manera, de hecho se centran en la parte
usual del componente a diseñar, y de esa forma son muy específicos.
Tenemos que son descripciones de clases cuyas instancias se relacionan y colaboran
entre sí. Cada patrón es adecuado para ser adaptado a un cierto tipo de problema, una
arquitectura orientada a objetos está llena de patrones. Los patrones conducen a
arquitecturas más pequeñas, más simples y más comprensibles, para describir un patrón
debemos especificar, los siguientes elementos:
• Nombre.
• Propósito o finalidad.
• Sinónimos (otros nombres por los que puede ser conocido).
• Problema al que es aplicable.
• Estructura (diagrama de clases).
• Participantes (responsabilidad de cada clase).
45
• Colaboraciones (diagrama de interacciones).
• Implementación (consejos, notas y ejemplos).
• Otros patrones con los que está relacionado.
Aunque esta es una forma para describir el propósito, nombre y demás propiedades de
los patrones existen muchos formatos o incluso se puede crear un formato propio para
representar a los patrones.
Es fundamental que para apoyarse de la reutilización es necesario anticiparse a los
nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada.
Cada patrón permite que algunos aspectos de la estructura del sistema puedan cambiar
independientemente de otros aspectos. Facilitan la reusabilidad, extensibilidad y
mantenimiento.
Como se ha comentado un patrón es un esquema que supone una solución a problemas
semejantes o concurrentes.
También es conveniente distinguir entre un patrón y la arquitectura del sistema como tal,
por así decirlo es la misma diferencia entre el diseño de un componente y el análisis del
sistema.
En general un patrón de diseño es una solución estándar para un problema común de
programación, una técnica para hacer flexibilizar el código y satisfacer ciertos criterios.
Los patrones de diseño permiten a un proyecto lograr una finalidad determinada, son
vistos como una manera más práctica de describir ciertos aspectos de la organización de
un programa y conexiones entre componentes de programas.
Es evidente que a lo largo de multitud de diseños de aplicaciones hay problemas que se
repiten y que responden a un cierto patrón. Sería deseable tener una colección de dichos
patrones con las soluciones más óptimas para cada caso.
46
Los patrones de diseño permiten que los diseños sean mucho más flexibles, modulares y
reutilizables, en el libro Design Patterns (Gamma, 1995) se dice que han revolucionado el
diseño orientado a objetos y todo buen arquitecto de software debería conocerlos. A
continuación se enlistan y describen de forma breve los patrones de diseño a objetos más
habituales publicados en el libro antes mencionado.
Patrones de creación
• Abstract Factory. Proporciona una interfaz para crear familias de objetos o que
dependen entre sí, sin especificar sus clases concretas.
• Builder. Separa la construcción de un objeto complejo de su representación, de
forma que el mismo proceso de construcción pueda crear diferentes
representaciones.
• Factory Method. Define una interfaz para crear un objeto, pero deja que sean
las subclases quienes decidan qué clase instanciar. Permite que una clase
delegue en sus subclases la creación de objetos.
• Prototype. Especifica los tipos de objetos a crear por medio de una instancia
prototípica, y crear nuevos objetos copiando este prototipo.
• Singleton. Garantiza que una clase sólo tenga una instancia, y proporciona un
punto de acceso global a ella.
Patrones estructurales
• Adapter. Convierte la interfaz de una clase en otra distinta que es la que
esperan los clientes. Permiten que cooperen clases que de otra manera no
podrían por tener interfaces incompatibles.
• Bridge. Desvincula una abstracción de su implementación, de manera que
ambas puedan variar de forma independiente.
47
• Composite. Combina objetos en estructuras de árbol para representar
jerarquías de parte-todo. Permite que los clientes traten de manera uniforme a
los objetos individuales y a los compuestos.
• Decorator. Añade dinámicamente nuevas responsabilidades a un objeto,
proporcionando una alternativa flexible a la herencia para extender la
funcionalidad.
• Facade. Proporciona una interfaz unificada para un conjunto de interfaces de un
subsistema. Define una interfaz de alto nivel que hace que el subsistema se
más fácil de usar.
• Flyweight. Usa el compartimiento para permitir un gran número de objetos de
grano fino de forma eficiente.
• Proxy. Proporciona un sustituto o representante de otro objeto para controlar el
acceso a éste.
Patrones de comportamiento
• Chain of Responsibility. Evita acoplar el emisor de una petición a su receptor, al
dar a más de un objeto la posibilidad de responder a la petición. Crea una
cadena con los objetos receptores y pasa la petición a través de la cadena
hasta que esta sea tratada por algún objeto.
• Command. Encapsula una petición en un objeto, permitiendo así parametrizar a
los clientes con distintas peticiones, encolar o llevar un registro de las peticiones
y poder deshacer la operaciones.
• Interpreter. Dado un lenguaje, define una representación de su gramática junto
con un intérprete que usa dicha representación para interpretar las sentencias
del lenguaje.
• Iterator. Proporciona un modo de acceder secuencialmente a los elementos de
un objeto agregado sin exponer su representación interna.
48
• Mediator. Define un objeto que encapsula cómo interactúan un conjunto de
objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran
unos a otros explícitamente, y permite variar la interacción entre ellos de forma
independiente.
• Memento. Representa y externaliza el estado interno de un objeto sin violar la
encapsulación, de forma que éste puede volver a dicho estado más tarde.
• Observer. Define una dependencia de uno-a-muchos entre objetos, de forma
que cuando un objeto cambia de estado se notifica y actualizan
automáticamente todos los objetos.
• State. Permite que un objeto modifique su comportamiento cada vez que
cambia su estado interno. Parecerá que cambia la clase del objeto.
• Strategy. Define una familia de algoritmos, encapsula uno de ellos y los hace
intercambiables. Permite que un algoritmo varíe independientemente de los
clientes que lo usan.
• Template Method. Define en una operación el esqueleto de un algoritmo,
delegando en las subclases algunos de sus pasos. Permite que las subclases
redefinan ciertos pasos del algoritmo sin cambiar su estructura.
• Visitor. Representa una operación sobre los elementos de una estructura de
objetos. Permite definir una nueva operación sin cambiar las clases de los
elementos sobre los que opera.
49
Patrones arquitectónicos
En un panorama muy genérico y orientado a la arquitectura de software tenemos que los
patrones arquitectónicos son aquellos que definen la estructura de un sistema software,
los cuales a su vez se componen de subsistemas con sus responsabilidades, también
tienen una serie de directivas para organizar los componentes del mismo sistema, con el
objetivo de facilitar la tarea del diseño de tal sistema.
Un patrón de arquitectura de software describe un problema particular y recurrente que
surge en un contexto específico, y presenta un esquema genérico y probado de su
solución.
En la actualidad existe una gran diversidad de arquitecturas que implementan patrones y
que se vuelven de uso común.
Los patrones arquitectónicos expresan un esquema estructural de la organización del
sistema, es decir, un esqueleto o estructura de un sistema, dicha estructura consiste en
subsistemas así como de sus responsabilidades e interrelaciones.
Si comparamos a los patrones de diseño con los de arquitectura tenemos que los
arquitectónicos son más grandes en escala y alcance.
Aun cuando un patrón arquitectónico contiene la forma o imagen de un sistema, no es una
arquitectura como tal, un patrón arquitectónico es un concepto que captura elementos
esenciales de una arquitectura.
Por consecuencia al no ser una arquitectura como tal, un patrón al ser implementado
permite que varias arquitecturas lo contengan y compartan características comunes.
Uno de los aspectos más importantes de patrones arquitectónicos es que incorporan
diversas cualidades de la calidad, es decir, algunos patrones representan soluciones a los
problemas de funcionamiento y otros se pueden utilizar con éxito en sistemas de alta
disponibilidad, como sistemas bancarios transaccionales o de cajeros automáticos.
Un sistema de patrones brinda un conjunto de soluciones probadas y depuradas a
muchos problemas recurrentes de diseño de diversos niveles de abstracción, desde los
patrones arquitectónicos hasta los patrones de bajo nivel dependen del lenguaje para
50
implementarlos, con este enfoque se permite generar un desarrollo con un alto grado de
reusabilidad.
Los patrones arquitectónicos representan el nivel más alto en un sistema de patrones,
permiten especificar la estructura fundamental de una aplicación, todas las actividades del
desarrollo están bajo esta estructura, por ejemplo el diseño a través de subsistemas, la
comunicación y colaboración entre diferentes partes del sistema.
Así también es considerable comentar que los patrones que dan soporte a propiedades
similares pueden ser agrupados en categorías. Según Buschmann en su libro “Pattern-
Oriented Software Architecture, A System of Patterns” (Buschmann, 1996), comenta las
siguientes categorías para los patrones arquitectónicos.
• Sistemas Distribuidos.
• Sistemas Interactivos.
• Sistemas Adaptables.
51
El Futuro de los Patrones
En el futuro esperamos que el interés en los patrones crezca sustancialmente, ya que los
investigadores y los principales proyectos de software se encuentran orientados a
continuar adoptando paradigmas de patrones, métodos y procesos (Schmidt, 2007).
La literatura de los patrones en los últimos años se ha centrado en los patrones concretos
y lenguajes de patrones, a menudo derivados de los entornos de aplicaciones orientadas
a objetos. De cara al futuro, se espera que la comunidad que se dedica del estudio de los
patrones se amplíe sobre esta tradición. Por ejemplo, la próxima generación de
aplicaciones orientadas a objetos en sus frameworks incorporan a los patrones de forma
explícita.
• Objetos distribuidos. Muchos patrones asociados con el middleware y las
aplicaciones para objetos concurrentes y en red se han documentado durante los
últimos diez años. El siguiente paso clave es el de documentar patrones de objetos
distribuidos, con el fin de extender lo ya documentado para centrarse en temas de
distribución de objetos, tales como localización de servicios remotos y partición,
nombres y directorios de servicios, balanceo de carga, confiabilidad y seguridad.
• Sistemas embebidos. Un número cada vez mayor de sistemas de computación
están incorporados, incluidos los sistemas de control del automóvil y aplicaciones
basados en el coche, software de control para equipos de automatización,
informática aviónica de misión, y dispositivos informáticos portátiles. Muchos de
estos sistemas están sujetos a estrictas limitaciones de recursos de computación,
en particular huella de la memoria y time constraints.
• Sistemas móviles. Las redes inalámbricas se están convirtiendo en dispositivos de
computación ubicua e integrados se vuelven más pequeños, más ligeros, y más
capaz. Por lo tanto, los sistemas móviles pronto apoyo a la comunicación de los
consumidores y muchas necesidades informáticas. Las áreas de aplicación para
los sistemas móviles incluyen computación ubicua, los agentes móviles, asistentes
personales, suministro de información dependientes de la posición, distancia de
diagnóstico médico y tele-radiología, y en el hogar y automatización de oficinas.
52
Además, los servicios de Internet, que van desde la navegación por la web de
banca on-line, se puede acceder desde sistemas móviles. Los sistemas móviles
pueden enfrentarse a muchos desafíos, como la gestión de ancho de banda,
adaptándose a las frecuentes interrupciones en la conectividad y la calidad del
servicio, las divergencias en los protocolos, y el mantenimiento de la coherencia de
caché a través de nodos de red. Esperamos que los desarrolladores con
experiencia en sistemas móviles determinen documentar su experiencia en forma
de un patrón para ayudar a satisfacer la creciente demanda de las mejores
prácticas en el desarrollo de software en este ámbito.
• Transacciones comerciales y sistemas de comercio electrónico. Muchos sistemas
de información empresarial, tales como contabilidad, nómina, inventarios y
sistemas de facturación, se basan en transacciones. Las reglas de procesamiento
de las transacciones son complejas y deben ser flexibles para reflejar las nuevas
prácticas de negocios y fusiones. los sistemas de negocios también deben manejar
volúmenes cada vez mayor de transacciones en línea. El advenimiento del
comercio electrónico en la Web es la exposición de muchos sistemas de negocio a
negocio directamente a los consumidores. A pesar de la importancia de estos
sistemas, elativamente poco se ha escrito sobre su análisis, arquitectura o
patrones de diseño. Esperamos que el diseño y desarrollo de patrones en las
transacciones y el comercio electrónico crezca en los próximos años.
• Calidad de servicio para commercial-off-the-shelf (COTS) basado en sistemas
distribuidos. Los sistemas distribuidos, tales como streaming de vídeo, telefonía por
Internet, y en gran escala de sistemas de simulación interactiva, tienen una calidad
cada vez más estrictos de servicio (QoS). La Clave de los requisitos de QoS es
determinada por el ancho de banda y latencia, velocidad del CPU, tiempo de
acceso de memoria, y niveles de potencia. Para reducir el ciclo de desarrollo en
tiempo y costo, como los sistemas distribuidos son cada vez más desarrollados
utilizando múltiples capas de hardware COTS, sistemas operativos, middleware y
componentes. Históricamente, sin embargo, ha sido difícil de configurar los
sistemas basados en COTS y al mismo tiempo poder satisfacer las propiedades de
calidad de servicio múltiples, tales como seguridad, puntualidad, y tolerancia a
fallos.
53
• Reflective middleware. Este término describe un conjunto de tecnologías diseñadas
para gestionar y controlar los recursos del sistema en aplicaciones distribuidas
autónomas o semiautónomas. Las técnicas reflexivas middleware permiten
cambios dinámicos en el comportamiento de las aplicaciones de software de base
y la adaptación de los protocolos de hardware, políticas y mecanismos con o sin el
conocimiento de las aplicaciones o usuarios finales. Al igual que con calidad de
servicio de sistemas distribuidos, los patrones jugarán un papel clave en
documentar las mejores prácticas que puedan ayudar a garantizar la aplicación
efectiva del “Reflective middleware”.
• Optimización de los principales patrones. Mucha de la literatura actual se ha
centrado en que el rendimiento no sea un factor en la calidad de software. Aunque
esto puede ser aceptable en los ámbitos en los requisitos no funcionales, tales
como la facilidad de uso o de ampliación, son de suma importancia, otros ámbitos,
especialmente distribuidos e integrados en tiempo real el verdadero valor de los
sistemas es su eficiencia, escalabilidad, previsibilidad y fiabilidad por encima de
muchas cualidades de software.
54
Lenguajes de Descripción Arquitectónica (ADL’s)
Los lenguajes de descripción arquitectónica (ADL’s), son lenguajes para el modelado, la
descripción y prueba arquitectónica, permiten la representación de componentes,
conectores, configuraciones y restricciones de la arquitectura, así también están
pensados para permitir la evolución de la arquitectura, es decir son flexibles al cambio.
Un ADL es un enfoque lingüístico a la representación formal de una arquitectura
(Clements, 1998). Una arquitectura software incluye la descripción de elementos que
constituyen a los sistemas, las interacciones entre tales elementos, los patrones que
guían su composición y las restricciones sobre estos patrones (Mary Shaw, 1996).
Un ADL se centra en la estructura de alto nivel de la aplicación en su conjunto y no en los
detalles de implementación de cualquiera de sus módulos fuentes específicos (Vestal,
1993). Un ADL debe modelar explícitamente los componentes, los conectores y las
diversas configuraciones; más aún, para que sea realmente utilizable y útil debe facilitar
un soporte de herramienta para el desarrollo arquitectónico (Medvidovic, 1996). Por tanto,
un ADL es un lenguaje que proporciona características para modelar la arquitectura
conceptual de un sistema software, distintiva de la implementación del sistema: los ADL’s
proporcionan tanto una sintaxis concreta como un marco conceptual para la
caracterización de arquitecturas donde este refleja las características del dominio para los
que el ADL está enfocado y/o el estilo arquitectónico. El marco subsume la teoría
semántica subyacente del ADL (Garlan, 1997).
Los ADLs se remontan a los lenguajes de interconexión de módulos (MIL), pero se han
comenzado a desarrollar con su denominación actual a partir de 1992 o 1993, poco
después del impacto de la arquitectura de software como especialidad profesional. La
definición más simple es la de Alexander Wolf (Wolf, 1997) que define un ADL como una
entidad consistente en cuatro “Cs”: componentes, conectores, configuraciones y
restricciones (constraints).
Una de las primeras definiciones es la de Steve Vestal (Vestal, 1993) quien sostiene que
un ADL debe modelar o soportar los siguientes conceptos:
55
• Componentes.
• Conexiones.
• Composición jerárquica, en la que un componente puede contener una sub-
arquitectura completa.
• Paradigmas de computación, es decir, semánticas, restricciones y propiedades no
funcionales.
• Paradigmas de comunicación.
• Modelos formales subyacentes.
• Soporte de herramientas para modelado, análisis, evaluación y verificación.
• Composición automática de código aplicativo.
Por otra parte Shaw y Garlan (Shaw, 1994) comentan que en los ADLs los conectores
sean tratados explícitamente como entidades de primera clase y han afirmado que un
ADL tiene que proporcionar propiedades de composición, abstracción, reusabilidad,
configuración, heterogeneidad y análisis, lo que excluiría a todos los lenguajes
convencionales de programación y a los MIL.
Una de las especificaciones más claras y concisas es la de Medvidovic (Medvidovic,
1996), la cual señala que los ADL’s deben contener los siguientes elementos para ser un
lenguaje completo:
• Componentes
• Conectores
• Configuraciones arquitectónicas
• Soporte de herramientas
Un ADL con todas sus características forma parte de un entorno de desarrollo integrado
que, además, soporte la agregación de información, para que sea optimo la utilización de
un ADL durante la construcción de un sistema se deben presentar situaciones tales como.
• Sistema inicialmente descrito, basado en estilos arquitectónicos.
• Descripción de alto nivel del sistema, sea mediante casos de uso, escenarios u otra
alternativa más formal.
56
• Realización de diversos tipos de análisis o simulaciones del modelo arquitectónico
que permitan estimar los recursos necesarios y obtener el grado de satisfacción de
propiedades de calidad como el rendimiento, la disponibilidad o la seguridad.
• Refinamiento de componentes para cada tipo de análisis.
• Visualización de información de cada componente y de los resultados del análisis
sobre ellos.
• Codificación o generación de plantillas a partir de las descripciones de los
componentes.
Por otra parte con base a las propuestas de los autores antes señalados podemos
comentar que existen elementos comunes que los ADL’s deben contener, los cuales son
los siguientes:
• Componentes: Representan los elementos primarios de un sistema. Ejemplos
típicos serían clientes, servidores, filtros, objetos, pizarras y bases de datos.
• Conectores: Representan interacciones entre componentes. Ejemplos típicos
podrían ser tuberías (pipes), llamadas a procedimientos, protocolos cliente-
servidor, o conexiones entre una aplicación y un servidor de base de datos.
• Configuraciones o sistemas: Se constituyen como grafos de componentes y
conectores. Los sistemas también pueden ser jerárquicos, componentes y
conectores pueden subsumir la representación de lo que en realidad son complejos
subsistemas.
• Propiedades: Representan información semántica sobre un sistema más allá de su
estructura. Por ejemplo, cuestiones de seguridad, escalabilidad, dependencia de
bibliotecas o servicios específicos, configuraciones mínimas de hardware y
tolerancia a fallas.
• Restricciones: Representan condiciones de diseño que deben acatarse incluso en
el caso que el sistema evolucione en el tiempo. Por ejemplo, el número de clientes
que se puede conectar simultáneamente a un servicio.
• Estilos: Representan familias de sistemas, un vocabulario de tipos de elementos de
diseño y de reglas para componerlos. Ejemplos serían las arquitecturas de flujo de
datos basados en grafos de tuberías (pipes) y filtros, las arquitecturas de pizarras
basadas en un espacio de datos compartido, o los sistemas en capas.
57
• Evolución: Es el soporte de procesos de evolución permitiendo derivar subtipos a
partir de los componentes e implementando refinamiento de sus rasgos.
• Propiedades no funcionales: La especificación de estas propiedades es necesaria
para analizar la conducta de los componentes, imponer restricciones, mapear
implementaciones sobre procesadores determinados, etcétera.
Es destacable mencionar que los ADL’s deben contener un conjunto mínimo de requisitos,
para poder ser lo más óptimo posible al momento de su utilización independientemente
del tipo y la arquitectura que se desea modelar:
• Comunicación: Un ADL debe ser adecuado para comunicar una arquitectura a
todas las partes interesadas en la misma. Todas las estructuras de una
arquitectura deben poder definirse utilizando el ADL, incluyendo tanto aquellas que
son estáticas como las que son dinámicas. Los diversos tipos de componentes y
conectores deben estar identificados en cada una de las estructuras.
• Análisis y Validación: Un ADL debe dar soporte a las tareas de creación de la
arquitectura, refinamiento y validación
• Propósito General: Un ADL debe proporcionar la capacidad para representar la
mayoría de los estilos arquitectónicos habituales.
• Abstracción: Un ADL debe tener la capacidad de proporcionar estructuras del
sistema que expresen información arquitectónica y que, al mismo tiempo, omitan
toda aquella información sobre la implementación que no sea arquitectónica.
• Derivación: El ADL debe proporcionar una base para fomentar la implementación.
Sobre todo, debe posibilitar la agregación de información extra a la especificación
ADL de manera que permita que una especificación final del sistema sea derivada
del ADL.
• Alternativas de Implementación: Si el ADL puede expresar información de nivel de
implementación, debe tener posibilidades para optar a más de una implementación
de las estructuras de nivel arquitectónico del sistema.
Es destacable el mundo de posibilidades que un ADL permite a un arquitecto de software
de manera ordenada y documentada.
58
Como se mencionó existen muchos ADL’s específicos para diversos tipos de enfoques y
otros más genéricos, es por eso que basado en características y en consejos acerca de
utilizar software libre se ha optado por utilizar ACME ARMI para describir el caso de
estudio en este trabajo.
Lenguaje AcmeArmi
Acme se define como una herramienta capaz de soportar el mapeo de especificaciones
arquitectónicas entre diferentes ADLs, o en otras palabras, como un lenguaje de
intercambio de arquitectura.
El proyecto Acme comenzó a principios de 1995 en la Escuela de Ciencias de la
Computación de la Universidad Carnegie Mellon. Destacados arquitectos y
sistematizadores tales como David Garlan y Robert Monroe han hecho posible el
desarrollo de Acme en obras como el reporte “Capturing software architecture design
expertise with Armani” de Monroe (Monroe. 1998) y el artículo “An architectural
interchange language” de Garlan, Monroe y Wile (Garlan, 1997).
La motivación fundamental de Acme es el intercambio entre arquitecturas e integración de
ADLs.
Acme soporta la definición de cuatro tipos de arquitectura: la estructura, las propiedades
de interés, las restricciones, los tipos y estilos.
Acme-Armani se constituyó en un lenguaje de tipo ADL, especializado en la descripción
de la estructura de un sistema y su evolución en el tiempo. Es un lenguaje puramente
declarativo que describe la estructura del sistema y las restricciones a respetar.
De alguna manera, la naturaleza de Acme-Armani captura también la experiencia de los
arquitectos, señalando su vinculación con la práctica de los patrones arquitectónicos, en
este caso patrones de diseño.
59
Armani se basa en siete entidades para describir las instancias del diseño: componentes,
conectores, puertos, roles, sistemas, representaciones y propiedades. Para capturar las
experiencias y mejores prácticas, Acme-Armani implementa además otras seis entidades
que son, tipos de elementos de diseño, tipos de propiedades, invariantes de diseño,
heurísticas, análisis y estilos arquitectónicos.
Figura 4, Pantalla de AcmeStudio.
60
CAPITULO 2, Patrones Arquitectónicos desde perspectivas actuales
En este capítulo se busca hacer una recopilación que a su vez sirva como referencia de
los patrones arquitectónicos que existen en la actualidad y son aplicados por muchos
sistemas robustos o son foco de atención de empresas de creación de software y
lenguajes de programación como Sun Microsystems y Microsoft.
Patrones Arquitectónicos como el patrón MVC (Modelo Vista Controlador), son tema de
este capítulo.
61
Patrón Arquitectónico Modelo Vista Controlador (MVC)
El patrón MVC es un patrón arquitectónico de tres capas conceptuales, fue definido en un
principio para sistemas usuario-máquina y en la actualidad es aplicado a los Sistemas de
Información Distribuidos.
El patrón MVC no solo define tres capas de una arquitectura 3-tier (Presentación, Lógica
de negocios y datos), más bien define las responsabilidades y las dependencias
dependiendo de los objetivos que representa en tres paradigmas (Modelo, Vista y
Controlador).
Modelo (Model):
o Encapsula los datos y las funcionalidades.
o Es independiente de cualquier representación de salida y/o
comportamiento de entrada.
o Representa toda la información con la que opera la aplicación.
o Gestiona el comportamiento y los datos del dominio.
o Responde a peticiones de información que vienen de la vista.
o Responde a instrucciones de cambio de estado, provenientes del
controlador.
Vista (View):
o Muestra la información al usuario.
o Pueden existir múltiples vistas del modelo.
o Cada vista tiene asociado un componente controlador.
o Gestiona la representación de la información de la aplicación.
62
Controlador (Controller):
o Reciben las entradas, es decir, los eventos que codifican los
movimientos o clics de botones del mouse, clics a botones o teclas, en
general todo tipo de evento que se genera de la vista.
o Llama a la lógica del negocio para procesar y producir una respuesta.
o Interpreta las entradas del usuario, informando al modelo y a la vista lo
que surja de dichas entradas.
El patrón MVC gráficamente cuenta con tres componentes y sus relaciones entre estos, y
que al final de un procesamiento utilizan la vista como entrada y salida de las peticiones
del usuario Figura 6.
Figura 5, Diagrama de secuencias que muestra gráficamente el patrón MVC.
El diagrama de la figura 5, explica el patrón MVC y muestra como un usuario genera una
evento y este es pasado por toda la arquitectura para que al final entregue una respuesta
como consecuencia del evento generado por el usuario.
1. El usuario introduce el evento.
2. El Controlador recibe el evento y lo traduce en una petición al Modelo.
3. El modelo (si es necesario) llama a la vista para su actualización.
4. Para cumplir con la actualización la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.
63
Patrón Arquitectónico Broker
Es un patrón arquitectónico aplicado en la estructuración de sistemas distribuidos en los
cuales es necesaria la interacción remota de componentes altamente desacoplados, lo
anterior se logra al introducir un componente Broker cuya función principal es lograr el
desacoplamiento de los clientes y de los servidores, también registra a los servidores,
logrando de esta forma que los servicios que estos ofrecen estén disponibles a los
posibles clientes.
Además de los componentes Broker, servidores y clientes, este patrón está también
constituido por los componentes de tipo Proxy y por los componentes de tipo Bridges.
Los Proxies, pueden ser de dos tipos: client-side-proxy y server-side-proxy, los proxies del
primer tipo pueden ser considerados como una capa entre los clientes y el Broker, la cual
proporciona transparencia puesto que gracias a ella un servidor remoto aparece ante un
componente cliente como local.
Los proxies del segundo tipo son análogos a los del primer tipo, sin embargo difieren en
que son responsables de recibir peticiones y desempaquetarlas con el fin de llamar al
servicio correcto, además se encargan de recibir resultados y excepciones del servidor,
empaquetarlos y enviarlos al Broker. Por otra parte, los componentes Bridges tienen como principal función ocultar los detalles
de implementación de los mecanismos de interoperatividad entre dos Brokers; así, si
estos corren en redes distintas, pueden, no obstante, comunicarse entre sí
independientemente de los sistemas operativos sobre los cuales ellos corren.
En resumen, cabe destacar que las características de calidad más importantes que se
ponen en evidencia para el patrón Broker son: la interoperabilidad, la transparencia de
ubicación, la capacidad de manejar los cambios con eficiencia (flexibilidad) y la
adaptabilidad (portabilidad).
64
Patrón Componentes Comportamiento Características de calidad
Broker Broker, proxies,
servidores, clientes,
bridges
dinámico Cambios a nivel
dinámico,
extensibilidad,
reutilización,
portabilidad
(adaptabilidad),
transparencia
respecto
Tabla 1, Características del patrón arquitectónico Broker
El patrón arquitectónico de broker introduce una capa de servicios de software que realiza
las operaciones de conversión y acoplamiento necesarias para simplificar el intercambio
de información entre los sistemas.
Gracias a las facilidades que brinda por este patrón y utilizando los mecanismos
apropiados es posible reemplazar gradualmente la funcionalidad de un sistema al mismo
tiempo que se integran los datos que contiene, sin esperar a que esto suceda en una
etapa avanzada.
Objetivo del patrón Broker
El patrón Broker arquitectónico puede ser usado para estructurar sistemas de software
distribuidos con componentes que interactúen de forma disociada por las llamadas de un
servicio remoto. Un componente Broker es responsable de coordinar las cuestiones de
comunicación, tales como solicitudes de reenvío, así como para la transmisión de
resultados y excepciones.
Motivación
La principal motivación que tuvo el autor para desarrollar este patrón es el poder introducir
un componente intermediario para lograr un mejor desacoplamiento de los clientes y
servidores.
65
• Lo ideal para los Servidores sería poderse registrar en un Broker y poner sus
servicios a disposición de los clientes a través de interfaces de método.
• Para los clientes tener acceso a la funcionalidad de los servidores mediante el
envío de peticiones a través del Broker.
A las tareas incluyen la localización de los Brokers en el servidor apropiado, la solicitud de
reenvío en el servidor y la transmisión los resultados y excepciones al cliente.
Al usar el patrón Broker, una aplicación debe poder tener acceso a servicios distribuidos,
simplemente mediante el envío de mensaje al objeto apropiado, en lugar de centrarse en
cosas de bajo nivel de comunicación entre procesos.
Además, la arquitectura Broker es flexible, ya que permite un cambio dinámico, adición,
supresión y traslado de objetos.
• El patrón Broker reduce la complejidad que implica en el desarrollo de aplicaciones
distribuidas, ya que hace que la distribución transparente para el desarrollador,
logra este objetivo mediante la introducción de un modelo de objetos en los que se
distribuyen los servicios y se encapsulan en los objetos.
• Los sistemas de Broker por tanto, ofrecen una manera a la integración de dos
tecnologías fundamentales: la distribución y la tecnología de objetos.
Usos Conocidos del patrón arquitectónico Broker
Este patrón se ha utilizado en los siguientes sistemas:
• CORBA. Common Object Request Broker Architecture, es una tecnología orientada
a objetos para la distribución de objetos en sistemas heterogéneos. CORBA fue
definido por el Object Management Group y utiliza el patrón arquitectónico Broker.
Se fundamentan en dar uso a este patrón para mejorar el apoyo de la
interoperabilidad de los clientes y los objetos servidor buscando disponibilidad a
través de un lenguaje de definición.
66
• IBM SOM / DSOM. Se trata de un sistema CORBA Broker compatible que combina
la definición de la interfaz CORBA y un idioma con un protocolo binario.
• Microsoft OLE 2.x utiliza el patrón Broker y define un estándar binario para la
exposición y el acceso a interfaces de servidor.
• World Wide Web utiliza el patrón bróker para que los navegadores actúen como
intermediarios y los servidores de WWW como proveedores de servicios.
• ATM-P. ATM-P. De Siemens este proyecto de casa se creó con el fin de construir
un sistema de conmutación de telecomunicaciones basada en la aplicación de ATM
Message Broker como una variante del sistema.
Características Benéficas del Patrón Arquitectónico Broker
• Variabilidad
• Extensibilidad de componentes
• Interoperabilidad entre
• Transparencia
• Portabilidad
67
Patrón Arquitectónico Pipes and Filters
Contexto
El patrón arquitectónico Pipes and Filters proporciona una estructura para los sistemas
basados en flujo de procesos de datos. Cada paso de un proceso se encapsula en un
componente filtro. Los datos se pasan a través de tubos entre filtros adyacentes. Re
combinar filtros permite construir familias de sistemas relacionados.
Motivación
El patrón arquitectónico Pipes and Filters divide la tarea de un sistema en varios pasos de
procesamiento secuencial. Estas medidas están conectadas por el flujo de datos a través
del sistema, los datos de salida de un paso es la entrada a la fase siguiente.
Cada paso del proceso es ejecutado por un componente de filtro Un filtro consume y
entrega datos de forma incremental, en contraste con el consumo de todas sus
aportaciones antes de producir cualquier salida, para lograr una baja latencia y permitir el
procesamiento paralelo real. La entrada al sistema es proporcionada por una fuente de
datos como un archivo de texto.
La fuente de datos, los filtros y los datos se conectan de forma secuencial por tuberías.
Cada tubo implementa el flujo de datos entre los pasos de procesamiento adyacentes. La
secuencia de filtros combinados por tuberías se denomina línea de proceso.
La aplicación de este patrón ofrece que se puedan combinar y reutilizar en diferentes
aplicaciones:
• Muchas aplicaciones puedan procesar grandes volúmenes de elementos de datos
similares. Por ejemplo, los sistemas comerciales puedan manejar cotizaciones de
bolsa, los sistemas de facturación de telecomunicaciones puedan manejar los
68
registros de llamadas de datos, sistemas de información y gestión de laboratorio
puedan manipular los resultados de pruebas.
• El tratamiento de los elementos de datos se puede desglosar en una secuencia de
transformaciones individuales. Por ejemplo, el procesamiento de mensajes XML
normalmente implica una serie de transformaciones XSLT.
Usos Conocidos
Este patrón se ha utilizado en los siguientes sistemas:
• UNIX hizo popular al patrón Pipes and Filters con los shells de comandos y
programas de filtro.
• CMS filters extiende los sistemas operativos mainframes de IBM apoyando de esta
manera su arquitectura.
• LASSPTools contiene programas de filtro que puede ser combinados utilizando
tuberías de UNIX.
Características Benéficas
• Eficiencia
• Procesamiento
• Flexibilidad
69
CAPITULO 3. Propuesta de solución usando el Patrón
Arquitectónico Piramidal y la Arquitectura Piramidal de Sistemas
Distribuidos
En este capítulo se explicará a detalle el funcionamiento, estructura, características, flujo
de trabajo y ventajas que tiene la propuesta de los patrones piramidales.
También se explicará el funcionamiento, estructura y ventajas que tiene la propuesta de
los patrones piramidales tomando como proyecto de pruebas la necesidad que se tiene de
masificar una solución de pagos en la que se tiene un sistema de Terminal Punto de
Venta que trabaja sobre terminales móviles de forma convencional, con una Arquitectura
cliente servidor, entre las terminales y el autorizador de transacciones.
Se harán pruebas y se especificarán los detalles de la propuesta con el fin de llegar a un
ambiente productivo exitosamente.
70
El Patrón Piramidal
Recordemos que en la arquitectura de software dicho a grandes rasgos los patrones son
un modelo a seguir para lograr un objetivo. Dicho lo anterior los patrones piramidales no
son la excepción.
El patrón piramidal pretende ser un modelo a soluciones basadas en elementos que se
comunican entre sí, con la característica de que la comunicación sea jerárquica. Es decir
que exista un orden entre elementos y que cada elemento se comunique solo con un
elemento del siguiente nivel según el orden en el que se encuentren.
El patrón piramidal se orienta a sistemas distribuidos que como se mencionó requieren de
una comunicación jerárquica, ya sea por diseño o por seguridad o para evitar
inconsistencia de datos.
Por mucho tiempo la forma piramidal se ha utilizado para denotar jerarquía entre los
niveles que la conforman. El patrón piramidal denota tres niveles en su estructura, el nivel
base, el nivel de interpretación y el nivel fuente:
Figura 6. Niveles del Patrón Piramidal
71
El nivel base es el primer nivel de la pirámide y del cual se generan las peticiones o
solicitudes de procesamiento de datos. El nivel base contiene todos los componentes que
interactúan directamente con el usuario final.
Por otra parte el nivel de interpretación, es el que tiene los componentes que validan con
reglas de negocio las peticiones del nivel base, procesarlas y enviarlas al siguiente nivel
(Nivel Fuente).
El nivel fuente es el último en la pirámide y contiene el procesamiento final de la petición,
este nivel contiene componentes que proveen diversos servicios de terceros y por
consecuencia la arquitectura de este nivel se considera como una caja negra.
Características de Niveles
• Nivel Base:
o Los componentes que lo conforman se encuentran instalados de forma local.
o Pueden estar instalados en diferentes escenarios.
o No importa el lenguaje en el que se hayan desarrollado.
o No importa el sistema operativo sobre el que se encuentren instalados.
o Se comunican solo con el nivel de interpretación a través de un lenguaje o
protocolo de comunicación estándar, como XML, por HTTP POST, GET o
SOAP.
o Por el tipo de comunicación con el nivel de interpretación los componentes
del nivel base deben tener salida a internet o intranet.
• Nivel de Interpretación
o Es un nivel en el que sus componentes se encuentren centralizados en un
servidor.
o Los componentes de este nivel cuentan con reglas de negocio que validan
las peticiones del nivel base y para generar una respuesta entendible para
este.
o Los componentes de este nivel se comunican con los componentes del nivel
base a través del mismo protocolo o lenguaje de comunicación.
72
o Este nivel decide si la petición que se hace en el nivel base puede ser
enviada al nivel fuente o no. Si la petición no puede ser procesada se
genera el mensaje correspondiente y se envía de regreso la petición al nivel
base, de lo contrario si la petición si puede ser procesada se genera un
mensaje entendible para el nivel fuente y se envía.
o Los componentes de este nivel se comunican con los componentes del nivel
fuente a través de un medio que los componentes del nivel fuente
establecen.
• Nivel Fuente
o En este nivel se contienen los componentes que proveen diversos servicios
de terceros.
o Este nivel es el último nivel de la pirámide y es donde se procesa la
respuesta final de la petición que se genera en el nivel fuente y que el nivel
de interpretación considera correcto.
o La arquitectura de los componentes o la operación de estos se considera
como una caja negra ya que provienen de servicios de terceros.
Flujo de Operación del Patrón Piramidal
1. Un usuario a través de un componente del nivel base genera una petición.
2. El componente del nivel base genera un mensaje que cumple con características
comunes entendibles para algún componente del nivel de interpretación, se
empaqueta el mensaje y se envía a través de un protocolo de comunicación.
3. El componente del nivel de interpretación que fue invocado por el componente del
nivel base, recibe el mensaje y lo interpreta.
4. El componente del nivel de interpretación valida el mensaje y decide si puede ser
procesado y enviado a algún componente del nivel fuente o si debe ser retornado
al nivel base.
73
5. Una vez que el mensaje que envía el componente del nivel base es correcto el
componente del nivel de interpretación, genera un nuevo mensaje entendible para
el componente correspondiente del nivel de servicios o nivel fuente, es por esto
que este nivel se le llama nivel de interpretación.
6. El componente o servicio del nivel fuente recibe la petición del nivel de
interpretación, la procesa y genera un nuevo mensaje con la respuesta para
enviarlo al componente del nivel de interpretación.
7. El componente del nivel de interpretación recibe la respuesta del nivel fuente, la
interpreta y genera un nuevo mensaje con el lenguaje o protocolo establecido con
el nivel base.
8. Finalmente el nivel base recibe la respuesta del procesamiento, la interpreta y
genera las acciones necesarias para notificar dicha respuesta al componente que
dio origen a la solicitud.
En resumen el patrón piramidal toma como el nivel más alto de la pirámide el o los
componentes que provean la información final de una petición, es por esto que se les
llama componentes fuente.
Por otra parte, el componente en el nivel más bajo de la pirámide (nivel base), hace una
petición o una solicitud de información la cual la debe recibir el siguiente nivel de la
pirámide (nivel de interpretación) para que uno de los componentes que lo conforman
pueda procesarla y pasarla al componente fuente quien provee el resultado final del
procesamiento de la información y lo devuelve de la misma manera pero ahora
descendentemente hasta llegar al componente base que dio origen a la solicitud.
Si descomponemos al patrón piramidal en capas cada nivel debería representar una de
las siguientes capas:
• Lógica de Presentación. (Nivel Base)
• Lógica de Dominio. (Nivel de Interpretación)
• Lógica de Fuente de datos.
74
Es importante señalar que el patrón piramidal es la primicia para generar una arquitectura
piramidal de sistemas distribuidos.
Características Generales
• Deben existir forzosamente tres niveles que son la base, interpretación y la fuente.
• Cada nivel puede tener múltiples componentes que tengan la misma jerarquía de
procesamiento de la información.
• Los componentes que se encuentran en cada nivel son independientes no es
necesario que exista comunicación entre ellos.
• La comunicación entre niveles debe ser jerárquica y puede ser ascendente y
descendente.
• Pueden existir peticiones simultáneas, pero cada una debe cumplir un ciclo
jerárquico en la pirámide.
• Dentro del nivel de interpretación pueden existir validaciones de asignación para
emitir la petición a uno o a otro componente del mismo nivel.
• El patrón piramidal puede ser considerado genérico por su estructura y modo de
procesamiento, más adelante se comentará el por qué se le puede considerar
genérico.
75
Ventajas del Patrón Piramidal
• Facilita la colocación de la solución sobre cualquier plataforma, sin importar el
lenguaje de programación, es debido a que todos los niveles se comunican a
través de protocolos estándar de comunicación.
• Los componentes del nivel base pueden ser cualquier “cosa” (cualquier medio),
que tenga la facilidad de conectarse a internet o intranet y que pueda ejecutar un
programa.
• Se puede tener control tanto del nivel base como del nivel de interpretación.
• No tiene restricciones sobre el modo en el que se comuniquen los niveles de la
pirámide, puede ser cualquier protocolo de comunicación estándar.
• Es posible hacer llegar a los usuarios finales de una forma organizada y segura las
ventajas que ofrecen servicios de terceros.
• Al tener centralizados lo componentes del nivel de interpretación, se tiene mayor
control de las peticiones que se hacen a los servicios de terceros y así también se
tiene control de las respuestas que ofrecen dichos servicios, En este nivel se debe
llevar el registro y administración de las peticiones y respuestas.
• Los usuarios para tener acceso a un servicio pueden estar en cualquier sitio en el
que se encuentre un componente del nivel base, por ejemplo si un componente del
nivel base es una aplicación para celular, el usuario podría acceder a un servicio
desde su dispositivo.
• Por la estructura de niveles cualquier operación realizada en el nivel base, se
registra en el nivel de interpretación y posteriormente se puede acceder al registro
de dichas operaciones a través de un componente base que haga una petición de
consulta al nivel de interpretación.
76
• Los componentes del nivel base solo se preocupan por establecer una sola forma
de comunicación, es decir la que establezcan con el nivel de interpretación, por
definición el nivel base no tiene forma de comunicarse con el nivel fuente, lo que da
ventaja a integrar en los componentes del nivel base solo un protocolo de
comunicación.
• Al estar centralizado el nivel de interpretación y al ser servicios los del nivel fuente,
los componentes del nivel base puede acceder en cualquier momento a los
servicios.
• Al ser un lenguaje o protocolo estándar el que se utiliza para comunicarse con el
nivel de interpretación se facilita la integración de nuevos tipos o escenarios en el
nivel fuente.
77
Múltiples plataformas y
múltiples dispositivos
Componentes
centralizados sobre
servidores en diferentes
Múltiples servicios de
terceros.
El Patrón Piramidal desde una perspectiva genérica
Una de las pretensiones que se tienen con el patrón piramidal es que este pueda ser
aplicado como solución a problemas de aplicación en las que se requiera tener acceso a
servicios.
Se puede considerar genérico por las siguientes causas.
1. No importa el lenguaje de programación en ninguno de los niveles.
2. No importa el sistema operativo en ninguno de los niveles.
3. La comunicación entre niveles es estándar.
4. Solo basta con establecer el medio de comunicación entre niveles para generar
peticiones y respuestas.
5. No importa el tipo de dispositivo que se encuentre en el nivel base, pueden ser
dispositivos móviles, laptops, PC, etc.
6. El nivel de interpretación solo debe ser un server centralizado con salida a
internet.
Figura 7, Patrón Piramidal, un enfoque genérico
78
Introducción al caso de estudio
Como es notable una aplicación que se encarga del manejo de transacciones bancarias
es de suma importancia el manejo correcto y seguro de la información.
Para este caso de estudio se tomará en cuenta una aplicación que hace cobros
bancarios, la cual tiene como objetivo realizar cobros bancarios con tarjeta presente y no
presente.
La Aplicación de Cobros Bancarios es una plataforma que permite a las compañías,
consolidar, y hacer más eficiente la gestión de cobros con tarjeta bancaria acoplándose a
las estrategias del negocio.
La Aplicación de Cobros Bancarios ofrece diferentes servicios de cobro para cubrir las
necesidades de cada empresa, garantizando la seguridad de las transacciones en cada
una de ellas.
Modelo Básico de Operación
Existe un modelo básico de operación que aplica de manera genérica a todos los medios
de pago. El vendedor realiza una venta a un cliente final que en su pago emplea a una
entidad financiera.
La entidad financiera es la que garantizará el pago al banco en la que el Comercio
mantiene sus depósitos, realizando estas dos entidades todo un intercambio,
compensación y liquidación de flujos monetarios para que se lleve a cabo el cobro/pago
derivado de la venta realizado entre vendedor y comprador. De esta forma, las distintas
partes que configuran el modelo base son las siguientes:
• El cliente final, comprador.
• El Comercio, vendedor.
• La entidad financiera Emisora, banco del cliente final que emite alguna forma de
título garantizando (medio de pago) y respaldando el pago de su cliente.
79
• La entidad financiera Adquirente, banco del Comercio, que adquiere los títulos
anteriores y los deposita al Comercio.
• Un sistema para intercambiar, compensar y liquidar estos títulos para que se
produzcan de forma segura los flujos monetarios entre los bancos Emisor y
Adquirente.
Figura 8, Partes que conforman el modelo base
80
Procesamiento de Medios de Pago Electrónicos
El procesamiento de tarjetas de crédito ocurre en dos pasos: la autorización en tiempo
real y la compensación de los fondos que fueron autorizados.
Autorización
Una transacción comienza cuando el tarjetahabiente presenta su tarjeta de pago al
Comercio para adquirir bienes o servicios. La información de la transacción es enviada
electrónicamente al Banco Emisor para solicitar la autorización del cobro cargo. El banco
verifica que la tarjeta sea válida, evalúa si tiene saldo disponible, checa el código de
seguridad, y regresa una respuesta: Aprobada, Rechazada u otras. El Comercio recibe la
respuesta segundos después de hacer la solicitud.
Liquidación y Compensación
La compensación bancaria es una forma de extinción de deudas entre instituciones
financieras por la que dos o más de ellas equilibran sus deudas recíprocas. La
liquidación es la transferencia de fondos, proceso por el cual una operación es saldada.
Diariamente se compensan las cuentas bancarias y se liquidan los fondos de las
transacciones realizadas en el periodo. Una vez realizada la compensación, se hace un
cargo al Banco Emisor y se transfieren los fondos a la cuenta del Comercio. El tiempo que
tarda el dinero en estar disponible en la cuenta del Comercio, depende del Banco del
Adquirente. Existen siete entidades (Comercio, consumidor, Banco Emisor, Banco
Adquirente, procesador de pagos, servicios de Gateway, asociaciones de tarjetas)
involucradas en una transacción. El Comercio depende de terceros para asegurar que el
consumidor puede pagar por la transacción y para autentificar que el consumidor está
autorizado para realizar la compra.
Problemática
El problema nace por la necesidad de poder implementar la plataforma de La Aplicación
de Cobros Bancarios en diferentes escenarios con el fin de poderlo masificar y utilizar
81
desde diversos dispositivos, pero siempre cumpliendo con diferentes estándares de
seguridad y resguardo de la información.
Con el objetivo de acrecentar el número de clientes potenciales de la aplicación y así
poder llevar la solución a muchos más dispositivos y en consecuencia a más clientes.
También el problema nace de la necesidad de ofrecer un producto distinto a terminales
punto de venta, tradicionales, se pretende ofrecer una solución centralizada con diferentes
posibilidades de accesibilidad e integración. Una solución versátil, que permita utilizar
componentes prediseñados listos para usarse, o bien, ofrecer herramientas para que
aplicaciones ya existentes puedan integrar la solución mediante componentes ya
elaborados.
Explicación Técnica de la Problemática
Técnicamente la aplicación de Cobros Bancarios cuenta con una arquitectura cliente
servidor la cual básicamente se trata de componentes físicos de software y hardware que
se encuentran instalados en un ordenador cliente y que hacen peticiones a los servicios
bancarios a través de mensajes ISO 8583.
El problema se encuentra en que cuando se necesita integrar una nueva plataforma o un
nuevo dispositivo o una nueva aplicación prácticamente se requiere regenerar la
aplicación y adaptarla al lenguaje de programación correspondiente, lo que es una tarea
de alto costo, prácticamente se tiene una aplicación por cada escenario o interfaz.
Esta situación detiene bastante el objetivo de masificar la solución y de llevarla a diversos
ambientes y escenarios.
Con la arquitectura actual se requiere planear un proyecto completo cada vez que se
pretenda implementar la solución en un escenario distinto a los contemplados.
Este problema limita mucho la actividad de negocio y cierra la puerta a clientes
potenciales que requieren cosas distintas a lo que se ofrece.
82
Figura 9, Arquitectura Actual de la aplicación de cobros bancarios
Propuesta de Solución a la problemática
A continuación se describen los pasos para el procesamiento electrónico de una
transacción, aplicando un modelo arquitectónico en niveles.
1. El Cliente paga al Comercio por un bien o servicio, proporcionando los datos de la
tarjeta de pago, en el punto de venta de su elección.
2. El Comercio somete una transacción de tarjeta de crédito al Gateway de Pagos en
nombre del cliente, a través de una conexión segura desde diferentes canales de venta:
Internet, mostrador, correo, terminal móvil.
83
3. El Gateway de Pagos, cumpliendo con los requisitos de seguridad y transmisión,
traduce la información de la transacción en un mensaje de solicitud de autorización y lo
transmite al Procesador.
4. El Procesador en ruta la solicitud de autorización al Banco Emisor de la tarjeta para su
autorización.
5. El Emisor aprueba o declina la transacción en base a los fondos disponibles del Cliente
y pasa el resultado de la transacción de regreso al Procesador.
6. El Procesador transmite el resultado de la transacción al Gateway de Pagos.
7. El Gateway de Pagos almacena el resultado de la transacción y lo envía al Comercio.
8. El Comercio termina la transacción y libera la mercancía al Cliente.
9. El Banco Emisor transfiere al Procesador los fondos de la operación (precio de venta -
la tasa de intercambio).
10. El Procesador envía los fondos al Banco Adquirente ((precio de venta - la tasa de
intercambio).
11. El Adquirente transfiere los fondos en la cuenta del Comercio (precio de venta menos
tasa de descuento).
12. El Banco Emisor carga el monto de la transacción (precio de venta + cuotas por
servicio e intereses sobre el saldo) a la cuenta del tarjetahabiente y le envía su estado de
cuenta de manera mensual.
84
Figura 10, Procesamiento Electrónico de Transacciones.
Con el fin de solucionar la problemática presentada, se harán pruebas de implementación
utilizando el patrón arquitectónico piramidal.
El patrón piramidal principalmente establece tres niveles sobre los cuales se encuentra
distribuida una aplicación.
• Nivel Base.
• Nivel de interpretación.
• Nivel Fuente.
85
Como recordamos el nivel base es en dónde literalmente nacen las peticiones de
procesamiento de la información, en este nivel se pueden encontrar gran cantidad de
vistas que generen solicitud de información.
Para este caso principalmente interesa este nivel, ya que es aquí en donde el negocio
pretende masificar su servicio, permitiendo abrir las posibilidades a más clientes con
distintas plataformas integradas.
Con la definición que se tiene del patrón piramidal, podemos atacar el punto de la
masificación interponiendo en el nivel base componentes integrables a diferentes
lenguajes tales DLL’s, Jar’s, OCX, etc. En resumen bibliotecas que puedan implementarse
en diferentes lenguajes. También es conveniente generar vistas para el nivel base que
estén montadas sobre plataformas Web, con esto garantizamos parte del problema de la
plataforma. Otro aspecto en este nivel es realizar vistas con similar ya compiladas para
cada plataforma que se deseé abarcar.
En resumen la sugerencia para el nivel base es adaptar las vistas en componentes
integrables para múltiples lenguajes tales como bibliotecas, generar una vista instalable
que integre una de las bibliotecas para los clientes que solo deseen acceder a la
funcionalidad de la aplicación e cobros bancarios sin añadir alguna interfaz propia.
Generar una interfaz web que permita a los clientes ingresar y generar cobros desde
portal para casos muy específicos realizar la interfaz sobre la plataforma de la aplicación
pero basar la funcionalidad de La Aplicación de Cobros Bancarios en alguna biblioteca.
Figura 11, Componentes del Nivel Base
86
Es necesario generar o acordar un protocolo de comunicación vía web entre el nivel base
y el nivel de integración, para este caso se utilizarán web services basados en SOAP.
Una vez que se llega a un acuerdo con el tipo de comunicación, se debe definir un
lenguaje de consultas que exista entre el nivel de interpretación y el nivel fuente, para este
caso se utilizará XML.
¿Por qué es conveniente usar XML? Porque los negocios de hoy en día dependen de la
información y los datos pueden provenir de varios orígenes de información distintos:
bases de datos, páginas Web, archivos de hojas de cálculo y correo electrónico, por
mencionar sólo algunos. XML permite trabajar con más datos de más orígenes y hacer
más cosas con esos datos. En general lenguaje XML resulta muy útil. Sin embargo una
desventaja de este lenguaje es que el navegador o el "visualizador" que el usuario utilice,
no cuente con un Parser capaz de visualizar el contenido del documento.
Figura 12, El Lenguaje XML
En cuanto al nivel de interpretación será aquí en donde se defina un web service que se
comunicará con todas las vistas y responderá a todas las peticiones del nivel fuente, este
nivel se considera como el de más tráfico ya que pasan por el tanto peticiones de los
clientes como respuestas de servicios de terceros.
87
Recordemos que en el nivel de interpretación se definen las reglas principales del negocio
y se almacenan los datos, es decir aquí se encuentran las bases de datos y los servicios
propios de La Aplicación de Cobros Bancarios.
En este caso se utilizará una base de datos Oracle 9i, en donde se almacenarán todos los
registros de las transacciones, así como los usuarios, privilegios, catálogos y demás
registros propios del comercio y necesarios para la correcta operación del sistema en
general.
El lenguaje que se utilizará para los componentes que se encuentren en el nivel fuente
será Java utilizando los beneficios que ofrece el framework Spring a través de Web
Services.
Este Web Service principalmente se encargará de tomar las peticiones de los clientes
recibiendo un solo parámetro de tipo String en cada uno de sus métodos, este parámetro
deberá estar encriptado y en él se contendrá el XML con los nodos correspondientes a la
petición que esté haciendo el componente que se encuentre en el nivel base.
El objetivo de recibir un solo parámetro de tipo String y no un objeto es porque el String es
un tipo de dato muy estándar que prácticamente cualquier lenguaje de programación tiene
y con esto podemos garantizar que se establezca una comunicación sin problemas de
compatibilidad entre los componentes del nivel base y del nivel fuente.
Figura 13, Componentes del Nivel de Interpretación
Para el nivel fuente el lenguaje y mensajería es establecido por el tercero dueño del
servicio que se desea explotar, en este caso existirá una comunicación por medio de web
88
servcies y enviando como parámetros mensajes de tipo ISO 8583, los cuales se enviaran
entre el procesador y La Aplicación de Cobros Bancarios.
El procesador es una empresa que dedica a recibir peticiones o solicitudes de cobros
bancarios y los envía a los diferentes bancos emisores para su autorización o rechazo.
Procesador Bancario Banco
Internet
ISO
COMPONENTES DEL NIVEL FUENTE
Figura 14, Componentes del Nivel Fuente
A continuación, se mostrará el flujo completo de la pirámide, tomando los diferentes
niveles y los componentes que los conforman.
89
Figura 15, Patrón Piramidal
Flujo de Implementación del Patrón Piramidal
A continuación se explica el flujo utilizando la propuesta del patrón piramidal.
1. Se deben especificar las reglas de negocio a nivel base de datos, así como
establecer restricciones y normalización de la misma.
2. Se sugiere generar procedimientos almacenados y transacciones para la
manipulación de la base de datos y no agregar queries al código de la aplicación.
3. Posteriormente es conveniente iniciar con el análisis y programación del Web
Service que se instalará en el nivel de interpretación, en este Web Service se
deben establecer reglas de negocio acorde a las necesidades.
4. Establecer protocolos de comunicación y conexión con servicios de terceros
mismos que se pretenden consumir y que se encuentran en el último nivel de la
pirámide (nivel fuente).
90
5. Se debe establecer el lenguaje y medio de comunicación para la interacción entre
el nivel de interpretación y el nivel base.
• Se recomienda utilizar el lenguaje XML, y así generar esquemas bien
definidos con tags que representen los datos que se desean manipular o
consultar.
• Se recomienda que cada método del Web Service reciba parámetros de tipo
String en este caso se recomienda recibir solo un parámetro encriptado por
algún método genérico y no usar un método de encripción propio de algún
lenguaje, este parámetro contendrá el XML con la información de la
operación que se realiza.
6. Una vez establecidos los XML de intercambio se debe generar el programa cliente
el cual será el que se instale en las PC’s de los usuarios finales y de donde se
generarán las peticiones, este programa representa el nivel base de la pirámide.
• En estas vistas existirán validaciones, interacción con hardware y en general
lo necesario para generar los datos de las peticiones y para recibir la
respuesta a las mismas.
• Las vistas del nivel base generan los XML de petición para invocar el Web
Service que se encuentra en el nivel de interpretación, así también reciben
los XML de respuesta para generar el flujo correspondiente.
91
Establecer
protocolos de
comunicación y
conexión con
servicios de
terceros Análisis y
programación del
Web Service
Procedimientos y
transacciones para la
manipulación de la BD
Especificar Reglas a nivel
BD
Generar programas
cliente
Lenguaje y medio de
comunicación, XML
Flujo de Implementación del Patrón Piramidal
Figura 16, Flujo de Implementación del Patrón Piramidal.
92
CAPÍTULO 4, Implementando el Patrón Piramidal.
En este capítulo se detallará el proceso por el cual se lleva a cabo una implementación
del patrón piramidal, tomando en cuenta los elementos citados en el capítulo anterior.
Así también se pretende ilustrar esta implementación a través de la aplicación de cobros
bancarios antes mencionada.
93
Consideraciones Previas
Antes de comenzar debemos tomar en cuenta las herramientas y recursos necesarios
para el caso de estudio, como recordamos se llevará a cabo la implementación de Patrón
Piramidal en una aplicación de cobros bancarios. A continuación se enlistan las
herramientas que se utilizarán para este caso:
Nivel Base
Herramienta Versión Uso
C#.net 2008 Se utilizará este lenguaje para la creación del front
end principal en el cual se ingresarán datos
necesarios para iniciar una transacción.
Visual Basic 6.0 Se utilizará esta herramienta para la creación de
una DLL que contendrá toda la funcionalidad para
el cobro, encapsulada, así como la funcionalidad
para interactuar con dispositivos (PinPads).
Java Script Se utilizará este lenguaje para crear una interfaz
más que implemente las funcionalidades de la DLL
en un ambiente Web.
VB.net 2008 Se utilizará este lenguaje para crear una aplicación
móvil que pueda invocar el servicio de cobro desde
un teléfono con Windows Mobile.
WML/WMLS con Java. 1.6 Se implementará una aplicación front que corra
sobre terminales punto de venta.
XML Se utilizará para enviar cadenas el nivel de
interpretación con los datos de la venta.
Tabla 2, Herramientas del Nivel Base
Principalmente estas herramientas están orientadas a la explotación de los servicios
desde la vista del usuario, es decir son aquellas aplicaciones que permitirán a los usuarios
comenzar un ciclo de cobro y en general de solicitud a servicios.
94
Nivel de Interpretación
Herramienta Versión Uso
Java 1.6 Este lenguaje se utilizará para crear el Web Service
de interacción con el nivel de base y el nivel fuente.
Frameworks Spring 2.0 Se utilizará este frameworks como base de la
programación java para crear el web services
utilizando las ventajas que ofrece.
SOAP Se utilizará para establecer la comunicación del
Web Services.
ISO Estandar de mensajería que se utilizará para enviar
mensajes en cadenas hacia el nivel fuente.
XML Lenguaje que se utilizará para enviar y recibir
mensajes con el nivel base.
Oracle 9i Motor de base de datos en el que se almacenarán
los datos del resultado de las transacciones.
Apache Tomcat 5.5 Servidor de aplicaciones en el que se montará el
desarrollo del Web Service.
Tabla 3, Herramientas del Nivel de Interpretación
Las herramientas de este nivel, principalmente están orientadas a servir a las peticiones
que se originan de las vistas que se encuentran en el nivel base, como podemos observar
se utilizarán herramientas orientadas a los servicios y se tomarán ventajas del frameworks
de Spring para lograr mayor nivel de mantenimiento y explotación.
Nivel Fuente
Herramienta Versión Uso
Procesador de Transacciones Bancaras
N/A El procesador de transacciones bancarias es una
entidad que se encarga de comunicarse con los
bancos en busca de autorización o rechazo de las
transacciones, esta entidad no está controlada por
el proyecto.
Tabla 4, Herramientas del Nivel Fuente
95
Primer Paso, Especificar Reglas a Nivel Base de Datos
Tomando en cuenta el flujo mostrado en la figura 16, seguiremos los pasos
recomendados y se hará cita a la implementación en el caso de estudio.
• Especificar Reglas a Nivel Base de Datos.
Se deben especificar las reglas de negocio a nivel base de datos, así como establecer constrains y normalización de la misma.
El proyecto a nivel base de datos consta tanto de entidades transaccionales como no
transaccionales. Las entidades transaccionales son aquellas en las que se almacenan los
datos de las operaciones.
Las entidades no transaccionales son aquellas en las que se almacenan datos de
configuración de la aplicación, como roles, permisos, catálogos, etcétera. A continuación
se muestra el grupo de tablas tanto transaccionales como no transaccionales, en forma de
un Diagrama Entidad-Relación:
Figura 17, Agrupación de tablas transaccionales y no transaccionales
96
Definición de Elementos de la Base de Datos
Para la definición de las tablas se recomienda usar una nomenclatura en la que se
establezcan prefijos que indiquen a que grupo de tablas del proyecto pertenece cada una.
La intención es indicar los estándares de nomenclatura para Base de Datos, que se
deben utilizar en el desarrollo de aplicaciones y configuraciones técnicas de la plataforma
distribuida.
El objetivo del establecimiento de estándares dentro es homogeneizar la forma de
definición de las Bases de datos, así como las mejores prácticas para lograr altos niveles
de productividad y eficiencia de los recursos tecnológicos y humanos, reduciendo así el
esfuerzo requerido para integrar sistemas aplicativos e infraestructura, en balance con los
niveles de servicio y seguridad que los proyectos demandan.
Nombre de la Instancia
Nomenclatura: Baanepp[número]
En donde: B : Identificador fijo, señalando Base de Datos
aa : Identificador de la aplicación en 2 posiciones
n : Identificador del negocio (ver Tabla 1: Tabla de negocios)
e : Identificador del entorno (ver Tabla 2: Tabla de entornos)
pp : Identificador del país (ver Tabla 3: Tabla de países )
número : 1...9
Ejemplos: Instancias de producción en Venezuela de la aplicación con código LA:
BLABPVE1
Bases de Datos
Nomenclatura: Baanepp[número]
En donde: B : Identificador fijo, señalando Base de Datos
aa : Identificador de la aplicación en 2 posiciones
n : Identificador del negocio (ver Tabla 1: Tabla de negocios)
97
e : Identificador del entorno (ver Tabla 2: Tabla de entornos)
pp : Identificador del país (ver Tabla 3: Tabla de países )
número : 1...9
Ejemplos: Base de Datos de producción en Venezuela de la aplicación con código LA:
BLABPVE1
Tablespace
Nomenclatura: TS_ttt[numero] _[consecutivo]
En donde: TS : Identificador fijo, para indicar tablespace
ttt : Tipo de objeto alojado
DAT = Datos (tablas)
IND = Indices
TMP = Temporal
UNDO = Undo
numero : Número consecutivo en tres posiciones
consecutivo : Número consecutivo en dos posiciones en caso de tener
varios tablespaces asignados a una tabla (ejemplo: tabla particionada)
Ejemplo: Tablespaces de una tabla con 3 particiones: TS_DAT001_01, TS_DAT001_02, TS_DAT001_03
Tablespace de una tabla sin particiones: TS_DAT003
Tablas
Nomenclatura: Taa[numero]_mmm
En donde: T : Identificador fijo, para indicar tabla
aa : Identificador de la aplicación de 3 a 5 posiciones
[numero]: Número consecutivo en tres posiciones
mmm : Descripción mnemónica del contenido de la tabla (20 caracteres)
en singular.
98
Ejemplo: Tabla de sucursales de la aplicación LAR: TLA002_SUCURSAL
Columnas
Nomenclatura: pp_mmm
En donde: pp : Prefijo que indica el tipo de dato
st : status
id: identificadores
cd: códigos,claves
pw: password
fh: fechas
hm: hora
tm: timestamp
im : importe
nb : nombres, descripciones
nu : número
pc : porcentajes
tp : tipos
tx : textos
cc: credit card
mmm : Mnemónico de la columna (20 caracteres) en singular.
Ejemplos: Usaremos como ejemplo la tabla para un empleado.
Columna para indicar el estatus del usuario, que puede ser activo 1 o inactivo
0: st_empleado Columna para indicar la clave del usuario: cd_empleado Columna para indicar la fecha de nacimiento del usuario: fh_nacimiento Columna para indicar la hora de registro del usuario: hm_registro Columna para indicar la fecha y hora de alta del usuario: tm_alta Columna para indicar el salario del usuario: im_salario Columna para indicar el nombre del usuario: nb_nombre, nb_nombre2, nb_paterno, nb_materno
99
Columna para indicar el teléfono del usuario: nu_lada, nu_telefono Columna para indicar porcentaje de aguinaldo: pc_aguinaldo Columna para indicar el tipo de empleado: tp_empleado Columna para indicar la descripción de sus actividades: tx_actividades Columna para indicar la tarjeta de crédito: cc_
Vistas
Nomenclatura: Vaa[numero]_mmm
En donde: V : Identificador fijo, para indicar vista
aa : Identificador de la aplicación de 2 a 5 posiciones
[numero]: Número consecutivo en tres posiciones, igual a la tabla de la que
proviene en caso de ser solo una tabla
mmm : Descripción mnemónica del contenido de la vista (20 caracteres)
en singular.
Ejemplo: Vista de sucursales de la aplicación PBA: VPBA001_EMPLEADO
Índices
Nomenclatura: Iaannnt[numero]_mmm
En donde: I : Identificador fijo, para indicar índices
aa : Identificador de la aplicación de 2 a 5 posiciones
nnn :1..999 Número consecutivo de la tabla a la cual pertenece en 3
posiciones
t : - Guión bajo
[numero]: 1..9 Número consecutivo en 1 posición
mmm : Nemotecnico de la tabla a la cual pertenece (20 caracteres)
Ejemplo: Índice secundario de la tabla PBA001_SUCURSAL:
IPBA001S1_SUCURSAL Llave primaria de la tabla PBA001_SUCURSAL: IPBA001P1_SUCURSAL
100
Índice particionado del tipo local prefixed de la tabla PBA001_SUCURSAL:
IPBA001_1_SUCURSAL
Llaves foráneas
Nomenclatura: Rpppddd[numero] Se llamará igual que su Regla de Integridad Referencial
En donde: R : Identificador fijo, para indicar regla de integridad referencial
ppp : Número consecutivo de la tabla padre.
ddd : Número consecutivo de la tabla hijo
[numero]: Número consecutivo en una posición
Ejemplo: Llave foránea de la tabla PBA001_SUCURSAL (tabla padre) y PBA021_PLANTILLA
(tabla hijo): R0010211
Cluster
Nomenclatura: ct_pppddd
En donde: ct : Identificador fijo, para indicar que es cluster.
ppp : Nemónico a 3 primeras posiciones de la tabla padre.
ddd : Nemónico a 3 primeras posiciones de la tabla hijo. Ejemplo:
Cluster de la tabla PBA001_SUCURSAL y PBA021_PLANTILLA:
CT_SUCPLA
Trigger
Nomenclatura: tgttt_ppp
En donde: tg : Identificador fijo, para indicar que es un trigger
ttt : Identificador de evento que dispara el trigger
101
INS: insert
DEL: delete
UPD: update
ppp : Nemónico de la tabla padre.
Ejemplo: Trigger de inserción de la tabla PBA001_SUCURSAL: TGINS_SUCURSAL
Procedimiento
Nomenclatura: sp_ppp
En donde: sp : Identificador fijo, para indicar que es un procedimiento almacenado
ppp : Nemónico de hasta 20 posiciones
Ejemplo: Procedimiento de selecciones de campañas: SP_SELECC_CAMPANIA
Función
Nomenclatura: fn_ppp
En donde: fn : Identificador fijo, para indicar que es una función
ppp : Nemónico de hasta 20 posiciones
Ejemplo: Función de selecciones de campañas: FC_SELECC_CAMPANIA
Secuencia
Nomenclatura: sq_ppp
En donde:
sq : Identificador fijo, para indicar que es una secuencia
ppp : Nemónico de hasta 20 posiciones de la secuencia
102
Ejemplo: Secuencia de campañas: SQ_CAMPANIA (si se genera consecutivo para la
tabla PBA013_CAMP_PROMO).
Ligas de base de datos (database link)
Nomenclatura: ln_bbb
En donde: ln : Identificador fijo, para indicar que es un database link
bbb : Nombre de la base de datos o servicio
Ejemplo: Liga hacia un ambiente de desarrollo: LN_DEVMX1
Sinónimo
Nomenclatura: Nombre de la tabla o vista original.
Ejemplo: Sinónimo público de la tabla PBA013_CAMP_PROMO será
PBA013_CAMP_PROMO.
Paquete
Nomenclatura: pg_ppp
En donde: pg : Identificador fijo, para indicar que es un paquete (package)
ppp : Nemónico de hasta 20 posiciones
Ejemplo: Paquete de selecciones de campañas: PG_SELECC_CAMPANIA
Usuario
Nomenclatura: Usr Prefijo fijo ppp Nombre de la aplicación
103
Ejemplo: Base de Datos de Aplicación pruebas: Usrpbas
Role
Nomenclatura: rl_ppp
En donde: rl : Identificador fijo, para indicar que es un role.
ppp : Nemónico de hasta 20 posiciones
Ejemplo: Role para usuario de seguridad de datos: RL_SEGURIDAD
Profile
Nomenclatura: pf_ppp
En donde: pf : Identificador fijo, para indicar que es un profile
ppp : Nemónico de hasta 20 posiciones
Ejemplo: Role para usuario de seguridad de datos: PF_SEGURIDAD
104
Segundo Paso, Manipulación de la Base de Datos
Una vez definida toda la estructura de la Base de Datos es momento de implementar
procedimientos, funciones, transacciones, disparadores que permitan la manipulación de
los datos.
El objetivo de implementar directamente en la base de datos parte de la lógica del negocio
es para evitar recompilar el Web Service al momento de hacer algún cambio en alguna
consulta o el algún cambio de la estructura de la base de datos, como por ejemplo
agregar o eliminar un campo, una tabla, etcétera.
También es para explotar las bondades de las transacciones utilizando sus elementos
como el Commit y Rollback en caso de algún problema y así evitar problemas de
inconsistencia en los datos.
Se sugiere generar procedimientos almacenados y transacciones para la manipulación de la base de datos y no agregar querys al código de la aplicación.
A continuación se muestra la estructura de una función, la cual siempre devuelve como
resultado de consulta un valor booleano, en este caso se muestra esta función con el fin
de ejemplificar la forma propuesta para la manipulación de datos.
drop function if exists FInsertaEmpresa; CREATE FUNCTION FInsertaEmpresa(CD_GIRO int, CD_ESTATUS int, NB_EMPRESA varchar(500), TP_PERSONA varchar(1), NB_RFC varchar(30), NB_COMERCIAL varchar(500), NB_CALLE varchar(500), NB_EXTERIOR varchar(30), NB_INTERIOR varchar(30), CD_CP varchar(10), NB_COLONIA varchar(500), NB_DELEGACION varchar(500), NB_CIUDAD varchar(500), NB_ESTADO varchar(500), NB_LADA varchar(30), NB_TELEFONO varchar(30), FH_REGISTRO datetime, FH_MODIFICACION datetime, TX_AVISO varchar(500),
105
TX_LEYENDA_TIKET varchar(500), DIR_LOGO varchar(1000) ) RETURNS BOOL BEGIN DECLARE cdEmpresa INT; DECLARE Result Bool; SET Result = false; SELECT MAX(CD_EMPRESA) INTO cdEmpresa FROM a01_empresa; if (cdEmpresa < 1000 ) or (cdEmpresa = null ) then SET cdEmpresa = cdEmpresa + 1000; else SET cdEmpresa = cdEmpresa + 1; end if; if (cdEmpresa is not null) then INSERT INTO a01_empresa () VALUES (cdEmpresa,CD_GIRO,CD_ESTATUS,NB_EMPRESA, TP_PERSONA,NB_RFC,NB_COMERCIAL,NB_CALLE,NB_EXTERIOR,NB_INTERIOR, CD_CP,NB_COLONIA,NB_DELEGACION,NB_CIUDAD,NB_ESTADO,NB_LADA,NB_TELEFONO, FH_REGISTRO,FH_MODIFICACION,TX_AVISO,TX_LEYENDA_TIKET,DIR_LOGO); SET Result = TRUE; end if; RETURN Result; END; DELIMITER ;
En seguida se enlistan los procedimientos y funciones contenidos en la base de datos, así
como su definición.
Procedimiento/Función/Transacción Descripción
LoginUsuer (Usuario, Password, Empresa, Sucusal)
Devuelve un recordset con dos campos,
uno que indica un true o un false
dependiendo si el usuario es correcto o no
y otro con una descripción en caso de que
el usuario haya sido rechazado para saber
detalle del rechazo.
SaveTransaction (TP_Trasaccion, Referencia, Fecha, Hora, Empresa, Sucursal, Usuario)
Registra una transacción en la base de
datos en la tabla de transacciones.
GetReport (Usuario, Password, Empresa, Sucursal, Referencia, Fecha)
Devuelve un recordset con las
transacciones realizadas en la fecha
indicada y tomando en cuenta la referencia
como filtro opcional. Tabla 5, Descripción de Procedimientos
106
Tercer Paso, Análisis y Desarrollo del Web Service
Una vez establecida la estructura de la Base de Datos es pertinente generar el Web
Service que se implantará en el nivel de interpretación el cual fungirá como intérprete de
mensajes entre el nivel base y el nivel fuente.
Posteriormente es conveniente iniciar con el análisis y programación del Web Service que se instalará en el nivel de interpretación, en este Web Service se deben establecer reglas de negocio acorde a las necesidades.
A continuación se enlistaran las clases que contendrá el web services y se dará una
explicación de su funcionalidad.
Clase Descripción
XMLService Esta clase se encargará del manejo de los esquemas XML así
como de la construcción y validación de los mensajes XML
provenientes de los niveles fuente y base.
ISOService Esta clase será la encargada de construir el mensaje ISO 8583
que se envíe hacia el nivel fuente y de parcear y tratar el mensaje
ISO 8583 que el nivel fuente responda.
ValidateService Esta clase contendrá una serie de validaciones de reglas de
negocio como longitudes, estatus, tipos de operaciones, entre
otras.
SecurityService Esta clase se encargará de encriptar y desencriptar los mensajes
entre niveles.
DBService Esta clase se encargará de establecer un pool de conexión con la
base de datos así como la invocación de los procedimientos
almacenados, transacciones y funciones.
LogService Esta clase se encargará de guardar los eventos que sucedan
entre el flujo de la operación.
ComService Esta clase contendrá los métodos necesarios para establecer una
comunicación entre los niveles.
TransactionService Esta clase contendrá los métodos de las operaciones a realizar. Tabla 6, Descripción de Clases
107
En seguida se enlistan nuevamente las clases, pero ahora se incluyen sus métodos y una
breve descripción de estos:
• XMLServices:
Accesibilidad Método Descripción
+ ValidateSchema (String XML)
: String
Valida que el esquema de la operación a
realizar sea correcto.
+ GetDataXML (String Tag,
String XML) : String
Devuelve el valor de un tag contenido en
un XML.
+ DoXMLTrx (String Title,
ArrayList Dts) : String
Genera un XML que corresponde al tipo
de transacción a realizar recibe un string
con el título del esquema y un arraylist
con el contenido de los tags. Por ejemplo
en el arraylist un ítem seria “id_company,
0035”.
+ DoXMLResponse (ArrayList
Dts) : String
Genera el XML de respuesta de uns
transacción el cual se devolverá al nivel
base y recibe un arraylist con los valores
y nombre de los tags. Tabla 7, Descripción de los Métodos de la Clase XMLServices
• ISOServices
Accesibilidad Método Descripción
+ DoISOMessage (ArrayList
Dts) : String
Genera el mensaje ISO 8583 para enviar
al procesador que se encuentra en el
nivel fuente.
+ GetISOMessage () : String Obtiene el mensaje ISO 8583 que
responde el procesador. Tabla 8, Descripción de los Métodos de la Clase ISOServices
• ValidateService
Accesibilidad Método Descripción
+ DataValidateLength (String
TitleData, String Data) :
Devuelve true o false si la longitud del
campo es correcto o no.
108
Boolean
+ DataValidateContent (String
TitleData, String Data) :
Boolean
Devuelve true o false si el contenido del
campo es correcto o no.
Tabla 9, Descripción de los Métodos de la Clase ValidateService
• DBService
Accesibilidad Método Descripción
+ ExecuteNoQuery (String
TitleProcedure, ArrayList
Parameters) : Boolean
Ejecuta el procedimiento almacenado,
función o transacción con el título
asignado a la variable string y devuelve
un booleano que indica si la ejecución
fue exitosa.
+ ExecuteQuery (String
TitleProcedure, ArrayList
Parameters) : RecordSet
Devuelve el resultado de un
Procedimiento el cual da como resultado
una consulta, por ejemplo un reporte. Tabla 10, Descripción de los Métodos de la Clase DBService
• SecurityService
Accesibilidad Método Descripción
+ EncryptStringTripeDES
(String Data) : String
Encripta una cadena con el algorimo de
encripción TripleDES.
+ DecryptStringTripleDES
(String Data) : String
Desencripta una cadena con el
algoritmo TripleDES.
+ GenerateKey (String
FirstKey, String SecondKey)
Genera una llave con base a los
parámetros que se le setean y la
establece como llave de encripción.
+ HexConvert (String Data) :
String
Convierte la cadena resultante de una
encripción en caracteres hexadecimales
para que al momento que viajen no
surjan problemas de caracteres
extraños. Tabla 11, Descripción de los Métodos de la Clase SecurityService
109
• LogService
Accesibilidad Método Descripción
+ SaveTrace (String Trace) Guarda el contenido del String en el
archivo y directorio asignados para
almacenar logs
+ SetDirectory (String File) Establece el directorio en el cual se
guardaran los logs.
+ EnabledLog (Boolean Log) Recibe una bandera para indicar si se
guardará o no un log de la actividad de
las clases. Tabla 12, Descripción de los Métodos de la Clase LogService
• ComService
Accesibilidad Método Descripción
+ SendISO (String Method,
ArrayList Parameters) : String
Envía un mensaje ISO 8583 al Web
Service del procesador y devuelve una
cadena con la respuesta del Web
Service. Tabla 13, Descripción de los Métodos de la Clase ComServices
• TransactionService
Accesibilidad Método Descripción
+ ExecuteOperation (String
Transaction, String XML) :
String
Recibe el título y XML correspondientes
a una operación invocada desde el nivel
base por ejemplo una venta,
cancelación, etc, devuelve una cadena
encriptada que contiene el XML de
respuesta para los componentes del
nivel base. Tabla 14, Descripción de los Métodos de la Clase TransactionServices
110
Cuarto Paso, Protocolos de Comunicación y Conexión con servicios
En este paso se deberán establecer los medios de comunicación con los servicios de
terceros que se encuentran en el nivel fuente. En este caso será con el procesador de
cobros bancarios.
Protocolo de comunicación
Para este caso de estudio la comunicación con el servicio de terceros será utilizando
sockets java uno cliente y otro servidor. El socket cliente estará creado en el WebService
del nivel de interpretación y el socket servidor se encontrará en el nivel fuente.
Así mismo existirá un hilo que se encargará de monitorear la actividad entre los sockets y
tendrá la función de notificar en caso de que se caiga la comunicación entre estos.
Figura 17 Protocolo de Comunicación entre el nivel de interpretación y el nivel fuente
Los sockets son un sistema de comunicación entre procesos de diferentes máquinas de
una red, un socket es un punto de comunicación por el cual un proceso puede emitir o
recibir información.
111
Los sockets son capaces de utilizar el protocolo de streams TCP (Transfer Control
Protocol) y el de datagramas UDP (User Datagram Protocol). Utilizan una serie de
primitivas para establecer el punto de comunicación, para conectarse a una máquina
remota en un determinado puerto que esté disponible, para escuchar en él, para leer o
escribir y publicar información en él, y finalmente para desconectarse (Marshall K.
McKusick, 2004).
Estándar ISO 8583, Conexión con el procesador bancario
Como se ha venido mencionando a lo largo del desarrollo de este caso de estudio, existe
un estándar diseñado única y exclusivamente para el manejo de mensajes de tipo
financieros para la autorización de cobros bancarios.
En este caso de estudio se utilizará este estándar para la comunicación entre el nivel de
interpretación y el nivel fuente, como ya sabemos estos mensajes se transportarán a
través de sockets.
Figura 18, Pasó de mensajes IS0 8583 entre niveles de interpretación y fuente.
112
ISO 8583 es un estándar para Transacciones Financieras con Mensajes originados en
una tarjeta bancaria (ISO 8583-1:2003, 2007).
Es el estándar ISO se debe utilizar para sistemas que intercambian transacciones
electrónicas realizadas por poseedores de tarjetas de bancarias.
Una transacción basada en una tarjeta usualmente sale desde un dispositivo de compra,
tal como un POS o un cajero automático ATM, a través de una red (o redes) hacia un
sistema del emisor de la tarjeta para obtener una autorización en función de la cuenta del
titular de la tarjeta.
La transacción contiene información que se obtiene de la tarjeta (ej. número de cuenta), la
terminal (ej. nro. de comercio), la transacción (ej. importe) en conjunto con otra
información que se puede generar o agregar dinámicamente por los sistemas
intervinientes.
El sistema emisor de la tarjeta podrá autorizar o rechazar la transacción, y genera un
mensaje de respuesta que debe ser devuelto a la terminal en un tiempo breve.
ISO 8583 define un formato de mensaje y un flujo de comunicación para que diferentes
sistemas puedan intercambiar estas transacciones.
La mayoría de las operaciones realizadas en ATM usan ISO 8583 en algunos puntos de la
cadena de comunicación, así como también las transacciones que realiza un cliente que
usa una tarjeta para hacer un pago en un local. En particular, todas las redes de tarjetas
basan sus transacciones en el estándar ISO 8583. Las transacciones incluyen compras,
extracciones, depósitos, reintegros, reversos, consultas de saldo, pagos y transferencias
entre cuentas. ISO 8583 también define mensajes entre sistemas para intercambios
seguros de claves, conciliación de totales y otros propósitos administrativos.
Aunque el ISO 8583 define un estándar común, no se usa normalmente en forma directa
por sistemas o redes. En lugar de eso cada red adapta el estándar para su propio uso con
campos adaptados a sus necesidades particulares.
113
La ubicación de los cambios en diferentes versiones del estándar varia, por ejemplo, los
elementos que definen la moneda (currency elements) de las versiones 1987 y 1993 no
se usan más en la versión 2003, lo que hace que la moneda sea un sub-elemento de
cualquier elemento monto. LA ISO 8583:2003 todavía tiene que obtener aceptación.
Un mensaje ISO 8583 consta de las siguientes partes:
• Message Type Indicator (MTI) - Indicador de Tipo de Mensaje
• Uno o más bitmaps, indicando que elementos están presentes en el mensaje
• Data elements, los campos del mensaje
Figura 19, El estándar ISO 8583
Consultada, http://blog.jotadeveloper.com/2009/01/25/conociendo-el-standard-iso8583/
Message Type Indicator (MTI): Este es un campo numérico de 4 dígitos que clasifica la
función de alto nivel del mensaje. Un MTI incluye la versión ISO 8583, la clase (Message
Class), la función (Message Function) y el origen del mensaje (Message Origin).
Bitmaps - Mapas de Bits: Dentro del ISO 8583, un mapa de bit es un campo o
subcampo dentro de un mensaje que indica que otros elementos (campos o subcampos)
se encuentran en el mensaje.
114
Un mensaje contendrá al menos un mapa de bits, llamado el Mapa de Bits Primario que
indica que campos (Data Elements) del 1 al 64 están presentes.
Puede existir un mapa de bits secundario, generalmente como elemento 1 que indica que
campos del 65 al 128 están presentes. De igual forma, un tercer bitmap puede usarse
para indicar la presencia o ausencia de los campos del 129 al 192, aunque esos campos
casi nunca se usan.
El mapa de bits se puede transmitir como un dato binario de 8 bytes, o como un campo de
16 caracteres hexadecimales 0-9, A-F en el set de caracteres ASCII o EBCDIC.
Bitmap Define la presencia de 4210001102C04804 Campos 2, 7, 12, 28, 32, 39, 41, 42, 50, 53, 62 7234054128C28805 Campos 2, 3, 4, 7, 11, 12, 14, 22, 24, 26, 32, 35, 37, 41, 42, 47, 49, 53, 62, 64 ,100 (Bitmap
secundario requerido para mostrar la presencia del campo - 100) 8000000000000001 Campos 1, 64 0000000000000003 (Bitmap secundario)
Campos 127, 128
Tabla 15, BitMap de un mensaje ISO 8583
Explicación del Bitmap (8 bytes, Bitmap Primario = 64 Bit) campo 4210001102C04804
• BYTE1 : 01000010 = 42x (contando de izquierda, el segundo y el séptimo bit son 1,
indicando que los campos 2 y 7 están presentes)
• BYTE2 : 00010000 = 10x (campo 12 está presente)
• BYTE3 : 00000000 = 00x (no hay campos presentes)
• BYTE4 : 00010001 = 11x (campos 28 y 32 están presentes)
BYTE5 : 00000010 = 02x (campo 39 está presente)
• BYTE6 : 11000000 = C0x (campos 41 y 42 están presentes)
• BYTE7 : 01001000 = 48x (campos 50 y 53 están presentes)
• BYTE8 : 00000100 = 04x (campo 62 está presente)
0________10________20________30________40________50________60__64
1234567890123456789012345678901234567890123456789012345678901234 n-th bit
0100001000010000000000000001000100000010110000000100100000000100 bit map Campos presentes en un mensaje de longitud variable:
2-7-12-28-32-39-41-42-50-53-62
115
Data Elements - Campos de datos: Los Data Elements son los campos individuales que
llevan la información sustancial acerca de la transacción.
Hay 128 campos definidos en el estándar ISO8583:1987, y 192 en posteriores releases.
La revisión de 1993 agregó nuevas definiciones, eliminó algunas pero sin embargo dejó el
formato del mensaje sin cambios.
Mientras que cada Data Element tiene un significado y formato específico, el estándar
también incluye algunos campos de propósito general y algunos especiales para sistemas
o países, los cuales varían sustancialmente en su forma y uso de una implementación a
otra.
Cada campo se describe en un formato estándar que define el contenido permitido del
campo (numérico, binario, etc.) y el largo del campo (variable o fijo), de acuerdo a la
siguiente tabla:
Abreviatura Significado a Alfanumérico, incluyendo los espacios n Sólo valores numéricos s Sólo caracteres especiales an Alfanumérico as Sólo caracteres alfanuméricos y especiales ns Sólo caracteres numéricos y especiales ans Caracteres Alfabeticos, numericos y especiales b Información binaria z Tracks 2 y 3 code set como se define en la ISO 4909 y en ISO 7813.
Tabla 16, Definición de campos de los Data Elements.
Como observamos es todo un estándar que se debe cumplir para poder establecer
comunicación con el procesador de transacciones, a continuación se muestra un mensaje
ISO 8583, que el Web Service del nivel de interpretación debe enviar al procesador de
transacciones bancarias:
ISO0250000500200B238C40128A1801A000000001000019C0000000000066549820708183620891267123620070807083009012015215474848000327682=1007000019542547019542547 AIR CANADA VT 6M Q6 0277014001 00010101484016B003LNK1+0000000019 PRO100000000000064& 0000300064! C000026 687 001 0 1 ! Q600006 00060309000000000029 0000020 P0 009001001001012C1HOSTB24 1003800000000000000000000000000000000000000 Field -1='0200' Field 0='B238C40128A1801A'
116
Field 1='000000001000019C' Field 3='000000' Field 4='000006654982' Field 7='0708183620' Field 11='891267' Field 12='123620' Field 13='0708' Field 17='0708' Field 18='3009' Field 22='012' Field 32='5' Field 35='e4848000327682=1007' Field 37='000019542547' Field 41='019542547 ' Field 43='AIR CANADA VT 6M Q6 ' Field 48='7014001 00010101' Field 49='484' Field 60='B003LNK1+0000000' Field 61=' PRO100000000000' Field 63='& 0000300064! C000026 687 001 0 1 ! Q600006 000603' Field 100='000000000' Field 120=' 0000' Field 121=' P0 ' Field 124='001001001' Field 125='C1HOSTB24 10' Field 126='00000000000000000000000000000000000000'
La comunicación ISO 8583 es obligatoria para toda aquella entidad que desee incorporar
a sus procesos de negocio el envío electrónico de transacciones bancarias, ya sean
procesadores, gateways, cajeros automáticos, etc.
El estándar ISO 8583, sería el cuarto paso de este caso de estudio de implementación del
patrón piramidal.
117
Quinto paso, Lenguaje y medio de comunicación entre el nivel base e
interpretación
En estos momentos ya tenemos desarrollado un Web Service que se encuentra en el
nivel de interpretación así como su comunicación con el nivel fuente, en estos momentos
toca desarrollar un lenguaje y medio de comunicación entre los niveles base y de
interpretación.
Como se ha venido mencionando, es recomendable establecer un lenguaje estándar que
se pueda ser interpretado por casi cualquier lenguaje de programación.
Para este caso de estudio se recomienda utilizar esquemas XSD para establecer la
tipología de los datos y el XML para intercambiar información respetando siempre los
esquemas.
Esquemas XSD como Lenguaje de Interpretación
Los esquemas XSD son un vocabulario para expresar las reglas de los datos que se
utilizarán y sirve de referencia para validar los datos que aparecerán en un XML (Priscilla
Walmsley, 2001), especifica la estructura de la instancia del documento XML (El elemento
está formado por elementos, y estos a su vez por otros elementos, etc.). Los esquemas
XSD tienen muchos beneficios, los cuales se enlistan a continuación:
• El esquema XSD sirve para definir la correcta estructura de los elementos del
documento XML.
• Define los elementos que pueden aparecer en el documento XML.
• Define los atributos de los elementos que pueden aparecer en el documento XML.
• Define qué elementos son hijos de los elementos principales del documento XML.
• Define la secuencia en la cual los hijos de los elementos pueden aparecer en el
documento XML.
• Define el número de hijos de los elementos.
• Define cuando un elemento es vacío o puede incluir texto.
• Define el tipo de datos para los elementos y sus atributos.
118
• Define los valores predeterminados para algunos elementos y atributos.
Si el documento XML no concuerda con la estructura definida del archivo XSD, entonces
el documento XML estará erróneo.
Los XSD se utilizan para validar mucho sobre la estructura de los XML, a continuación se
enlistan varios de sus usos:
• Validar el contenido de un documento XML.
• Determinar que el documento XML es una instancia válida del vocabulario
(gramática o reglas), expresada por el esquema XSD.
• Define los elementos que pueden aparecer dentro de un documento XML y los
atributos que pueden ser asociados con un elemento.
• Define si un elemento se encuentra vacío o puede incluir texto.
• Define el valor de defecto de un atributo.
• Define los elementos que pueden contener elementos hijo.
• Define la secuencia de los elemento hijo, que aparecen en un elemento.
• Define el número de elementos hijo.
Atributos
Los atributos son similares a los elementos, si bien un atributo ha de ser de un tipo simple
y tiene declararse justo antes de cerrar la etiqueta xsd:complexType.
A diferencia de los elementos, los atributos pueden aparecer en cualquier orden y no
pueden incluir otros elementos (al ser de tipos simples). No obstante, su característica
más interesante es que pueden ser opcionales y se les puede asignar un valor por
defecto:
<xsd:attribute name="rebate" type="xsd:decimal" />
El atributo use de xsd:attribute puede utilizarse para especificar si la presencia del atributo
es esencial ("required"), opcional ("optional") o incluso si está prohibida ("prohibited"),
aunque esta última opción no resulta especialmente útil.
119
Ejemplo de un esquema XSD
El siguiente ejemplo muestra un sencillo esquema XML que podría ser útil para gestionar
los productos existentes en un almacén:
<?xml version="1.0" encoding="utf-8"?> <xsd:schema id="stock" xmlns:xsd="http://www.w3c.org/2001/XMLSchema" targetNamespace="http://elvex.ugr.es/stock.xsd"> <xsd:complexType> <xsd:sequence> <xsd:element name="ID" type="xsd:unsignedInt" /> <xsd:element name="description" type="xsd:string" /> <xsd:element name="price" type="xsd:decimal" /> <xsd:element name="quantity" type="xsd:integer" /> </xsd:sequence> </xsd:complexType> </xsd:schema>
La etiqueta xsd:schema del documento XML anterior está definida en el estándar XSD y
es la que nos permite definir esquemas de acuerdo con el estándar del W3C (David C.
Fallside, 2004). El atributo targetNamespace nos permite asociar el esquema al espacio
de nombres indicado (para diferenciarlo de otros esquemas stock).
La etiqueta xsd:complexType nos permite definir tipos de forma similar a como se
especifican los tipos definidos por el usuario en un lenguaje de programación, indicando
los elementos correspondientes a cada dato almacenado acerca de los productos de
nuestro almacén, su identificador y su tipo.
Los elementos se utilizan para especificar las etiquetas válidas en un documento XML
(name) y su tipo (type), tal como aparece en el ejemplo anterior. Además, el orden en que
aparecen los elementos en el esquema XML determina el orden en que han de aparecen
dentro de un documento XML que se ajuste al esquema.
Las facetas forman parte de la definición de elementos y atributos de un esquema XML y
nos permiten especificar restricciones adicionales sobre los datos que pueden aparecer
en un documento XML válido.
120
Notación XSD para el nivel de interpretación
Para el nivel de interpretación se utilizarán esquemas XSD con el fin de garantizar que
todas aquellas peticiones que provengan del nivel base cumplan con ciertas reglas de
formato.
En este caso el nivel de interpretación contendrá cuatro esquemas que representarán las
funcionalidades que existen en el nivel base a las que tendrán alcance los usuarios, los
esquemas representan las siguientes funcionalidades:
• Solicitud de Cobro bancario.
• Solicitud de Cancelación de un cobro antes realizado.
• Reimpresión de un voucher.
• Consulta de transacciones.
Los XSD para este nivel estarán subdivididos por dos elementos fundamentales, uno que
contendrá datos del comercio y otro que contendrá datos específicos de la funcionalidad o
transacción a realizar.
Figura 20, elemento business de los esquemas del nivel de interpretación
El elemento “business”, contiene la información necesaria para llevar a cabo las primeras
validaciones del negocio, como privilegios, montos autorizados, etc.
Hablando a nivel clases del Web Service, el elemento “business” se somente a las
validaciones de la clase ValidateService para verificar si la empresa, usuario, password,
121
sucursal son correctos, también para verificar si este usuario tiene permisos para llevar a
cabo esta operación, entre otras validaciones.
<xs:complexType name="business"> <xs:annotation> <xs:documentation>business identification</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="id_company"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="4"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="id_branch"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="10"/> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="country"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="MEX"/> <xs:enumeration value="USA"/> <xs:enumeration value="GBR"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="user"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="8"/> <xs:maxLength value="20"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="pwd"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> <xs:maxLength value="40"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType>
En este tag se tienen los elementos que utilizará el web service para la identificación de
los comercios que generen peticiones, a continuación se explican los elementos
contenidos en el tag “business”.
122
Elemento Características
id_company • Tipo dato: String
• Longitud máxima: 4 posiciones
• Naturaleza: Obligatorio
• Aplica a Operaciones: Todas
• Valor Fijo: Número de Comercio.
id_branch • Tipo dato: String
• Longitud máxima: 10 posiciones
• Naturaleza: Obligatorio
• Aplica a Operaciones: Todas
• Valor Fijo: Número de unidad de
negocio (Por ejemplo: sucursal).
country • Tipo dato: String
• Longitud máxima: 3 posiciones
• Naturaleza: Obligatorio
• Aplica a Operaciones: Todas
• Valor: País desde donde se envía la
solicitud de cargo.
user • Tipo dato: String
• Longitud máxima: 10 posiciones
• Naturaleza: Obligatorio
• Aplica a Operaciones: Todas
• Valor: Identificador de usuario a
nombre del quien se realiza el cargo.
pwd • Tipo dato: String
• Longitud máxima: 15 posiciones
• Naturaleza: Obligatorio
• Aplica a Operaciones: Todas
• Valor: Contraseña asociada al
usuario. Tabla 17, elementos del tag business
123
El segundo elemento (“transacction”) contendrá información más específica de la
operativa a realizar, y es variable de acuerdo a dicha operativa.
Solicitud de Cobro bancario
Esta función permite al negocio realizar solicitudes de cargo con presencia de tarjeta;
aplica para todo tipo de Comercio que tiene ventas de mostrador. Para realizar una
solicitud de cargo con tarjeta, la herramienta de ventas del Comercio genera una
transacción asociada a una referencia, importe, y forma de pago.
En seguida se muestra el esquema XSD de una solicitud de cobro que disparará alguna
de las interfaces contenidas en el nivel base, utilizando software Altova XML Spy.
Figura 21, Esquema XSD para la operativa de cobros bancarios
124
Como es notable el esquema esta subdivido en de forma jerárquica en dos elementos,
uno que contiene datos del comercio que da origen a la petición y otro que contiene los
datos de la operación dichos con los cuales se generará el mensaje ISO 8583.
A continuación se muestra esta funcionalidad a forma de esquema con el fin de denotar
las reglas de formato que se establecen en el nivel de interpretación y que toda interfaz
del nivel base debe cumplir, para que su petición sea aceptada y procesada en forma
correcta.
<xs:element name="VMCAMEXB"> <xs:annotation> <xs:documentation> </xs:documentation> </xs:annotation> <xs:complexType> <xs:sequence> <xs:complexType name="business"> <xs:annotation> <xs:documentation>business identification</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="id_company"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="4"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="id_branch"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="10"/> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="country"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="MEX"/> <xs:enumeration value="USA"/> <xs:enumeration value="GBR"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="user"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="8"/> <xs:maxLength value="20"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="pwd"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:minLength value="1"/> <xs:maxLength value="40"/>
125
</xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> <xs:complexType name="transactionb"> <xs:annotation> <xs:documentation>Transaction Banda</xs:documentation> </xs:annotation> <xs:sequence> <xs:element name="merchant"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:length value="5"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="reference"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="30"/> <xs:minLength value="1"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="tp_operation"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> <xs:enumeration value="5"/> <xs:enumeration value="6"/> <xs:enumeration value="7"/> <xs:enumeration value="8"/> <xs:enumeration value="9"/> <xs:enumeration value="10"/> <xs:enumeration value="11"/> <xs:enumeration value="12"/> <xs:enumeration value="13"/> <xs:enumeration value="14"/> <xs:enumeration value="15"/> <xs:enumeration value="16"/> <xs:enumeration value="17"/> <xs:enumeration value="18"/> <xs:enumeration value="19"/> <xs:enumeration value="20"/> <xs:enumeration value="21"/> <xs:enumeration value="22"/> <xs:enumeration value="23"/> <xs:enumeration value="24"/> <xs:enumeration value="25"/> <xs:enumeration value="26"/> <xs:enumeration value="27"/> <xs:enumeration value="28"/> <xs:enumeration value="29"/> <xs:enumeration value="30"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="creditcard"> <xs:complexType>
126
<xs:sequence> <xs:element name="crypto"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="0"/> <xs:enumeration value="1"/> <xs:enumeration value="2"/> <xs:enumeration value="3"/> <xs:enumeration value="4"/> <xs:enumeration value="5"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="type"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="V/MC"/> <xs:enumeration value="AMEX"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="tracks"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="1000"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> <xs:element name="amount" type="xs:decimal"/> <xs:element name="currency"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:enumeration value="MXN"/> <xs:enumeration value="USD"/> </xs:restriction> </xs:simpleType> </xs:element> <xs:element name="usrtransacction" minOccurs="0"> <xs:simpleType> <xs:restriction base="xs:string"> <xs:maxLength value="30"/> </xs:restriction> </xs:simpleType> </xs:element> </xs:sequence> </xs:complexType> </xs:sequence> </xs:complexType> </xs:element>
Como es notorio en el tag “transacction”, se definen los datos que se generan en el
momento de una operación de cobro, a continuación se explican los elementos del tag
“transacction”.
127
Los siguientes son los parámetros utilizados en las funciones de cobro, su utilización
depende si se trata de una transacción con las variantes de con Tarjeta Presente.
Estos parámetros indican detalle de la transacción y muchos de ellos serán tomados por
la clase ISOService, para generar el mensaje ISO 8583 que será enviado al procesador
que se encuentra en el nivel fuente.
Parámetro Naturaleza Descripción
amount Obligatorio Cantidad a cobrar.
crypto Depende
de la
operación
Bandera que indica el nivel de encripción para el
número de la tarjeta.
0 =no está encriptado
1=esta encriptado solo el número de la tarjeta
2=toda la información del track está encriptada
currency Obligatorio Tipo de moneda.
merchant Obligatorio Referencia del número de afiliación del
Comercio.
reference Obligatorio Número referencia de la transacción.
tp_operation Obligatorio Indica el escenario que se encuentra en el nivel
base del cual proviene la petición.
usrtransacction Opcional Código de usuario por transacción.
tracks Obligatorio Contiene la información que se lee de la banda
o del chip, para el caso de la banda se obtienen
dos (track 1 y track 2), para el caso del chip solo
se obtiene el track2, de cualquier forma estos
deben ir concatenados y encriptados con
TripleDES.
type Obligatorio Tipo de tarjeta Visa, MasterCard o American
Express. Tabla 18, Elementos del tag “transacction” de una solicitud de cobro
En seguida se muestra un ejemplo que cumple con el esquema XSD propuesto en el nivel
de interpretación, para la realización de un cobro bancario, con presencia de tarjeta.
128
//VENTA BANDA <?xml version="1.0" encoding="UTF-8" ?> <VMCAMEXB> <business> <id_company>0035</id_company> <id_branch>700</id_branch> <country>MEX</country> <user>0035RRMI0</user> <pwd>11AEA0D1F22CDB30FE</pwd> </business> <transacction> <merchant>00127</merchant> <reference>54D77</reference> <tp_operation>9</tp_operation> <creditcard> <crypto>2</crypto> <type>V/MC</type> <tracks>04A1A8D19449A648FB7F4F308E67A79322DDE39BFB4AC08377 244A4B6ADAC85607AD345C46227312F2</tracks> </creditcard> <amount>1.20</amount> <currency>MXN</currency> </transacction> </VMCAMEXB>
Solicitud de cancelación de un Cobro
Otra de las funcionalidades a las cuales tendrán acceso los usuarios de las interfaces o
escenarios que se encuentren en el nivel base, será la cancelación de una transacción
bancaria ya realizada con anterioridad, para lo cual también se han de establecer
esquemas y atributos necesarios para ejecutar esta operación.
Esta función permite al Comercio cancelar una transacción que se haya realizado durante
el día.
Como dato adicional podemos decir que esta funcionalidad sólo podrá realizarse antes del
horario de corte bancario (usualmente a las 11:00 p.m.), ya que posteriormente, tendrá
que realizarse una devolución administrativa.
A continuación se muestra la figura del esquema que se debe cumplir para originar una
solicitud de cancelación de un cobro bancario.
129
Figura 22, Esquema para la cancelación de un cobro
Como podemos observar este esquema al igual que el del cobro, cuenta con dos tags
principales, que son “business” y “transacction”, el tag “business” es prácticamente el
mismo, el cual como ya se había mencionado contiene los datos necesarios para la
identificación del comercio que origina la petición.
Por su parte el tag “transacction”, contiene información específica de la operación, a
continuación se describen los elementos de este tag.
Parámetro Naturaleza Descripción
amount Obligatorio Cantidad a cobrar.
crypto Depende
de la
operación
Bandera que indica el nivel de encripción .
130
usrtransacction Opcional Código de usuario por transacción.
no_operacion Depende
de la
operación
Número asignado a la operación original que se
desea cancelar.
auth Obigatorio Número de autorización de la operación, se
envía para transacciones como cancelación,
venta forzada, reverso, etc. Tabla 19, Elementos del tag “transacction” de una cancelación
Ejemplo de un XML que cumple con el esquema expuesto para la cancelación de un
cobro bancario:
//CANCELACION <?xml version="1.0" encoding="UTF-8" ?> <VMCAMEXMCANCELACION> <business> <id_company>0002</id_company> <id_branch>8710</id_branch> <country>MEX</country> <user>0002PEOJ</user> <pwd>11AEA3D6F03BD933FF</pwd> </business> <transacction> <amount>.01</amount> <no_operacion>123456789</no_operacion> <auth>123456</auth> <usrtransacction>USRTRX01</usrtransacction> <crypto>2</crypto> <version>dllcpintegra 4.1.6</version> </transacction> </VMCAMEXMCANCELACION>
Solicitud de Reimpresión
Esta función permite al Comercio re-imprimir el voucher de una transacción, de igual
forma el nivel de interpretación debe contener el esquema que de formato a las peticiones
que se originen en el nivel base.
El esquema de igual forma contiene tres tags principales, uno que es la identificación del
comercio que origina la petición (business) y otros que contienen información específica
de la operación.
131
Es importante señalar que esta funcionalidad a diferencia del cobro y cancelación, no
requiere ir al nivel fuente, ya que en este caso la información que requiere la petición
puede extraerse de la base de datos que se encuentra en el nivel de interpretación.
A continuación se muestra el esquema que se debe cumplir para originar una solicitud
correcta de una reimpresión de un voucher.
Figura 23, Esquema para la reimpresión de un voucher
Parámetro Naturaleza Descripción
crypto Depende
de la
operación
Bandera que indica el nivel de encripción.
no_operacion Depende
de la
operación
Número asignado a la operación original que se
desea cancelar.
Tabla 20, tags complementarios de una reimpresión
//REIMPRESION <?xml version="1.0" encoding="UTF-8" ?> <REPRINTVOUCHER> <business> <id_company>0035</id_company> <id_branch>700</id_branch> <country>MEX</country> <user>0035GPEA0</user>
132
<pwd>11AEA0D1E72ED338FE</pwd> </business> <no_operacion>000012758</no_operacion> <crypto>2</crypto> </REPRINTVOUCHER>
Solicitud de Consulta de Transacciones
Esta función permite al Comercio realizar una consulta de las operaciones que ha
realizado con una referencia o fecha específica.
La funcionalidad es útil cuando el Comercio manda datos únicos en este campo, como
número de cliente, número de factura, número de orden, número de póliza, número de
suscriptor, etc. Se pueden consultar sólo una o todas las operaciones del día.
De la misma forma se debe cumplir con un esquema similar a los anteriores con datos
tanto de identificación como específicos de la operación.
A diferencia de los anteriores esquemas el de consulta devuelve al nivel base un XML con
el resultado de un recodset.
<transacciones> <transaccion> <nu_operaion></nu_operaion> <cd_usuario></cd_usuario> <cd_empresa></cd_empresa> <nu_sucursal></nu_sucursal> <nu_afiliacion></nu_afiliacion> <nb_referencia> </nb_referencia> <cc_nombre><cc_nombre /> <cc_num></cc_num> <cc_tp></cc_tp> <nu_importe></nu_importe> <cd_tipopago></cd_tipopago> <cd_tipocobro></cd_tipocobro> <cd_instrumento></cd_instrumento> <nb_response></nb_response> <nu_auth></nu_auth> <fh_registro></fh_registro> <fh_bank></fh_bank> <cd_usrtransaccion></cd_usrtransaccion> <tp_operacion></tp_operacion> <nb_currency></nb_currency> </transaccion></transacciones>
133
Sexto Paso, Generar Programas Cliente
Una vez establecidos los XML de intercambio se debe generar el programa cliente el cual será el que se instale en las PC’s de los usuarios finales y de donde se generarán las peticiones, este programa representa el nivel base de la pirámide.
Este paso es en donde se establecen los componentes que conformarán el nivel base de
la pirámide, es decir, de donde se generarán las peticiones.
Los componentes de este nivel deben cumplir con las condiciones de comunicación, tanto
de mensajería como de flujo que establece el nivel de interpretación.
En este nivel como se ha mencionado se recomienda generar componentes que incluyan
toda la interacción con el nivel de interpretación y posteriormente a las vistas crearles una
referencia de estos componentes.
Figura 24, Referencia a componentes
Para este caso de estudio se generará un componentes de tipo COM Object (DLL’s) y
bibliotecas Java (JAR’s), con el fin de que este contenga toda la funcionalidad de
interacción con el Web Service que se encuentra en el nivel de interpretación, estos
objetos deben ser capaz de crear los mensajes XML y de enviarlos al nivel de
interpretación así como recibir la respuesta y procesarla de manera correcta, con el fin de
evitar especializar a las interfaces y que de cara a estas el manejo e interacción con los
servicios se quede a nivel de una llamada a un objeto o referencia.
134
Creando Objetos para interacción con el nivel de interpretación
Componente Activex DLL
Un componente es cualquier software compatible con Automatización, por lo que puede
usarse mediante programación en una aplicación personalizada. Incluye controles
ActiveX, servidores de Automatización basados en Visual Basic y servidores de
Automatización basados en Visual C.
La automatización es una tecnología que permite que las aplicaciones proporcionen
objetos de una forma coherente a otras aplicaciones, herramientas de programación y
lenguajes de macros.
Las siglas COM significan Component Object Model que traducido sería algo así como
modelo de objetos componentes. COM es el "modelo de objetos" fundamental sobre el
que se generan OLE (Object Linking and Embedding, Vinculación e incrustación de
objetos) y los controles ActiveX. COM permite que un objeto exponga su funcionalidad a
otros componentes y aloje aplicaciones. Define cómo el objeto se expone a sí mismo y
cómo funciona dicha exposición en procesos y en redes. Además, COM define el ciclo de
vida del objeto.
Los componentes COM son programas que permiten ser utilizados desde otro programas
mediante automatización. Por regla general, los componentes suelen ser bibliotecas
ActiveX (DLL), controles ActiveX (OCX) e incluso ejecutables ActiveX (EXE).
Una ventaja de los componentes COM es que la creación de uno de estos componentes
nos permite escribir un código que "posiblemente" nos servirá para usarlo en más de una
aplicación, además de que ese mismo componente podemos distribuirlo para que otros
programadores puedan usarlo.
Otra ventaja es que si en un futuro queremos hacer cambios en el código de ese
componente, sólo tendremos que distribuir esa biblioteca y no el resto de la aplicación,
incluso puede ser que ese componente se ejecute desde un servidor, con lo cual
simplemente actualizándolo en el servidor, el resto de las aplicaciones "cliente" que lo
utilicen estarán actualizados a la última versión.
135
En este caso de estudio las interfaces que funcionen sobre un sistema operativo Win32
deberán crear una referencia a una DLL, la cual como ya se habia mencionado contendrá
toda la funcionalidad necesaria.
La DLL llamada cpIntegracionEMV.dll debe ser compatible con interfaces de terminales
de punto de venta para las operaciones en las que se requiera la lectura de una tarjeta
bancaria.
El Control cpIntegracionEMV.dll será un componente ActiveX desarrollado en el
esquema de Microsoft “Component Object Model” y permitirá a las interfaces realizar
mediante sus métodos y propiedades, solicitudes de Autorización de Transacciones con
Tarjeta de Crédito y Débito.
El componente podrá ser utilizado en plataformas de desarrollo que soporten este tipo de
componentes (ActiveX dll) como .Net, Visual Basic, Visual C++, Delphi, Power Builder,
entre otros.
Para invocar las funcionalidades del Nivel de Interpretación es necesario integrar la DLL
(cpIntegracionEMV.dll) en las interfaces del Nivel Base. De forma tal que se haga una
instancia de la clase clsCpIntegracionEMV, utilizando el método y parámetros
correspondientes a la transacción que se desea realizar.
La DLL invocará al servicio con los datos de la transacción, con los que el Nivel de
Interpretación hace una solicitud de Autorización de Transacción al procesador que se
encuentra en el Nivel Fuente. El resultado de la Solicitud de Autorización es
proporcionada a la interfaz de acuerdo a las especificaciones de la DLL.
El Control cpIntegracionEMV.dll deberá realizar una conexión a través del protocolo de
HTTPS a el Web Service, por lo que es necesario que las computadoras cliente en las
que se instale la interfaz que utilice la DLL tenga habilitado el acceso a dicho servidor de
transacciones.
Cabe mencionar que el control requerirá realizar conexiones mediante algunas
bibliotecas, que fungirán como referencias o dependencias de este componente.
136
Otro punto importante que vale la pena mencionar es que este componente también
contendrá interacción con dispositivos lectores de tarjetas bancarias.
A continuación se detalla el flujo de operación de una transacción de cobro con presencia
de tarjeta bancaria, desde el componente DLL.
Este flujo que deberá ser programado en la aplicación del Nivel Base, para integrar de
manera efectiva la interacción con el Nivel de Interpretación con el control
cpIntegracionEMV.dll.
# Función Comentario 1 .dbgSetUrl URL al que se conectará la aplicación del Nivel Base con el Nivel de
Interpretación. .dbgSetReader Devuelve true cuando encuentra un lector válido y false cuando no hay
ningún lector conectado. 2 .dbgStartTxEMV Prepara a la DLL y establece la comunicación con el dispositivo de lectura
para iniciar el proceso de la transacción. 3 .chkCc_ExpMonth,
.chkCc_ExpYear,
.chkCc_Name,
.chkCc_Number.
Si la lectura es exitosa, los parámetros chkCc*, la aplicación podrá mostrar los datos correspondientes a la tarjeta leída.
4 .sndVentaDirectaEMV Una vez leída la tarjeta, se debe ejecutar esta función con sus parámetros correspondientes para enviar la transacción al Web Service del Nivel de Interpretación y ejecutar el cobro.
5 getCc_Name, getCc_Number, getCc_ExpMonth, getCc_ExpYear, getCc_Type, getTx_Amount, getTx_Reference, getRspCdResponse, getRspDsResponse, getRspCdError, getRspDsError, getRspAuth, getRspOperationNumber, getRspDsOperationType, . getRspDate, . getRspTime, getRspDsCompany, getRspDsAdress, getRspDsMerchant, getRspVoucher, getRspXML
En este paso las aplicaciones del nivel base deben ejecutar las funciones que traen el resultado de la transacción, principalmente la función getRspDsResponse la cual trae tres posibles valores: “aproved”, “denied” o “error”. Con base al resultado, se sabrá qué acciones tomar, por ejemplo: - Si la transacción fue aprobada la aplicación del Nivel Base podrá llamar a la función getRspVoucher para imprimir el vaucher resultante o la función getRspAuth para obtener el número de autorización asignado a la transacción. - Si la transacción ha sido rechazada se puede mandar un mensaje en pantalla de que la transacción se denegó. - En caso de que el resultado sea “error” puede mandar a llamar la función getRspDsError para saber el detalle del error o la función getRspCdError para saber el código del error generado por el Web Service.
6 dbgEndOperation Antes de salir de la aplicación, se debe ejecutar esta función para eliminar la conexión con el dispositivo de lectura.
Tabla 21, Flujo de Operación control Activex del Nivel Base
137
Con este flujo de operación las aplicaciones del Nivel Base podrán mostrar a los usuarios
el resultado de una petición de cobro bancario.
Se establecen parámetros de conexión
Se establce la URL de Web Service.dbgSetUrl
Se prepara el Lector de Tarjetas Bancarias
El display del PinPad indica que se deslice la tarjeta.dbgSetReader, .dbgStartTxEMV
Cuando el ciclo de lectura termina
Se obtienen los dato de la tarjeta
.chkCc_ExpMonth, .chkCc_ExpYear,
.chkCc_Name, .chkCc_Number.
Se utiliza la función para el envío de cobro con tarjeta
Se envía la solicitud de autorización.sndVentaDirectaEMV
Se analiza la respuesta de la solicitud
Aprobada, Declinada o ErrorgetRspDsResponse
Flujo de Operación
Figura 25, Flujo de Operación control Activex del Nivel Base
En seguida se detallaran cada una de las funciones que contendrá la DLL y que
corresponden a los esquemas que se encuentran en el Nivel de Interpretación.
Solicitud de Cobro bancario a Nivel Base con Activex
En seguida se mostrarán los esquemas en el que se detallan los parámetros que debe
recibir la DLL con los cuales internamente generará el mensaje XML para enviarlo al Nivel
de Interpretación, para cada uno de los métodos del Web Service.
138
La primer operativa a analizar es la de un cobro bancario esta función permitirá a la
aplicación realizar solicitudes de cargo con presencia de tarjeta; aplica para todo tipo de
comercio que tiene ventas de mostrador.
Para realizar una solicitud de cargo con tarjeta, la aplicación que invoque a la DLL deberá
generar una transacción asociada a una referencia, importe, y forma de pago.
Figura 26, Funciones de entrada en la DLL para generar un mensaje de cobro
139
Solicitud de cancelación de un Cobro a Nivel Base con Activex
Esta función permite a la aplicación del Nivel Base cancelar una transacción que se haya
realizado durante el día proporcionando el número de operación, la autorización e
importe.
La operación de cancelación puede ser interpretada como una devolución considerando
que se haga en el mismo momento del cobro.
Figura 27, Funciones de entrada en la DLL para generar un mensaje de cancelación
140
Solicitud de Reimpresión a Nivel Base con Activex
Esta función permite a la aplicación del Nivel Base reimprimir el voucher de una
transacción, para lo cual es necesario enviar el Número de Operación
(Tx_OperationNumber). La función getRspVoucher, devolverá una cadena con el voucher
listo para imprimir; la función getRspXML, devolverá el XML de los campos que componen
el voucher. En caso de que la aplicación del Nivel Base requiera extraer los datos que
contiene el voucher, deberá hacerlo de la función getRspXML.
Figura 28, Funciones de entrada en la DLL para generar un mensaje de reimpresión
141
Solicitud de Consulta de Transacciones a Nivel Base con Activex
Con esta función la aplicación del Nivel Base a través de la DLL, obtendrá detalle de las
transacciones que ha realizado hasta el momento parametrizando por número de
operación, referencia y fecha.
Las aplicaciones debe obtener el resultado del query ejecutado en el Nivel de
Interpretación a través de la función getRespXML en formato XML y con esto la
aplicación deberá ser capaz de procesar el resultado y mostrarlo al usuario o ejecutar
alguna operación propia de dicha aplicación.
Figura 29, Funciones de entrada en la DLL para generar un mensaje de consulta
142
Interfaces a las que aplica el control Activex
Como ya se ha mencionado un control Activex es un componente que puede ser
referenciado por diferentes lenguajes de programación siempre y cuando estos soporten
referencias a este tipo de controles.
Por ejemplo es posible integrar esta DLL en lenguajes como Visual Basic 6, Delphi, Visual
C#, Visual C++, Visual Basic .net, Javascript, VBScript, Visual Data Flex, entre muchos
otros. De hecho esta es la intención de crear un componente que encapsule la
funcionalidad de comunicación con el Nivel de Interpretación, tener las mismas funciones
sin importar la interfaz sobre la cual sea invocada.
Para este caso de estudio se tienen varias interfaces desde las cuales se pretende tener
acceso a esta funcionalidad, además de la posibilidad de que el comercio pueda integrar
a su propia interfaz estas funciones, una de estas interfaces es una aplicación de paquete
que contendrá pantallas para acceder a las funcionalidades y se podrá instalar en
cualquier computadora que contenga que cuente con un sistema operativo basado en
Win32 de de 32 bits, en seguida se muestra un ejemplo de una pantalla de esta interfaz.
Figura 30, Aplicación a 32bits del Nivel Base
143
Otra interfaz que contendrá esta funcionalidad será un dispositivo móvil basado en
Windows Mobile y contendrá de la misma forma una referencia a un componente que se
comunique con el Nivel de Interpretación, en seguida se muestra una pantalla ejemplo de
esta aplicación.
Figura 31, Aplicación basada en Mobile
Por otra parte con este modelo se pueden hacer llamadas al Nivel de Interpretación,
desde el Nivel Base, integrando la DLL en un ambiente Web, a través de un JavaScript, a
continuación se muestra el ejemplo de una pantalla que contendría la funcionalidad en un
ambiente Web.
Figura 32, Aplicación Web del Nivel Base
144
Con lo anterior se demuestra que con este modelo aplicado en el Nivel Base podemos
tener la posibilidad de integrar y masificar el acceso a las funcionalidades que se desean
explotar del Nivel Fuente.
Componente Java JAR
Los archivos JAR fueron principalmente pensados para los applets de Java con el fin de
empaquetar todos los componentes necesarios para su ejecución y es una abreviación de
Java Archive.
Un archivo JAR es una colección de clases Java compiladas y otros recursos que pueden
requerir las clases en tiempo de ejecución, un JAR permite la agrupación de los archivos y
recursos en un archivo que puede ser comprimido y es 100% compatible con archivos Zip.
Un JAR permite empaquetar las clases de un proyecto en un solo archivo y
posteriormente desde otra aplicación hacer una referencia a ese JAR con el fin de obtener
todas las funcionalidades que brinda.
En este caso de estudio, para poder trabajar con aplicaciones que no corran sobre Win32,
se eligió trabajar con archivos JAR, para las aplicaciones del Nivel Base basadas en Java.
La arquitectura JavaBeans está basada en modelos de componentes y programación
orientada a objetos. Los componentes son unidades de software reutilizables e
independientes, que pueden formar componentes compuestos, applets, aplicaciones y
servlets que puede ser utilizado visualmente por una herramientas de programación.
Los componentes JavaBean son conocidos como Beans. Los JavaBeans,
independientemente de su funcionalidad, se definen por las siguientes características.
Los Beans soportan introspección, que permite a una herramienta de programación
analizar cómo funcionan los Beans. Se adhieren a reglas específicas llamada Patrones de
Diseño para nombrar las características de los Beans. Una propiedad es un atributo de un
Bean que afecta a su apariencia. Por ejemplo, un botón puede tener las siguientes
propiedades: el tamaño, la posición, etc.
145
Las herramientas de programación realizan la introspección de un Bean para descubrir
sus propiedades y exponerlos para su manipulación. Las propiedades de un Bean pueden
examinarse y modificarse mediante métodos o funciones miembro, que acceden a dicha
propiedad, y pueden ser de dos tipos:
• Método get: lee el valor de la propiedad
• Método set: cambia el valor de la propiedad.
Conforme a la Programación Orientada a Objetos y la arquitectura JavaBeans, a
continuación se describe la estructura del componente Java JAR que formará parte de los
componentes del Nivel Base.
• Deben existir dos clases que representan los grupos de operativas.
• Cada clase debe contener métodos que son comparables con los pasos de la
transacción a realizar; es decir, representan la funcionalidad de la clase.
• Todos los Beans contarán con sus propios métodos get y set, para obtener y
asignar valores, respectivamente.
• Deben existir Beans de Operación, que soportan la operación de las transacciones.
• Deben existir Beans propios de cada operativa, los cuales almacenan datos propios
de cada operación.
Clases Métodos Beans de Operación Beans propios de cada operativa
Tarjeta Presente • datosTarjeta
• transacciona
• imprime
• cancela
• Receptor
• Transaccion
• Respuesta
VentaDirectaBanda
Administrativas • imprime
• Cancelación
• Reimpresión
• Consultas
• Cancelación
• Reimpresión
• Consultas
Cancelación
Reimpresión
Consultas
Tabla 22, Descripción de Clases
146
Descripción de Métodos de clases
Los métodos son los pasos o funciones que realizan las clases y todos ellos utilizan el
objeto BeanTransaccion. Este es el Bean principal, encargado de soportar otros Beans
necesarios para completar cualquier transacción disponible en el nivel.
Método E/S Descripción
datosTarjeta(BeanTransaccion) • Parámetros: objeto BeanTransaccion
• Devuelve: void • Clases: Se utiliza solo
en TarjetaPresente
Este método es el primer paso a seguir al ejecutar una operación con tarjeta presente ya que es el encargado de establecer comunicación con la terminal lectora de tarjetas asignada en el objeto beanTransaccion en su campo lector.
transacciona(BeanTransaccion) • Parámetros: objeto BeanTransaccion
• Devuelve: void • Clases: Se utiliza en
TarjetaPresente y TarjetaNoPresente
Este método es el encargado de tomar los datos de la empresa receptora y los datos de la tarjeta para realizar una transacción desde el nivel base.
imprime(BeanTransaccion) • Parámetros: objeto BeanTransaccion
• Devuelve: void • Clases: Se utiliza en
TarjetaPresente, TarjetaNoPresente y
• Administrativas
Este es el último paso de una transacción y puede o no ser ejecutado ya que su uso no afecta el resultado de la operación realizada.
cancela() • Parámetros: Ninguno • Devuelve: void • Clases: Se utiliza en
TarjetaPresente
Este método puede ser empleado de manera opcional e idealmente se debe de ejuctar después del método datosTarjeta.
Consultas (BeanTransaccion) • Parámetros: objeto BeanTransaccion
• Devuelve: void • Clases: Se utiliza en
Administrativas
Este método muestra las transacciones que se llevaron a cabo en un día en específico o con una referencia específica. Recibe un objeto Bean de tipo BeanConsultas que tiene asignado el díao referencia que se desea consultar, o ambas, el objeto BeanConsultas está dentro de BeanTransaccion.
Reimpresion (BeanTransaccion)
• Parámetros: objeto BeanTransaccion
• Devuelve: void • Clases: Se utiliza en
Administrativas
Este método sirve para obtener una copia del voucher de determinada transacción. Para hacer esto solo es necesario especificar el número de operación que deseemos reimprimir.
Cancelacion (BeanTransaccion) • Parámetros: objeto BeanTransaccion
• Devuelve: void • Clases: Se utiliza en
Administrativas
Recibe un objeto Bean de tipo BeanCancelacion que tiene asignado el número de operación que se desea cancelar y el número de autorización (auth), el objeto BeanCancelacion está dentro de BeanTransaccion.
Tabla 23, Descripción de Métodos de Clases
147
Descripción de Beans de operación
Como ya se habían mencionado en la tabla anterior, existirán tres tipos principales de
beans con lo que se operará este componente del nivel base, a continuación se
mencionan:
• BeanTransaccion que funciona como contenedor de los demás Beans de
operación.
• BeanReceptor que almacena los datos del comercio en el que se encuentra la
aplicación que integra al objeto Jar.
• BeanRespuesta que contiene el resultado de la operación que fue enviada a los
niveles posteriores.
Bean Descipción
beanTransaccion Este es el Bean principal y es el encargado de soportar otros Beans necesarios para completar cualquier operación desde el nivel base. El BeanTransacción guarda datos del Comercio a través de BeanReceptor y los resultados de la operación en BeanResultados y almacena un Bean propio de la operativa a ejecutar. Por ejemplo, si se va a realizar una Venta Directa Banda, se le asigna a BeanTransaccion un objeto de tipo BeanVentaDirectaBanda, a través de los métodos set del Bean.
beanReceptor Este Bean contiene la información relacionada al negocio, se deben llenar con datos propios del comercio. Contiene además datos generales que son compartidos por diferentes operativas.
beanRespuesta Al término de cualquier operación, el resultado es recibido en un objeto del tipo BeanRespuesta, esta sería la respuesta que viene desde el nivel fuente y ya se encuentra formateada para que la aplicación que integre el componente Jar pueda acceder a todos los datos.
Tabla 24, Descripción de Beans de Operación
Beans de Función
Estos Beans representan las funciones a las cuales se desea acceder, es decir son
aquellas las cuales tienen un esquema en el Nivel de Interpretación. Para acceder a estas
funciones el Jar debe generar un mensaje con un XML que con la información accedida a
a las propiedades de los beans, a continuación se describen los beans de función.
148
Funcionalidad Beans Descripción
Venta Directa Banda • Bean: BeanVentaDirectaBanda • Asignar a Bean Tipo: BeanTransaccion • Parámetros propios: Ninguno
Operación con presencia del cliente y de la tarjeta en el Comercio; los datos de la tarjeta son extraídos por algún dispositivo que lee la banda magnética de la tarjeta o del CHIP para las tarjetas que cuenten con él.
Cancelacion • Bean: BeanCancelacion • Asignar a Bean Tipo: BeanTransaccion • Parámetros propios: operationNumber, auth
Cancela la una transacción que se haya realizado con anterioridad en el comercio.
Reimpresion • Bean: BeanReimpresion • Asignar a Bean Tipo: BeanTransaccion • Parámetros propios: operationNumber
Permite reimprimir un voucher de una trasnacción.
Consultas • Bean: BeanConsultas • Asignar a Bean Tipo: BeanTransaccion • Parámetros propios: date
Esta función permite al Comercio realizar una consulta de las operaciones que ha realizado.
Tabla 25, Beans de Función
Interfaces a las que aplica el componente JAR.
Como podemos observar el JAR integra la posibilidad de explotar las funcionalidades de
los niveles posteriores pero a diferencia de la DLL será a través de aplicaciones hechas
en JAVA, como aplicaciones Web, Swing, Applets, Servlets e incluso otros Web Services.
La aplicación que explotará la funcionalidad del JAR estará basada en WML y WMLS para
terminales punto de venta (TPV).
Estas terminales son pensadas principalmente para comercios que no cuentan con una
computadora y mucho menos que no cuentan con acceso a internet, estas terminales
contienen su propio medio de conexión a través de GPRS de un chip de telefonía celular.
A continuación se muestra una figura que contiene el flujo y algunas pantallas para
acceder a la funcionalidad del Nivel de Interpretación desde una TPV.
Figura 33, Aplicación TPV Nivel Base
149
Resultados Obtenidos
Si recordamos la problemática de este caso de estudio podremos darnos cuenta que se
han obtenido resultados satisfactorios.
El problema nace por la necesidad de poder implementar la plataforma de La Aplicación de Cobros Bancarios en diferentes escenarios con el fin de poderlo masificar y utilizar desde diversos dispositivos, pero siempre cumpliendo con diferentes estándares de seguridad y resguardo de la información.
Como podemos darnos cuenta al final en seis pasos obtuvimos una pirámide con tres
niveles en el primero (Nivel Base) un par de componentes integrables (DLL y JAR) a
diferentes aplicaciones desarrolladas en distintos lenguajes de programación y que se
comunican con el Nivel de Interpretación a través de mensajes XML por medio de SOAP.
En el segundo nivel (Nivel de Interpretación) obtuvimos un Web Service y una base de
datos con diversas reglas de negocio que permiten garantizar la consistencia y
persistencia de los datos este Web Service se comunica con el Nivel Base de la misma
forma, a través de responder a las peticiones por medio de SOAP y con mensajes en XML
y que se comunica con el Nivel Fuente a través de sockets y con hilo de monitoreo,
enviando mensajes ISO 8583.
En el tercer nivel (Nivel Fuente), tenemos un procesador de transacciones bancarias que
se considera como una caja negra ya que no se tiene el control sobre el comportamiento
de este y que se comunica con el Nivel de Interpretación por medio de sockets y recibe y
contesta con mensajes de tipo ISO 8583.
Con esta implementación se permitió a la aplicación ser modificable e integrable en varios
puntos de venta sin importar la interfaz y lenguaje de programación de este y así desde el
punto de vista comercial se obtuvo una aplicación que se puede ofrecer a más clientes de
distintos tipos.
150
Conclusiones
El patrón piramidal es un conjunto de herramientas orientadas a la creación arquitectónica
de soluciones distribuidas, buscando siempre un punto genérico con el fin de hacer
genéricas a las soluciones como tal, y por lo tanto poder aplicarlas a diversos proyectos,
principalmente aquellos que pretendan masificar soluciones.
El patrón piramidal permite crear estructuras arquitectónicas basadas en tres Niveles
conformados en forma jerárquica. Cada Nivel cuenta con una funcionalidad en específico,
el Nivel Base que es el primer nivel de la pirámide y del que nacen las peticiones, el Nivel
de Interpretación él se segundo nivel de la pirámide y es el primero que recibe las
peticiones del Nivel Base y en el cual se hacen las validaciones de reglas de negocio y
manejo de bases de datos, por último se encuentra el Nivel Fuente el cual contiene
servicios de terceros y al cual finalmente llegan las peticiones para ser procesadas.
Cabe mencionar que durante el paso de los mensajes estos se van adaptando entre
niveles para poder literalmente “hablar” un mismo lenguaje.
Con el patrón piramidal no debe haber limitaciones de lenguajes de programación ya que
la comunicación entre los Niveles debe estar basada en protocolos de comunicación
estándar como SOAP y los mensajes pueden estar conformados por cadenas por ejemplo
XML lo cual también es estándar. Por este punto es posible utilizar diferentes lenguajes
entre los Niveles.
El patrón piramidal en consecuencia puede ser aplicado a soluciones basadas
principalmente en servicios. Por ejemplo se podría tener un sistema que despachara
tiempo aire, con la posibilidad de comprar tiempo aire desde diferentes dispositivos y mas
aun la empresa que decidiera vender ese tiempo aire pudiera tener control total de las
peticiones que le llegan.
Hablando en un sentido más amplio en la actualidad es posible conectarse con un Web
Service de las compañías de telefonía celular. Con esto podemos considerar como el
Nivel Fuente el Web Service de la compañía de telefónica celular, también es posible
151
generar un Web Service que explote el Web Service de la telefonía y es posible que es
mismo Web Service tenga acceso a una base de datos que se encuentre en su mismo
servidor y en la cual se puedan almacenar todas los datos asociados a la venta de tiempo
aire así como datos asociados a comercios que pretendan vender tiempo aire, finalmente
también es posible generar componentes que se comuniquen con el web service que
tiene el acceso a la base de datos y generar vistas que referencien a estos componentes.
Con lo anterior tenemos todos los elementos para generar mensajes de comunicación
entre los niveles, aplicar reglas de negocio y mejor aún podemos implementar una
aplicación que corra desde cualquier dispositivo y que llame al Web Service de acceso a
datos y no al Web Service de la compañía celular directamente.
Con esto es posible masificar esta solución y agregar la posibilidad a los comercios
asociados que puedan vender tiempo aire desde una aplicación ya existente que ellos
utilicen con solo implementar alguno de los componentes del Nivel Base o con una
aplicación propia del comercio que ofrezca el servicio, por ejemplo en un restaurante ya
cuentan con sistemas hechos a su medida que les ayudan a llevar un control de sus
órdenes y en general de su operación, entonces con esto es posible integrar a su sistema
un componente del Nivel Base y añadir a este mismo sistema la posibilidad de acceder a
la venta de tiempo Aire.
Figura 34, Patrón Piramidal de Venta de Tiempo Aire
152
Como es notable una característica y fin también de este patrón es la posibilidad de
integrar la solución a aplicaciones ya generadas por terceros añadiendo algún
componente del Nivel Base, inclusive comercialmente hablando una empresa que venda
un servicio bajo este patrón podrá tener acceso a mayor cantidad de clientes.
El patrón piramidal también pretende ayudar a generar soluciones propias de una
empresa con la posibilidad de aumentar el acceso a los servicios desde diferentes
dispositivos.
En resumen el patrón piramidal permite generar soluciones arquitectónicas fácilmente
integrables y flexibles para sistemas distribuidos.
Con el patrón arquitectónico piramidal se puede tener más control y registro de
actividades de los usuarios y permite principalmente masificar servicios propios y de
terceros.
153
Glosario
A A2A – Aplication to Aplication, es la forma de llamar a la arquitectura de comunicación
entre dos aplicaciones.
ADL - Lenguaje de Descripción Arquitectónica - Architecture Description Language), es un
enfoque lingüístico a la representación formal de una arquitectura.
ALTOVA XML SPY - Es un entorno de desarrollo XML, que proporciona intuitivas vistas y
potentes utilidades para modelar, editar, transformar y depurar tecnologías relacionadas
con XML de forma rápida y fácil. XMLSpy incluye un original diseñador gráfico de
esquemas XML, permitiendo diseñar y documentar complejos esquemas fácilmente.
ATM - Automated Teller Machine, Es una forma en de llamar a los cajeros automáticos
que se encuentran en los bancos.
C CORBA - Common Object Request Broker Architecture — arquitectura común de
intermediarios en peticiones a objetos
CSC - Card Security Code, es una característica de seguridad para tarjeta de crédito o
débito, con el fin de dar protección contra fraude, son los últimos tres dígitos de la parte
posterior de una tarjeta bancaria, también se conoce como CVV o CVC.
D
154
DLL - Una biblioteca de enlace dinámico es el término con el que se refiere a
los archivos con código ejecutable que se cargan bajo demanda de un programa por parte
del sistema operativo.
F Framework - Se refieren a dominios o clases de problemas específicos
G GoF - Design Patterns: Elements of Reusable Object-Oriented Software
Gateway - Un gateway (puerta de enlace) es un dispositivo, con frecuencia un ordenador,
que permite interconectar redes con protocolos y arquitecturas diferentes a todos los
niveles de comunicación. Su propósito es traducir la información del protocolo utilizado en
una red al protocolo usado en la red de destino.
I ISO 8583 - Standard para Transacciones Financieras con Mensajes originados en una
tarjeta - Especificaciones de los mensajes de intercambio es el standard de la
International Organization for Standardization para sistemas que intercambian
transacciones electrónicas realizadas por poseedores de tarjetas de crédito.
J JAR - Un archivo JAR (por sus siglas en inglés, Java ARchive) es un tipo de archivo que
permite ejecutar aplicaciones escritas en lenguaje Java.
155
M MIL - Lenguajes de interconexión de módulos
O OCX - Es un acrónimo que significa "OLE Control Extensión". OLE a su vez significa
Object Linking and Embedding. OCX hace referencia a módulos que publican controles y
funciones para ser utilizados en programas para Windows, incluyendo especialmente el
navegador Internet Explorer. Típicamente, estas bibliotecas se presentan en bibliotecas
de enlace dinámico (DLL) almacenadas con extensión .OCX.
S SOAP - (siglas de Simple Object Access Protocol) es un protocolo estándar que define
cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio
de datos XML. Este protocolo deriva de un protocolo creado por David Winer en 1998,
llamado XML-RPC. SOAP fue creado por Microsoft, IBM y otros y está actualmente bajo
el auspicio de la W3C. Es uno de los protocolos utilizados en los servicios Web.
T TADG/ TISAF - Treasury Architecture Development Guidance/ Treasury Information
System Architecture Framework
TPV - Terminal Punto de Venta
U
156
UML - Lenguaje Unificado de Modelado / UML, por sus siglas en inglés, Unified Modeling
Language
W WSDL - "Lenguaje de Descripción de Servicios Web" (o "Web Services Description
Language"), Lenguaje basado en XML que permite la descripción de servicios web
desplegados. WSDL se utiliza también para la localización y ubicación de servicios en
Internet.
X XML - Siglas en inglés de eXtensible Markup Language (lenguaje de marcas extensible),
es un metalenguaje extensible de etiquetas desarrollado por el World Wide Web
Consortium (W3C).
XSD - Los esquemas XSD son un vocabulario para expresar las reglas de los datos que
se utilizarán y sirve de referencia para validar los datos que aparecerán en un XML
157
Bibliografía
Paul Clements. “A Survey of Architecture Description Languages”. Proceedings of the
International Workshop on Software Specification and Design, Alemania, 1996.
David Garlan. “Software Architecture: A Roadmap”. En Anthony Finkelstein (ed.), The
future of software engineering, ACM Press, 2000.
Mary Shaw y David Garlan. “Software Architecture: Perspectives on an emerging
discipline”. Upper Saddle River, Prentice Hall, 1996.
Philippe Kruchten. “The 4+1 View Model of Architecture”, IEEE Computer Society and the
ACM, Nombiembre de 1995
C. Alexander, S. Ishikawa, M. Silverstein, M. Jacobson, I. Fiksdahl-King, y S. Angel, "A
Pattern Language", Oxford University Press, New York, 1977.
Using Pattern Languages for Object-Oriented Programs Kent Beck, Apple Computer, Inc.
Ward Cunningham, Tektronix, Inc. September 17, 1987
Design Patterns. Elements of Reusable Object-Oriented Software - Erich Gamma, Richard
Helm, Ralph Johnson, John Vlissides - Addison Wesley (GoF- Gang of Four). 1995.
Pattern-Oriented Software Architecture Volume 1: A System of Patterns, Frank
Buschmann , Regine Meunier, Hans Rohnert, Peter Sommerlad, Michael Stal, 1996.
Alexander Wolf. “Succeedings of the Second International Software Architecture
Workshop” (ISAW-2). ACM SIGSOFT Software Engineering Notes, pp. 42-56, enero de
1997.
Steve Vestal. “A cursory overview and comparison of four Architecture Description
Languages”. Technical Report, Honeywell Technology Center, Febrero de 1993.
Robert Monroe. “Capturing software architecture design expertise with Armani”.
158
Technical Report CMU-CS-163, Carnegie Mellon University, Octubre de 1998.
Mary Shaw y David Garlan. “Characteristics of Higher-Level Languages for Software
Architecture”. Technical Report CMU-CS-94-210, Carnegie Mellon University, Diciembre
de 1994.
Neno Medvidovic. “A classification and comparison framework for software Architecture
Description Languages”. Technical Report UCI-ICS-97-02, 1996.
P. Clements L. Bass and R. Kazman. Software Architecture in Practice. Addison–Wesley,
1998.
David Garlan, D. Monroe, and D. Wile. ACME: An architectural interchange language. In
Proc. of the XIX th Intl. Conference on Software Engineering. ICSE’ 97, Boston, 1997.
Marshall K. McKusick, George V. Neville-Neil, The Design and Implementation of the
FreeBSD Operating System (Addison Wesley, Agosto 2, 2004).
ISO 8583-1:2003, financial transaction card originated messages - Interchange message
specifications - Part 1: Messages, data elements and code values (Agosto 23, 2007)
Priscilla Walmsley, Definitive XML Schema, 1st edition, Prentice Hall PTR; ISBN:
0130655678, (Diciembre de 2001).
David C. Fallside, Priscilla Walmsley, XML Schema Part 0: Primer Second Edition, W3C
Recommendation 28 October 2004.
Pattern-Oriented Software Architecture, Patterns for Concurrent and Networked Objects,
Volume 5, Douglas Schmidt, Michael Stal, Hans Rohnert and Frank Buschmann, ISBN:
0471606952, 2007.
