1

INSTITUTO POLITCNICO NACIONAL

UNIDAD PROFESIONAL INTERDISIPLINARIA DE INGENIERA Y
CIENCIAS SOCIALES Y ADMINISTRATIVAS


SECCIN DE ESTUDIOS DE POSGRADO E INVESTIGACIN


PATRONES ARQUITECTNICOS PARA PROGRAMACIN
DISTRIBUIDA



T E S I S


PARA OBTENER EL GRADO DE
MAESTRO EN CIENCIAS EN INFORMTICA

P R E S E N T A

MICHAEL ROJAS RODRGUEZ



DIRECTORES:
MC. ELIZABETH ACOSTA GONZAGA
MC. JESS ANTONIO ALVAREZ CEDILLO


MEXICO, D.F. 2010
2

3


CARTA CESIN DE DERECHOS







En la Ciudad de Mxico D.F el da 26 el mes de Noviembre del ao 2010, el que suscribe Michael
Rojas Rodrguez alumno del Programa de Maestra en Ciencias en Informtica con nmero de
registro B081882, adscrito a la Seccin de Estudios de Posgrado de la UPIICSA-IPN, manifiesta
que es autor intelectual del presente trabajo de Tesis bajo la direccin de la M. en C. Elizabeth
Acosta Gonzaga y el M. en C. J ess Antonio lvarez Cedillo y cede los derechos del trabajo
intitulado Patrones Arquitectnicos Para Programacin Distribuida, al Instituto Politcnico
Nacional para su difusin, con fines acadmicos y de investigacin.


Los usuarios de la informacin no deben reproducir el contenido textual, grficas o datos del trabajo
sin el permiso expreso del autor y/o director del trabajo. Este puede ser obtenido escribiendo a la
siguiente direccin michaelrojasr@gmail.com Si el permiso se otorga, el usuario deber dar el
agradecimiento correspondiente y citar la fuente del mismo.


INSTITUTO POLITCNICO NACIONAL
SECRETARA DE INVESTIGACIN Y POSGRADO
4

AGRADECIMIENTOS


El principal agradecimiento es a mis padres quienes siempre me han apoyado y han
credo 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 motivacin ellos me lo han otorgado. Muchas
gracias Pap y Mam por sus sabios y sinceros consejos.

A mis hermanos Connie y Sergio quienes me guan y apoyan. Se que puedo contar con
ustedes siempre.

A mis profesores quienes con sus conocimientos, consejos y ayuda he podido lograr un
paso ms 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 J ess lvarez, por la buena disposicin 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 Rodrguez







5

ndice
Resumen .............................................................................................................................. 12
Summary .............................................................................................................................. 13
Introduccin .......................................................................................................................... 14
Planteamiento de la problemtica ....................................................................................... 16
Objetivos .............................................................................................................................. 17
J ustificacin .......................................................................................................................... 18
Alcances ............................................................................................................................... 19
Resultados Esperados ......................................................................................................... 20
Limitaciones ......................................................................................................................... 20
Marco terico ....................................................................................................................... 21
CAPITULO 1, Una visin esencial de la arquitectura de software y patrones .................... 24
Sistemas de informacin distribuidos ............................................................................... 25
Arquitectura de Software .................................................................................................. 31
Vistas Arquitectnicas....................................................................................................... 39
Patrones ............................................................................................................................ 42
Tipos de Patrones ............................................................................................................. 44
Patrones de diseo ........................................................................................................ 44
Patrones de creacin ..................................................................................................... 46
Patrones estructurales ................................................................................................... 46
Patrones de comportamiento ......................................................................................... 47
Patrones arquitectnicos .................................................................................................. 49
El Futuro de los Patrones ................................................................................................. 51
Lenguajes de Descripcin Arquitectnica (ADLs) ........................................................... 54
Lenguaje Acme-Armi ..................................................................................................... 58
CAPITULO 2, Patrones Arquitectnicos desde perspectivas actuales ............................... 60
Patrn Arquitectnico Modelo Vista Controlador (MVC) .................................................. 61
Modelo (Model): ............................................................................................................. 61
Vista (View): ................................................................................................................... 61
Controlador (Controller): ................................................................................................ 62
Patrn Arquitectnico Broker ............................................................................................ 63
Objetivo del patrn Broker ............................................................................................. 64
6

Motivacin ...................................................................................................................... 64
Usos Conocidos del patrn arquitectnico Broker ........................................................ 65
Caractersticas Benficas del Patrn Arquitectnico Broker ......................................... 66
Patrn Arquitectnico Pipes and Filters ........................................................................... 67
Contexto ......................................................................................................................... 67
Motivacin ...................................................................................................................... 67
Usos Conocidos ............................................................................................................. 68
CAPITULO 3. Propuesta de solucin usando el Patrn Arquitectnico Piramidal y la
Arquitectura Piramidal de Sistemas Distribuidos ................................................................ 69
El Patrn Piramidal ........................................................................................................... 70
Caractersticas de Niveles ............................................................................................. 71
Flujo de Operacin del Patrn Piramidal ....................................................................... 72
Caractersticas Generales ............................................................................................. 74
Ventajas del Patrn Piramidal ....................................................................................... 75
El Patrn Piramidal desde una perspectiva genrica .................................................... 77
Introduccin al caso de estudio ........................................................................................ 78
Modelo Bsico de Operacin ......................................................................................... 78
Procesamiento de Medios de Pago Electrnicos .......................................................... 80
Problemtica .................................................................................................................. 80
Explicacin Tcnica de la Problemtica ........................................................................ 81
Propuesta de Solucin a la problemtica ...................................................................... 82
Flujo de Implementacin del Patrn Piramidal .............................................................. 89
CAPTULO 4, Implementando el Patrn Piramidal. ............................................................ 92
Consideraciones Previas .................................................................................................. 93
Nivel Base ...................................................................................................................... 93
Nivel de Interpretacin ................................................................................................... 94
Nivel Fuente ................................................................................................................... 94
Primer Paso, Especificar Reglas a Nivel Base de Datos ................................................ 95
Definicin 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 forneas ...................................................................................................... 100
Cluster .................................................................................................................... 100
Trigger .................................................................................................................... 100
Procedimiento ........................................................................................................ 101
Funcin .................................................................................................................. 101
Secuencia .............................................................................................................. 101
Ligas de base de datos (database link) ................................................................. 102
Sinnimo ................................................................................................................ 102
Paquete .................................................................................................................. 102
Usuario ................................................................................................................... 102
Role ........................................................................................................................ 103
Profile ..................................................................................................................... 103
Segundo Paso, Manipulacin de la Base de Datos ...................................................... 104
Tercer Paso, Anlisis y Desarrollo del Web Service ..................................................... 106
Cuarto Paso, Protocolos de Comunicacin y Conexin con servicios .......................... 110
Protocolo de comunicacin ......................................................................................... 110
Estndar ISO 8583, Conexin con el procesador bancario ....................................... 111
Quinto paso, Lenguaje y medio de comunicacin entre el nivel base e interpretacin 117
Esquemas XSD como Lenguaje de Interpretacin .................................................... 117
Atributos ................................................................................................................. 118
Ejemplo de un esquema XSD ................................................................................ 119
Notacin XSD para el nivel de interpretacin ............................................................. 120
Solicitud de Cobro bancario ................................................................................... 123
Solicitud de cancelacin de un Cobro ................................................................... 128
Solicitud de Reimpresin ....................................................................................... 130
Solicitud de Consulta de Transacciones ................................................................ 132
Sexto Paso, Generar Programas Cliente ...................................................................... 133
Creando Objetos para interaccin con el nivel de interpretacin ............................... 134
Componente Activex DLL ...................................................................................... 134
Solicitud de Cobro bancario a Nivel Base con Activex ...................................... 137
Solicitud de cancelacin de un Cobro a Nivel Base con Activex ....................... 139
Solicitud de Reimpresin 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
Descripcin de Mtodos de clases .................................................................... 146
Descripcin de Beans de operacin .................................................................. 147
Beans de Funcin .............................................................................................. 147
Interfaces a las que aplica el componente J AR. ................................................ 148
Resultados Obtenidos.................................................................................................... 149
Conclusiones..................................................................................................................... 150
Glosario ............................................................................................................................. 153
Bibliografa ........................................................................................................................ 157























9

ndicedeTablas
Tabla 1, Caractersticas del patrn arquitectnico Broker .................................................. 64
Tabla 2, Herramientas del Nivel Base ................................................................................. 93
Tabla 3, Herramientas del Nivel de Interpretacin .............................................................. 94
Tabla 4, Herramientas del Nivel Fuente .............................................................................. 94
Tabla 5, Descripcin de Procedimientos .......................................................................... 105
Tabla 6, Descripcin de Clases ........................................................................................ 106
Tabla 7, Descripcin de los Mtodos de la Clase XMLServices ...................................... 107
Tabla 8, Descripcin de los Mtodos de la Clase ISOServices ....................................... 107
Tabla 9, Descripcin de los Mtodos de la Clase ValidateService .................................. 108
Tabla 10, Descripcin de los Mtodos de la Clase DBService ........................................ 108
Tabla 11, Descripcin de los Mtodos de la Clase SecurityService ................................ 108
Tabla 12, Descripcin de los Mtodos de la Clase LogService ....................................... 109
Tabla 13, Descripcin de los Mtodos de la Clase ComServices .................................... 109
Tabla 14, Descripcin de los Mtodos de la Clase TransactionServices ........................ 109
Tabla 15, BitMap de un mensaje ISO 8583 ...................................................................... 114
Tabla 16, Definicin 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 cancelacin ...................................... 130
Tabla 20, tags complementarios de una reimpresin ...................................................... 131
Tabla 21, Flujo de Operacin control Activex del Nivel Base ........................................... 136
Tabla 22, Descripcin de Clases ...................................................................................... 145
Tabla 23, Descripcin de Mtodos de Clases .................................................................. 146
Tabla 24, Descripcin de Beans de Operacin ................................................................ 147
Tabla 25, Beans de Funcin ............................................................................................. 148

10

ndicedeFiguras
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 grficamente el patrn MVC. ................. 62
Figura 6. Niveles del Patrn Piramidal ................................................................................ 70
Figura 7, Patrn Piramidal, un enfoque genrico ................................................................ 77
Figura 8, Partes que conforman el modelo base ................................................................. 79
Figura 9, Arquitectura Actual de la aplicacin de cobros bancarios ................................... 82
Figura 10, Procesamiento Electrnico de Transacciones. .................................................. 84
Figura 11, Componentes del Nivel Base ............................................................................. 85
Figura 12, El Lenguaje XML ................................................................................................ 86
Figura 13, Componentes del Nivel de Interpretacin .......................................................... 87
Figura 14, Componentes del Nivel Fuente .......................................................................... 88
Figura 15, Patrn Piramidal ................................................................................................. 89
Figura 16, Flujo de Implementacin del Patrn Piramidal. .................................................. 91
Figura 17, Agrupacin de tablas transaccionales y no transaccionales ............................. 95
Figura 17 Protocolo de Comunicacin entre el nivel de interpretacin y el nivel fuente . 110
Figura 18, Pas de mensajes IS0 8583 entre niveles de interpretacin y fuente. ........... 111
Figura 19, El estndar ISO 8583 ...................................................................................... 113
Figura 20, elemento business de los esquemas del nivel de interpretacin .................... 120
Figura 21, Esquema XSD para la operativa de cobros bancarios ................................... 123
Figura 22, Esquema para la cancelacin de un cobro ..................................................... 129
Figura 23, Esquema para la reimpresin de un voucher ................................................. 131
Figura 24, Referencia a componentes ............................................................................. 133
Figura 25, Flujo de Operacin 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 cancelacin .. 139
Figura 28, Funciones de entrada en la DLL para generar un mensaje de reimpresin... 140
Figura 29, Funciones de entrada en la DLL para generar un mensaje de consulta ........ 141
Figura 30, Aplicacin a 32bits del Nivel Base .................................................................. 142
11

Figura 31, Aplicacin basada en Mobile ........................................................................... 143
Figura 32, Aplicacin Web del Nivel Base ........................................................................ 143
Figura 33, Aplicacin TPV Nivel Base .............................................................................. 148
Figura 34, Patrn Piramidal de Venta de Tiempo Aire ..................................................... 151
12

Resumen

Hoy en da muchos de los grandes sistemas son pensados para operar en forma
distribuida, con el fin de centralizar la informacin y as de llevar cada vez ms orden y
control en la operacin de los comercios, el problema es que normalmente no se piensa
en que tan fcil o difcil sera 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 patrn que sirva
como base para generar soluciones tomando sus elementos.

Los patrones en la ingeniera de software sirven principalmente para dar orden a
soluciones y plantear estructuras orientadas a resolver problemas recurrentes. As
tambin se tiene que los patrones arquitectnicos 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 tambin exhortar al uso y creacin de
patrones con el fin evitar orientar la solucin a los problemas en aplicaciones sumamente
especficas y en lugar de estos hacer soluciones flexibles y orientadas a la reutilizacin.

Es uno de los principales fines de este trabajo obtener un patrn base y flexible que
permita ser implementado en sistemas distribuidos con informacin centralizada que
pretendan ofrecer servicios a una gran cantidad de comercios sin importar que algn
comercio maneje alguna infraestructura especial, es decir se pretende que existan
componentes adaptables a diferentes necesidades. En resumen tener un patrn genrico
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 dont 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

Introduccin

La intencin de este trabajo nace del esfuerzo de continuar con la creacin de generar
soluciones genricas para problemas o situaciones recurrentes y para generacin de
soluciones que puedan masificarse, principalmente basadas en servicios.

Si un mismo problema se presenta en un entorno diferente no se tenga que disear de
nuevo otra solucin.

Nace con la necesidad de que un evento se presenta recurrentemente en varios contextos
y se puede dar solucin una sola vez y con base a un patrn poder reutilizar esa solucin
exitosamente. Hablamos de la solucin como un todo como el esqueleto o la estructura,
es decir, se piensa combatir el problema desde una perspectiva ms 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.
Creacin de componentes o mdulos.
Mejoras a las funcionalidades.
Para lo cual se propone una forma estndar para crear un patrn arquitectnico
que permita replicar una solucin de una situacin especfica dentro de un
contexto distribuido.

Para lo cual se deben tomar en cuenta varias situaciones que a continuacin se
describen:

1. Conocer la situacin, es decir, hacer un anlisis.

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 solucin o se
trata de una situacin nica.

4. Evaluar los escenarios en los que se presenta, con el fin de analizar la forma en
que podra comportarse el patrn.

5. Identificar si ya existen patrones que puedan adaptarse.

6. Generar una pseudo solucin de la situacin, es decir hacer un primer
acercamiento a la solucin.

7. Generar un formato o utilizar uno ya existente para el patrn (GoF, IBM), o incluso
hacer una combinacin productiva y adaptable

8. Generar el patrn con su conjunto de pasos.

9. Probar el patrn en los diferentes escenarios y evaluar el comportamiento.

10. Hacer una retroalimentacin si as lo requiriera.

11. Y por ltimo implementar el patrn.

12. Documentacin con respecto a la implementacin y mantenimiento.


16

Planteamientodelaproblemtica

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 ms de una empresa de produccin de artculos.

Es an ms interesante cuando son empresas ms grandes o que cuentan con
sucursales, es difcil 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 disea una solucin a la medida para cada
entorno y depende de la magnitud de la empresa los mdulos, herramientas,
infraestructura, costos y funcionalidades adicionales, lo que ocasiona que si el mismo
problema se presenta en un entorno diferente se tenga que disear de nuevo otra
solucin para dicho entorno.

En las empresas consultoras cuando se enfrentan al diseo de una solucin para alguno
de sus clientes, a menudo los lderes de proyecto piensan en generar la solucin ms
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 cdigo o de los componentes
sino de la solucin como tal.

Muchas veces cuando se construye una solucin a la medida no se piensa ms all de
que satisfaga las necesidades especficas del cliente en ese momento, muchas veces no
se considera la reutilizacin o ms comn no se piensa en una arquitectura como tal al
momento de estar generando la solucin.
17

Objetivos

Motivar al uso y construccin de patrones arquitectnicos principalmente enfocados al
desarrollo de aplicaciones distribuidas en problemas empresariales.

Demostrar que la construccin correcta de un patrn arquitectnico lleva a la reutilizacin
de la solucin en casos recurrentes y su representacin en formas como imgenes y
diagramas.

Exponer los elementos esenciales que debe incluir un patrn arquitectnico al momento
de estar siendo construido.

Mostrar los diferentes tipos de patrones arquitectnicos y entender en qu momento
pueden ser aplicados.

Sugerir una tcnica para la construccin de patrones arquitectnicos enfocados al
desarrollo de aplicaciones distribuidas, con el fin de que al implementar esta sugerencia
de tcnica se pueda llegar a un mismo resultado en diferentes contextos.

18

Justificacin

En la actualidad por el crecimiento de las empresas y en general por las nuevas
necesidades y la masificacin del internet y otros recursos, el tipo de soluciones para una
empresa est ms 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 solucin, lo que implica el uso de patrones arquitecticos aplicados a
soluciones distribuidas.

Con el uso de patrones se abre la posibilidad de llevar una solucin a diversos entornos
empresariales, implicar a los patrones como parte del diseo y construccin de una
aplicacin pone en ventaja a la empresa desarrolladora de la solucin.

En muchas organizaciones que se dedican al desarrollo de sistemas distribuidos la
mayora de las veces no se considera el uso de patrones arquitectnicos, ya que como se
comentaba anteriormente, se prefiere basar los esfuerzos en el desarrollo de aplicacin
rpidas y totalmente a la medida, muchas veces no se considera invertir el tiempo
suficiente en disear un patrn que en su momento al encontrar algn problema similar
puede aplicarse sin volver a centrar esfuerzos en el diseo, puesto que en ese caso la
estructura de la aplicacin ya estara lista.

Es importante considerar que si una vez se trabaja como se debe no habr necesidad de
hacer lo mismo de nuevo, ms cuando el problema se presenta de forma recurrente.

19

Alcances

Partiendo de la definicin de patrones arquitectnicos, 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, tambin tienen una serie de directivas para
organizar los componentes del mismo sistema, con el objetivo de facilitar la tarea del
diseo de tal sistema, tenemos que este trabajo tiene como fin aportar la idea de la
construccin de patrones arquitectnicos 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 construccin y diseo
de la solucin.

El trabajo mostrar los elementos esenciales de un patrn arquitectnico, las formas
conocidas de hacerlo y se propondr una alternativa basada en tres escenarios reales
distintos, con el propsito de mostrar que es posible reutilizar una solucin si se tiene
desde un principio un enfoque genrico.

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 travs de un ADL
(Lenguaje de Descripcin Arquitectnica - Architecture Description Language), con el fin
de formalizar la forma de representarlo. Adicionalmente a de los ADL tambin se
mostrarn otras formas de representar a los patrones arquitectnicos.

Se expondrn 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 construccin
de patrones arquitectnicos en la programacin distribuida.





20

ResultadosEsperados

Se espera demostrar que el uso de patrones arquitectnicos en la construccin de
aplicaciones especficamente distribuidas es muy importante y permite construir una sola
vez la solucin para problemas recurrentes recomendablemente en diversos contextos.

Se pretende sugerir una tcnica en la construccin de patrones para aplicaciones
distribuidas. As tambin se pretende partir de patrones ya existentes para que sirva como
apoyo en la construccin de la tcnica sugerida.

Se espera demostrar a travs de un experimento en tres organizaciones con el mismo
problema y aplicando el mismo patrn que es posible lograr la solucin del problema
planteado en todos los casos.

Limitaciones

No se expondrn a detalle patrones existentes.
No se mostrarn a detalle especificaciones propias de los lenguajes ADL.
No se estudiarn a detalle casos de patrones arquitectnicos no orientados a
sistemas distribuidos.
No se considerarn patrones arquitectnicos para programacin paralela.

21

Marcoterico

En este trabajo se pretende hacer una investigacin a base de experimentos para
demostrar que la construccin y uso de patrones arquitectnicos enfocados al desarrollo
de aplicaciones distribuidas permite la reutilizacin de la solucin en diferentes contextos
donde se presente un problema similar o recurrente.

El tipo de investigacin que se tomar en este trabajo es la investigacin aplicada ya que
est basada en la bsqueda intencionada de conocimiento o soluciones a problemas y
bsicamente lo que en este trabajo se est buscando.

Se considera que esta investigacin es aplicada, porque est relacionada con la
generacin de conocimientos en forma de teora o mtodos que se estima que en un
perodo mediato podran desembocar en aplicaciones al sector productivo.

Al momento de plantear el mtodo para generar la tcnica sugerida para la construccin
de patrones arquitectnicos se tomar en cuenta el formato GoF, el cual consiste en
encontrar elementos o secciones de una situacin que es recurrente. Dicho formato
consiste en la consideracin 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, J ohn Wiley and Sons para la construccin de
patrones arquitectnicos, el cual consiste en los siguientes elementos:

Name
Problem
Context
Forces
Solution
Resulting Context
Examples
Rationale
Related Patterns
Known Uses
Se tomar en cuenta tambin 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
especificacin describe el fundamento, estructura y taxonoma para patrones
arquitectnicos 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 construccin de patrones
arquitectnicos basados en aplicaciones distribuidas.

El formato definido en el documento TADG para patrones arquitectnicos, 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 tomarn en cuenta para apoyo a la aportacin.

Client-Proxy Server
Customer Support
Reactor
Replicated Servers
Layered Architecture
Pipe and Filter Architecture
Subsystem Interface
24

CAPITULO 1, Una visin esencial de la arquitectura de software y
patrones







En este captulo se expondrn temas esenciales referentes a la arquitectura de software y
de los patrones, as tambin se busca generar una visin global del tema principal de esta
tesis.

Tambin 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 captulo se tocan temas como la Arquitectura de Software desde
diferentes perspectivas, definicin y tipos de patrones, vitas arquitectnicas, lenguajes de
descripcin arquitectnica, etctera.
25

Sistemasdeinformacindistribuidos

Cuando sale a la luz el tema de los patrones arquitectnicos es posible recurrir a las
aplicaciones o sistemas en los que su arquitectura est basada en programacin
distribuida, actualmente la mayora de los sistemas son basados en arquitecturas
distribuidas, son muy pocos los sistemas que se encuentran bajo una arquitectura
monoltica.
Un sistema de informacin distribuido es un sistema en el cual sus componentes se
transmiten informacin, del tipo que sea mediante mensajes, pueden intervenir varios
actores, los cuales de alguna manera participan en el proceso de circulacin de la
informacin entre ellos, de forma independiente el uno del otro.
Tambin es posible comentar que un sistema de informacin distribuido es una coleccin
de elementos de que se encuentran fsicamente separados y no comparten una memoria
comn, se comunican entre s a travs del intercambio de mensajes utilizando un medio
de comunicacin.
En un sistema distribuido, podemos considerar ciertos factores caractersticos 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 estndar.
Medios de comunicacin.
Capacidad de Procesamiento en paralelo.
Dispersin y parcialidad.

26

Para que un sistema de informacin 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 Tecnolgicos.
Nuevos requerimientos.
Globalizacin.
Aspectos Externos.
Integracin.
Al momento de construir un sistema basado en patrones arquitectnicos distribuidos
tenemos ciertas caractersticas que adquiere dicho sistema y que por ende lo hacen
distinto a otro que no est basado en este tipo de patrones. Entre dichas caractersticas
estn las siguientes:
Las estaciones satisfacen las necesidades de los usuarios.
Uso de nuevas interfaces.
Disponibilidad de elementos de Comunicacin.
Desarrollo de nuevas tcnicas.
Respuesta Rpida.
Ejecucin Concurrente de procesos.
Empleo de tcnicas de procesamiento distribuido.
Disponibilidad y Confiabilidad.
Sistema poco propenso a fallas de arquitectura o definicin.
Mayores servicios que elevan la funcionalidad.
Inclusin rpida de nuevos recursos.
Los recursos actuales no afectan.
27

Es obvio pensar que el tener sistemas distribuidos implica tanto caractersticas benficas
como contraproducentes, entre las cuales podemos citar las siguientes:
Se requiere poner ms atencin al momento del procesamiento de las
instrucciones.
La velocidad de propagacin de informacin, en ocasiones dependiendo de la
infraestructura tiende a ser lenta.
Servicios de replicacin de datos y servicios con posibilidades de fallas.
Se debe poner ms atencin a los controles de acceso y a la seguridad de las
aplicaciones, debido a que se encuentran ms propensas a posibles hackeos o
introduccin de usuarios malintencionados.
La administracin suele complicarse ms.
Los costos de construccin y mantenimiento pueden ser elevados, dependiendo
la planeacin y negociacin.
Los elementos estructurales incluyen la organizacin de un sistema como la composicin
de componentes; estructuras de control global, protocolos de comunicacin, la asignacin
de funcionalidad a los elementos de diseo, distribucin fsica, desempeo. Este es el
nivel de arquitectura de software del diseo.
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, etctera. Los
sistemas pueden tener ms de una estructura.
La arquitectura de software define componentes, agrupa informacin sobre cmo los
componentes interactan entre s lo cual revela la diferencia existente entre la arquitectura
de un sistema y su descripcin o especificacin, 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 estndares, etc.
Otros aspectos que deben ser considerados son, la naturaleza de las interacciones entre
componentes, es decir la manera en la que por definicin o implcitamente 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 eleccin es en general
independiente de la funcionalidad, pero deben ser empaquetados de formas compatibles
si se espera cooperacin entre ellos.
A la hora de comenzar con el diseo de un patrn arquitectnico, se deben considerar dos
elementos necesarios los cuales son los componentes y los conectores, estos pueden
definirse como los primeros bloques de construccin 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 acta como intermediario de la comunicacin,
coordinacin o cooperacin entre componentes.
Es importante mencionar que un patrn permite caracterizar una familia de sistemas que
estn relacionadas por compartir ciertas propiedades. Un patrn se puede considerar
como conjunto de restricciones sobre una arquitectura.
Los patrones arquitectnicos en un ambiente distribuido, permiten con facilidad estructurar
los componentes de un sistema.
Un buen diseo de un sistema de informacin distribuido basado en patrones
arquitectnicos 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 adems dichos usuarios no notan si existe un cambio en alguno de estos
servicios.
En otras palabras la transparencia, significa disear 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 diseo 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 mquina 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
fraccin 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 tambin relacionado con la confiabilidad es la tolerancia a fallas, segn la cual
las fallas se deben ocultar brindando una recuperacin transparente para el usuario,
aunque haya cierta degradacin de la performance.
El desempeo es tambin un factor fundamental a la hora del diseo de sistemas
distribuidos, esto quiere decir que cuando se ejecuta una aplicacin en un sistema
distribuido no debe parecer diferente o peor que si se ejecuta de forma aislada.
El desempeo se puede parametrizar tomando algunas mtricas como el tiempo de
respuesta, el rendimiento, cantidad consumida de la capacidad de la red, entre otras.
Para garantizar un buen desempeo a la hora de realizar peticiones entre los mdulos del
sistema, se tiene que considerar el uso de protocolos de comunicacin en los
procesadores que intervienen en la comunicacin, esto implica que se incremente el
consumo del procesador.
Por lo tanto se debe considerar la minimizacin del nmero de mensajes, lo difcil es que
la mejor forma de mejorar el desempeo es tener muchas actividades en ejecucin al
mismo tiempo, es decir, ejecucin paralela en distintos procesadores.
La escalabilidad es otro aspecto, que se debe de tratar en el diseo de sistemas
orientados a la programacin distribuida, la tendencia indica que el tamao 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 caractersticas para garantizar que un sistema distribuido cuente con
un grado alto de escalabilidad.
Ninguna mquina tiene la informacin completa acerca del estado del sistema.
Las mquinas toman decisiones solo en base a la informacin disponible de
manera local.
El fallo de una mquina no arruina el algoritmo.
No existe una hiptesis implcita de la existencia de un reloj global.
31

ArquitecturadeSoftware

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 ingeniera o de
diseo de sistemas.

Sin embargo existe una definicin 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 segn se le percibe desde el resto del sistema y las formas en que los
componentes interactan y se coordinan para alcanzar la misin del sistema. La vista
arquitectnica es una vista abstracta, aportando el ms alto nivel de comprensin y la
supresin 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 cdigo,
ocupando el lugar que en los grficos antiguos se reservaba para el diseo, esto puede
ser considerado como un enfoque demasiado amplio.

No obstante se tiene una definicin formal de Arquitectura de software la cual ofrece el
documento de IEEE Estndar 1471-2000 y dice de la siguiente manera:

La arquitectura de software es un conjunto de decisiones al momento del diseo del
software que deben ser ejecutadas correctamente porque de lo contrario podran 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 organizacin fundamental de un sistema encarnada en
sus componentes, las relaciones entre ellos y el ambiente y los principios que orientan su
diseo y evolucin.

A continuacin se muestra una figura que describe la arquitectura de un sistema de venta
de productos y se muestra la interaccin que existe entre sus diferentes componentes,
desde un punto de vista de la operacin del sistema.
32

Esta arquitectura se compone de cinco componentes los cuales son:

El usuario quien es la persona fsica que opera el sistema y que puede ser uno o
varios individuos.
La PC que cuenta con tres perifricos, los cuales son un lector de cdigo 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 tambin tiene instalado el
software cliente que se comunica con el servidor para enviar y recibir peticiones
durante la operacin, pueden existir muchas PCs con las mismas caractersticas.
El servidor, el cual tiene instalada la base de datos donde se registran todas las
operaciones realizadas por los clientes, tambin 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
transaccin 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 transaccin, 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 mltiples 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 Dinmicos.
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
configuracin, estilo, restricciones, semntica, anlisis, propiedades, racionalizaciones,
requerimientos, necesidades de los participantes, el trabajo en este modelo est
caracterizado por el desarrollo de lenguajes de descripcin arquitectnica. 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 composicin. Los modelos de Framework normalmente se
refieren a dominios o clases de problemas especficos, es decir arquitecturas de software
especficas de dominio, tales como CORBA (Figura 2).

Interfaz con el ORB
Plantilla IDL Invocacin Dinmica Adaptador del Objeto
Esqueleto Dinmico
Esqueleto IDL
Esttio
Cliente Implementacin del Objeto
Nucleo ORB

Figura 2, Arquitectura CORBA
34


Los modelos dinmicos, se concentran en la conducta de los sistemas, lo cual puede
referirse a cambios en la configuracin de los mismos, y su fin especficamente es que las
configuraciones que contenga sean parametrizables y no fijas.

En cuanto a los modelos de proceso, estos concentran su atencin en la construccin de
la arquitectura y en los pasos o procesos involucrados en esa construccin, 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 comn 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 tambin 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 expresin grfica
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
arquitectnicos.

En el campo del software, la arquitectura nos identifica los elementos ms importantes de
un sistema as como sus relaciones. Es decir nos da una visin global del sistema.

Definir una arquitectura de software es importante porque se necesita para entender el
sistema, organizar su desarrollo, plantear la reutilizacin del software y hacerlo
evolucionar.

Generalmente las metodologas de desarrollo indican principios para identificar y disear
una arquitectura, aunque la ayuda real que ofrecen es muy limitada al basarse en
principios muy genricos. La arquitectura de un sistema no precisamente responde
requisitos estructurales, sino que est relacionada con aspectos de rendimiento,
usabilidad, reutilizacin, restricciones econmicas y tecnolgicas, e incluso cuestiones
estticas.

Actualmente existen muchas metodologas de desarrollo de software, desde mtodos muy
pesados y burocrticos, mtodos ajustables al proyecto y a las condiciones de desarrollo
y mtodos ligeros que surgen como respuesta a los excesos formales de otros mtodos.

Evidentemente, partiendo de los principios de diversas metodologas es muy difcil sacar
una visin unificada sobre el diseo arquitectnico. 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 disea 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 interaccin (secuencia de acciones) tpica entre el usuario y el sistema.

Desde un punto de vista arquitectnico, no todos los casos de uso tienen la misma
importancia, destacando aquellos que nos ayudan a mitigar los riesgos ms importantes y
sobre todo aquellos que representan la funcionalidad bsica 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 bsicos. Este conjunto de especificaciones permiten
validar la arquitectura con los clientes y los desarrolladores, y asegurar que es adecuada
para implementar la funcionalidad bsica deseada.

Una visin alternativa sera 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 atencin 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 metodologa tradicional de desarrollo permite centrarse nicamente
en parte del problema, obviando cuestiones como rendimiento, seguridad, protocolos de
comunicacin, restricciones de hardware, software, y econmicas. Una metodologa
tradicional proporciona una visin 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 nmero de pginas, es til desarrollar un sistema basado en plantillas, por
la disminucin de costos de mantenimiento. Esto es algo que ningn requisito funcional
proporcionara, y que probablemente tampoco surgira de forma natural en los modelos de
diseo.

A este tipo de soluciones (patrn de diseo) se llega por la experiencia en el desarrollo de
sistemas y por el conocimiento de las tecnologas existentes en el mercado. Gracias a
esta experiencia, desde el inicio del desarrollo de una aplicacin, es posible buscar
componentes que implementen ciertas tecnologas o funcionalidades, y por lo tanto
37

integrar la bsqueda 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 metodologas que gestionen de forma directa a los aspectos arquitectnicos y
estructurales de un sistema, podrn producir no solo productos de mayor calidad, sino a
un menor costo y en menos tiempo, esto se debe a que los riesgos arquitectnicos del
proyecto son menores y estn mucho ms controlados, y que al poder integrar una visin
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 (ADLs) nos
pueden proporcionar mucha ayuda.

Los Lenguajes de descripcin arquitectnica (ADLs) se pueden definir como "La
especificacin de una serie de elementos y sus relaciones de modo que permiten describir
buenas soluciones a los diferentes problemas que aparecen en un contexto especfico"
(Clements, 1996).

Los patrones de diseo tienen como objetivo capturar buenas prcticas que nos permitan
mejorar la calidad del diseo de un sistema, determinando elementos que soporten roles
tiles en dicho contexto, encapsulando complejidad, y hacindolo ms flexible.

Por otro lado, con frecuencia se dice que la funcin 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 razn por la que los sistemas con objetivos similares
38

comparten tambin una arquitectura comn, 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 solucin a un conjunto de casos de uso, e interacciones con actores especficos.
Adems constituyen tambin un marco conceptual en el diseo de la arquitectura de los
sistemas, ya que como la funcin define a la forma, sintetizan por lo general soluciones
arquitectnicas 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
bsicos expuestos por el cliente, comprender la arquitectura del sistema a construir as
como su problemtica, 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 informacin:

Caractersticas bsicas que lo definen y diferencian.
Definicin de los actores principales que participan en dicho sistema as como sus
casos de uso bsicos, descritos evidentemente de forma genrica.
Especificacin de los principales componentes funcionales del sistema as como
las relaciones entre ellos.
Arquitectura lgica y flujos de informacin, que estructuran los diferentes
subsistemas, el intercambio de informacin entre los mismos, etc.
Arquitectura de componentes. Consiste en mapear los componentes funcionales en
la arquitectura lgica de la aplicacin.
Arquitectura fsica. Especificacin del despliegue de los componentes.

Los ADLs deben tener una visin orientada a la construccin de software y a constituirse
como elementos integrables en el proceso de desarrollo de las aplicaciones, ms adelante
en este captulo se mencionaran ms a detalle.
39

VistasArquitectnicas

Las vistas son formas que sirven para representar un aspecto parcial de una Arquitectura
de Software mostrando propiedades especficas de un sistema. Se les puede considerar
como parte de los bloques de un sistema.

Existen gran nmero 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 arquitectnicas relevantes.

Las Vistas pueden ser descritas grficamente como una cantidad de componentes y
conexiones, pero la semntica de estos artefactos difiere entre Vistas. De igual manera,
diferentes Vistas pueden ser utilizadas para diferentes anlisis.

As tambin al tener un enfoque arquitectnico, tenemos que la arquitectura de un sistema
consta de mltiples 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 Lgica.
Vista de Proceso.
Vista de Desarrollo.
Vista Fsica.

En cada una de las vistas es notable ciertas caractersticas, como el aspecto del sistema,
a quien va dirigida particularmente cada vista, as tambin su notacin, 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, etctera.
Abundando acerca del modelo de vistas propuesto por Philippe Kruchten, tenemos que se
basa mucho en la abstraccin.

Por su parte la Vista Lgica, se refiere a la abstraccin de las funciones del sistema y sus
relaciones, la Vista Lgica 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 abstraccin, encapsulamiento y herencia.

Philippe Kruchten, considera la notacin Rational/Booch, para representar la vista lgica,
mediante diagramas de clases y plantillas de clases, los diagramas de clases muestran un
conjunto de clases as como sus relaciones lgicas, asociaciones, uso, composicin,
herencia y ms elementos de la Programacin 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 caractersticas 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
distribucin, integridad del sistema y tolerancia a fallas.

En la Vista de Procesos se describe en varios niveles de abstraccin donde cada nivel
est enfocado a distintos intereses, se tiene que un proceso es una agrupacin de tareas
que forman una unidad ejecutable. Los procesos representan el nivel al que la
arquitectura de procesos puede ser controlada tcticamente. Adems, los procesos
pueden replicarse para aumentar la distribucin de la carga de procesamiento, o para
mejorar la disponibilidad.

La Vista de Desarrollo, se centra en la organizacin de los mdulos generados en
ambiente de desarrollo, el software es empaquetado en pequeas partes llamados
subsistemas o bibliotecas de programas que pueden ser desarrollados por uno o ms
desarrolladores. Dichos subsistemas se organizan jerrquicamente 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 jerarqua.

Esta Vista, toma en cuenta aspectos como la facilidad de desarrollo, administracin del
software, reutilizacin y restricciones impuestas por el lenguaje de programacin.

La Vista de Desarrollo de un sistema se debe representar en diagramas de mdulos 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 Fsica, 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 mnimo impacto sobre el cdigo fuente, es decir, sin
tener que recompilar los mdulos.
42

Patrones

Existen muchas definiciones alrededor del tema de los patrones as tambin 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 mecnica, etctera. En su
forma ms genrica un patrn en si es un modelo a seguir que puede ser tomado en
cuenta al momento de realizar algo.

Siendo exigentes con la anterior definicin tenemos que en lugar de decir que el patrn se
puede tomar en cuenta para hacer algo deberamos decir que el patrn se debe tomar en
cuenta el momento de hacer algo, con el fin de llevar un cierto orden y llegar a la
construccin 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 solucin en
experiencia probada y en buenas prcticas. Dicho lo anterior los patrones capturan la
experiencia existente y probada para promover buenas prcticas. 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 solucin a problemas
comunes a muchos proyectos de arquitectura.

Vista la eficacia de los patrones en el campo de la arquitectura, otras disciplinas los
aadieron a su repertorio de herramientas. La informtica no ha sido una excepcin y la
adaptacin de este concepto a la ingeniera del software fue con la aportacin de Ward
Cummingham y Kent Beck (Kent Beck, 1987) quienes adaptaron ideas de Christopher
Alexander a la Ingeniera de Software y crearon cinco patrones para el diseo de las
interfaces y en el ao de 1995 Gamma, Helm, J ohnson, Vlissides ms conocidos como la
pandilla de los cuatro Gang of Four, publican su libro Desing Patterns (Gamma, 1995),
en donde hacen una recopilacin de 23 patrones comunes en el diseo de software
orientado a objetos. Tenemos que los patrones son una gua para la correcta arquitectura,
diseo y desarrollo del software.

43

En si la generacin de patrones de software se basa en capturar la experiencia de la
solucin a problemas que surgen en un contexto y la documentacin de dicha
experiencia, con el fin de que al momento de presentarse de nuevo un problema de esa
ndole se pueda recurrir al patrn que ayuda a la solucin del problema.

Dicho de otra manera un patrn intenta capturar la experiencia, de modo que la forma
correcta de resolver un problema dado pudiera ser transmitida a otras personas que an
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
patrn no es ms que la descripcin detallada de una solucin adecuada a un problema
concreto.

El objetivo bsico que se persigue con la idea de patrn es no tener que rehacer las cosas
cada vez que se presente una cierta situacin. Los patrones capturan soluciones a
situaciones de especial inters, ya sea por ser muy comunes o por ser especialmente
complejas. Normalmente, un patrn est compuesto por el enunciado del problema y una
o varias propuestas de solucin.

Para formalizar estas soluciones, se necesita una notacin expresiva y rica en semntica
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 ms a detalle.

Para que una solucin sea considerada un patrn debe poseer ciertas caractersticas, 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 diseo en distintas circunstancias.

44

TiposdePatrones

No existe una sola clasificacin como tal, pueden ser de varios enfoques tales como:
Patrones de Procesos (Organizacin, Administracin, Anlisis Diseo y Pruebas).
Patrones de producto de Software (Anlisis, Arquitectura, Diseo y Lenguaje de
programacin).
Conjuntos de Patrones (Lenguaje de Patrones, Catalogo de Patrones, Sistema de
Patrones).
Patrones Arquitectnicos (Patrones aplicables a sistemas distribuidos).
Patrones de diseo.
Patronesdediseo

Cuando nos referimos a patrones de diseo tenemos que son maneras de solucionar
muchos problemas parecidos de una misma manera, de hecho se centran en la parte
usual del componente a disear, y de esa forma son muy especficos.

Tenemos que son descripciones de clases cuyas instancias se relacionan y colaboran
entre s. Cada patrn 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 ms pequeas, ms simples y ms comprensibles, para describir un patrn
debemos especificar, los siguientes elementos:

Nombre.
Propsito o finalidad.
Sinnimos (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).
Implementacin (consejos, notas y ejemplos).
Otros patrones con los que est relacionado.

Aunque esta es una forma para describir el propsito, nombre y dems 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 reutilizacin es necesario anticiparse a los
nuevos requisitos y cambios, de modo que los sistemas evolucionen de forma adecuada.
Cada patrn 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 patrn es un esquema que supone una solucin a problemas
semejantes o concurrentes.

Tambin es conveniente distinguir entre un patrn y la arquitectura del sistema como tal,
por as decirlo es la misma diferencia entre el diseo de un componente y el anlisis del
sistema.

En general un patrn de diseo es una solucin estndar para un problema comn de
programacin, una tcnica para hacer flexibilizar el cdigo y satisfacer ciertos criterios.

Los patrones de diseo permiten a un proyecto lograr una finalidad determinada, son
vistos como una manera ms prctica de describir ciertos aspectos de la organizacin de
un programa y conexiones entre componentes de programas.

Es evidente que a lo largo de multitud de diseos de aplicaciones hay problemas que se
repiten y que responden a un cierto patrn. Sera deseable tener una coleccin de dichos
patrones con las soluciones ms ptimas para cada caso.

46

Los patrones de diseo permiten que los diseos sean mucho ms flexibles, modulares y
reutilizables, en el libro Design Patterns (Gamma, 1995) se dice que han revolucionado el
diseo orientado a objetos y todo buen arquitecto de software debera conocerlos. A
continuacin se enlistan y describen de forma breve los patrones de diseo a objetos ms
habituales publicados en el libro antes mencionado.
Patronesdecreacin

Abstract Factory. Proporciona una interfaz para crear familias de objetos o que
dependen entre s, sin especificar sus clases concretas.
Builder. Separa la construccin de un objeto complejo de su representacin, de
forma que el mismo proceso de construccin 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 creacin de objetos.
Prototype. Especifica los tipos de objetos a crear por medio de una instancia
prototpica, y crear nuevos objetos copiando este prototipo.
Singleton. Garantiza que una clase slo tenga una instancia, y proporciona un
punto de acceso global a ella.

Patronesestructurales

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
podran por tener interfaces incompatibles.
Bridge. Desvincula una abstraccin de su implementacin, de manera que
ambas puedan variar de forma independiente.
47

Composite. Combina objetos en estructuras de rbol para representar
jerarquas de parte-todo. Permite que los clientes traten de manera uniforme a
los objetos individuales y a los compuestos.
Decorator. Aade dinmicamente 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
ms fcil de usar.
Flyweight. Usa el compartimiento para permitir un gran nmero de objetos de
grano fino de forma eficiente.
Proxy. Proporciona un sustituto o representante de otro objeto para controlar el
acceso a ste.

Patronesdecomportamiento

Chain of Responsibility. Evita acoplar el emisor de una peticin a su receptor, al
dar a ms de un objeto la posibilidad de responder a la peticin. Crea una
cadena con los objetos receptores y pasa la peticin a travs de la cadena
hasta que esta sea tratada por algn objeto.
Command. Encapsula una peticin 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 representacin de su gramtica junto
con un intrprete que usa dicha representacin para interpretar las sentencias
del lenguaje.
Iterator. Proporciona un modo de acceder secuencialmente a los elementos de
un objeto agregado sin exponer su representacin interna.
48

Mediator. Define un objeto que encapsula cmo interactan un conjunto de
objetos. Promueve un bajo acoplamiento al evitar que los objetos se refieran
unos a otros explcitamente, y permite variar la interaccin entre ellos de forma
independiente.
Memento. Representa y externaliza el estado interno de un objeto sin violar la
encapsulacin, de forma que ste puede volver a dicho estado ms tarde.
Observer. Define una dependencia de uno-a-muchos entre objetos, de forma
que cuando un objeto cambia de estado se notifica y actualizan
automticamente 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 vare independientemente de los
clientes que lo usan.
Template Method. Define en una operacin 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 operacin sobre los elementos de una estructura de
objetos. Permite definir una nueva operacin sin cambiar las clases de los
elementos sobre los que opera.

49

Patronesarquitectnicos
En un panorama muy genrico y orientado a la arquitectura de software tenemos que los
patrones arquitectnicos son aquellos que definen la estructura de un sistema software,
los cuales a su vez se componen de subsistemas con sus responsabilidades, tambin
tienen una serie de directivas para organizar los componentes del mismo sistema, con el
objetivo de facilitar la tarea del diseo de tal sistema.
Un patrn de arquitectura de software describe un problema particular y recurrente que
surge en un contexto especfico, y presenta un esquema genrico y probado de su
solucin.
En la actualidad existe una gran diversidad de arquitecturas que implementan patrones y
que se vuelven de uso comn.
Los patrones arquitectnicos expresan un esquema estructural de la organizacin 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 diseo con los de arquitectura tenemos que los
arquitectnicos son ms grandes en escala y alcance.
Aun cuando un patrn arquitectnico contiene la forma o imagen de un sistema, no es una
arquitectura como tal, un patrn arquitectnico es un concepto que captura elementos
esenciales de una arquitectura.
Por consecuencia al no ser una arquitectura como tal, un patrn al ser implementado
permite que varias arquitecturas lo contengan y compartan caractersticas comunes.
Uno de los aspectos ms importantes de patrones arquitectnicos 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 automticos.
Un sistema de patrones brinda un conjunto de soluciones probadas y depuradas a
muchos problemas recurrentes de diseo de diversos niveles de abstraccin, desde los
patrones arquitectnicos 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 arquitectnicos representan el nivel ms alto en un sistema de patrones,
permiten especificar la estructura fundamental de una aplicacin, todas las actividades del
desarrollo estn bajo esta estructura, por ejemplo el diseo a travs de subsistemas, la
comunicacin y colaboracin entre diferentes partes del sistema.
As tambin es considerable comentar que los patrones que dan soporte a propiedades
similares pueden ser agrupados en categoras. Segn Buschmann en su libro Pattern-
Oriented Software Architecture, A System of Patterns (Buschmann, 1996), comenta las
siguientes categoras para los patrones arquitectnicos.
Sistemas Distribuidos.
Sistemas Interactivos.
Sistemas Adaptables.
51

ElFuturodelosPatrones

En el futuro esperamos que el inters en los patrones crezca sustancialmente, ya que los
investigadores y los principales proyectos de software se encuentran orientados a
continuar adoptando paradigmas de patrones, mtodos y procesos (Schmidt, 2007).

La literatura de los patrones en los ltimos aos 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 ample sobre esta tradicin. Por ejemplo, la prxima generacin de
aplicaciones orientadas a objetos en sus frameworks incorporan a los patrones de forma
explcita.

Objetos distribuidos. Muchos patrones asociados con el middleware y las
aplicaciones para objetos concurrentes y en red se han documentado durante los
ltimos diez aos. 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
distribucin de objetos, tales como localizacin de servicios remotos y particin,
nombres y directorios de servicios, balanceo de carga, confiabilidad y seguridad.

Sistemas embebidos. Un nmero cada vez mayor de sistemas de computacin
estn incorporados, incluidos los sistemas de control del automvil y aplicaciones
basados en el coche, software de control para equipos de automatizacin,
informtica avinica de misin, y dispositivos informticos porttiles. Muchos de
estos sistemas estn sujetos a estrictas limitaciones de recursos de computacin,
en particular huella de la memoria y time constraints.

Sistemas mviles. Las redes inalmbricas se estn convirtiendo en dispositivos de
computacin ubicua e integrados se vuelven ms pequeos, ms ligeros, y ms
capaz. Por lo tanto, los sistemas mviles pronto apoyo a la comunicacin de los
consumidores y muchas necesidades informticas. Las reas de aplicacin para
los sistemas mviles incluyen computacin ubicua, los agentes mviles, asistentes
personales, suministro de informacin dependientes de la posicin, distancia de
diagnstico mdico y tele-radiologa, y en el hogar y automatizacin de oficinas.
52

Adems, los servicios de Internet, que van desde la navegacin por la web de
banca on-line, se puede acceder desde sistemas mviles. Los sistemas mviles
pueden enfrentarse a muchos desafos, como la gestin de ancho de banda,
adaptndose 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 travs de nodos de red. Esperamos que los desarrolladores con
experiencia en sistemas mviles determinen documentar su experiencia en forma
de un patrn para ayudar a satisfacer la creciente demanda de las mejores
prcticas en el desarrollo de software en este mbito.

Transacciones comerciales y sistemas de comercio electrnico. Muchos sistemas
de informacin empresarial, tales como contabilidad, nmina, inventarios y
sistemas de facturacin, se basan en transacciones. Las reglas de procesamiento
de las transacciones son complejas y deben ser flexibles para reflejar las nuevas
prcticas de negocios y fusiones. los sistemas de negocios tambin deben manejar
volmenes cada vez mayor de transacciones en lnea. El advenimiento del
comercio electrnico en la Web es la exposicin 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 anlisis, arquitectura o
patrones de diseo. Esperamos que el diseo y desarrollo de patrones en las
transacciones y el comercio electrnico crezca en los prximos aos.

Calidad de servicio para commercial-off-the-shelf (COTS) basado en sistemas
distribuidos. Los sistemas distribuidos, tales como streaming de vdeo, telefona por
Internet, y en gran escala de sistemas de simulacin interactiva, tienen una calidad
cada vez ms 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 ms desarrollados
utilizando mltiples capas de hardware COTS, sistemas operativos, middleware y
componentes. Histricamente, sin embargo, ha sido difcil de configurar los
sistemas basados en COTS y al mismo tiempo poder satisfacer las propiedades de
calidad de servicio mltiples, tales como seguridad, puntualidad, y tolerancia a
fallos.
53


Reflective middleware. Este trmino describe un conjunto de tecnologas diseadas
para gestionar y controlar los recursos del sistema en aplicaciones distribuidas
autnomas o semiautnomas. Las tcnicas reflexivas middleware permiten
cambios dinmicos en el comportamiento de las aplicaciones de software de base
y la adaptacin de los protocolos de hardware, polticas 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 jugarn un papel clave en
documentar las mejores prcticas que puedan ayudar a garantizar la aplicacin
efectiva del Reflective middleware.

Optimizacin 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 ampliacin, 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

LenguajesdeDescripcinArquitectnica(ADLs)
Los lenguajes de descripcin arquitectnica (ADLs), son lenguajes para el modelado, la
descripcin y prueba arquitectnica, permiten la representacin de componentes,
conectores, configuraciones y restricciones de la arquitectura, as tambin estn
pensados para permitir la evolucin de la arquitectura, es decir son flexibles al cambio.
Un ADL es un enfoque lingstico a la representacin formal de una arquitectura
(Clements, 1998). Una arquitectura software incluye la descripcin de elementos que
constituyen a los sistemas, las interacciones entre tales elementos, los patrones que
guan su composicin y las restricciones sobre estos patrones (Mary Shaw, 1996).

Un ADL se centra en la estructura de alto nivel de la aplicacin en su conjunto y no en los
detalles de implementacin de cualquiera de sus mdulos fuentes especficos (Vestal,
1993). Un ADL debe modelar explcitamente los componentes, los conectores y las
diversas configuraciones; ms an, para que sea realmente utilizable y til debe facilitar
un soporte de herramienta para el desarrollo arquitectnico (Medvidovic, 1996). Por tanto,
un ADL es un lenguaje que proporciona caractersticas para modelar la arquitectura
conceptual de un sistema software, distintiva de la implementacin del sistema: los ADLs
proporcionan tanto una sintaxis concreta como un marco conceptual para la
caracterizacin de arquitecturas donde este refleja las caractersticas del dominio para los
que el ADL est enfocado y/o el estilo arquitectnico. El marco subsume la teora
semntica subyacente del ADL (Garlan, 1997).

Los ADLs se remontan a los lenguajes de interconexin de mdulos (MIL), pero se han
comenzado a desarrollar con su denominacin actual a partir de 1992 o 1993, poco
despus del impacto de la arquitectura de software como especialidad profesional. La
definicin ms 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.
Composicin jerrquica, en la que un componente puede contener una sub-
arquitectura completa.
Paradigmas de computacin, es decir, semnticas, restricciones y propiedades no
funcionales.
Paradigmas de comunicacin.
Modelos formales subyacentes.
Soporte de herramientas para modelado, anlisis, evaluacin y verificacin.
Composicin automtica de cdigo aplicativo.

Por otra parte Shaw y Garlan (Shaw, 1994) comentan que en los ADLs los conectores
sean tratados explcitamente como entidades de primera clase y han afirmado que un
ADL tiene que proporcionar propiedades de composicin, abstraccin, reusabilidad,
configuracin, heterogeneidad y anlisis, lo que excluira a todos los lenguajes
convencionales de programacin y a los MIL.

Una de las especificaciones ms claras y concisas es la de Medvidovic (Medvidovic,
1996), la cual seala que los ADLs deben contener los siguientes elementos para ser un
lenguaje completo:

Componentes
Conectores
Configuraciones arquitectnicas
Soporte de herramientas

Un ADL con todas sus caractersticas forma parte de un entorno de desarrollo integrado
que, adems, soporte la agregacin de informacin, para que sea optimo la utilizacin de
un ADL durante la construccin de un sistema se deben presentar situaciones tales como.

Sistema inicialmente descrito, basado en estilos arquitectnicos.
Descripcin de alto nivel del sistema, sea mediante casos de uso, escenarios u otra
alternativa ms formal.

56

Realizacin de diversos tipos de anlisis o simulaciones del modelo arquitectnico
que permitan estimar los recursos necesarios y obtener el grado de satisfaccin de
propiedades de calidad como el rendimiento, la disponibilidad o la seguridad.
Refinamiento de componentes para cada tipo de anlisis.
Visualizacin de informacin de cada componente y de los resultados del anlisis
sobre ellos.
Codificacin o generacin de plantillas a partir de las descripciones de los
componentes.

Por otra parte con base a las propuestas de los autores antes sealados podemos
comentar que existen elementos comunes que los ADLs deben contener, los cuales son
los siguientes:

Componentes: Representan los elementos primarios de un sistema. Ejemplos
tpicos seran clientes, servidores, filtros, objetos, pizarras y bases de datos.
Conectores: Representan interacciones entre componentes. Ejemplos tpicos
podran ser tuberas (pipes), llamadas a procedimientos, protocolos cliente-
servidor, o conexiones entre una aplicacin y un servidor de base de datos.
Configuraciones o sistemas: Se constituyen como grafos de componentes y
conectores. Los sistemas tambin pueden ser jerrquicos, componentes y
conectores pueden subsumir la representacin de lo que en realidad son complejos
subsistemas.
Propiedades: Representan informacin semntica sobre un sistema ms all de su
estructura. Por ejemplo, cuestiones de seguridad, escalabilidad, dependencia de
bibliotecas o servicios especficos, configuraciones mnimas de hardware y
tolerancia a fallas.
Restricciones: Representan condiciones de diseo que deben acatarse incluso en
el caso que el sistema evolucione en el tiempo. Por ejemplo, el nmero de clientes
que se puede conectar simultneamente a un servicio.
Estilos: Representan familias de sistemas, un vocabulario de tipos de elementos de
diseo y de reglas para componerlos. Ejemplos seran las arquitecturas de flujo de
datos basados en grafos de tuberas (pipes) y filtros, las arquitecturas de pizarras
basadas en un espacio de datos compartido, o los sistemas en capas.
57

Evolucin: Es el soporte de procesos de evolucin permitiendo derivar subtipos a
partir de los componentes e implementando refinamiento de sus rasgos.
Propiedades no funcionales: La especificacin de estas propiedades es necesaria
para analizar la conducta de los componentes, imponer restricciones, mapear
implementaciones sobre procesadores determinados, etctera.
Es destacable mencionar que los ADLs deben contener un conjunto mnimo de requisitos,
para poder ser lo ms ptimo posible al momento de su utilizacin independientemente
del tipo y la arquitectura que se desea modelar:
Comunicacin: 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 estticas como las que son dinmicas. Los diversos tipos de componentes y
conectores deben estar identificados en cada una de las estructuras.
Anlisis y Validacin: Un ADL debe dar soporte a las tareas de creacin de la
arquitectura, refinamiento y validacin
Propsito General: Un ADL debe proporcionar la capacidad para representar la
mayora de los estilos arquitectnicos habituales.
Abstraccin: Un ADL debe tener la capacidad de proporcionar estructuras del
sistema que expresen informacin arquitectnica y que, al mismo tiempo, omitan
toda aquella informacin sobre la implementacin que no sea arquitectnica.
Derivacin: El ADL debe proporcionar una base para fomentar la implementacin.
Sobre todo, debe posibilitar la agregacin de informacin extra a la especificacin
ADL de manera que permita que una especificacin final del sistema sea derivada
del ADL.
Alternativas de Implementacin: Si el ADL puede expresar informacin de nivel de
implementacin, debe tener posibilidades para optar a ms de una implementacin
de las estructuras de nivel arquitectnico 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 ADLs especficos para diversos tipos de enfoques y
otros ms genricos, es por eso que basado en caractersticas y en consejos acerca de
utilizar software libre se ha optado por utilizar ACME ARMI para describir el caso de
estudio en este trabajo.

LenguajeAcmeArmi

Acme se define como una herramienta capaz de soportar el mapeo de especificaciones
arquitectnicas 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
Computacin 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 artculo An architectural
interchange language de Garlan, Monroe y Wile (Garlan, 1997).
La motivacin fundamental de Acme es el intercambio entre arquitecturas e integracin de
ADLs.

Acme soporta la definicin de cuatro tipos de arquitectura: la estructura, las propiedades
de inters, las restricciones, los tipos y estilos.
Acme-Armani se constituy en un lenguaje de tipo ADL, especializado en la descripcin
de la estructura de un sistema y su evolucin 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 tambin la experiencia de los
arquitectos, sealando su vinculacin con la prctica de los patrones arquitectnicos, en
este caso patrones de diseo.

59

Armani se basa en siete entidades para describir las instancias del diseo: componentes,
conectores, puertos, roles, sistemas, representaciones y propiedades. Para capturar las
experiencias y mejores prcticas, Acme-Armani implementa adems otras seis entidades
que son, tipos de elementos de diseo, tipos de propiedades, invariantes de diseo,
heursticas, anlisis y estilos arquitectnicos.


Figura 4, Pantalla de AcmeStudio.
60

CAPITULO2,PatronesArquitectnicosdesdeperspectivasactuales





En este captulo se busca hacer una recopilacin que a su vez sirva como referencia de
los patrones arquitectnicos que existen en la actualidad y son aplicados por muchos
sistemas robustos o son foco de atencin de empresas de creacin de software y
lenguajes de programacin como Sun Microsystems y Microsoft.
Patrones Arquitectnicos como el patrn MVC (Modelo Vista Controlador), son tema de
este captulo.
61

PatrnArquitectnicoModeloVistaControlador(MVC)

El patrn MVC es un patrn arquitectnico de tres capas conceptuales, fue definido en un
principio para sistemas usuario-mquina y en la actualidad es aplicado a los Sistemas de
Informacin Distribuidos.
El patrn MVC no solo define tres capas de una arquitectura 3-tier (Presentacin, Lgica
de negocios y datos), ms 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 representacin de salida y/o
comportamiento de entrada.
o Representa toda la informacin con la que opera la aplicacin.
o Gestiona el comportamiento y los datos del dominio.
o Responde a peticiones de informacin que vienen de la vista.
o Responde a instrucciones de cambio de estado, provenientes del
controlador.

Vista(View):
o Muestra la informacin al usuario.
o Pueden existir mltiples vistas del modelo.
o Cada vista tiene asociado un componente controlador.
o Gestiona la representacin de la informacin de la aplicacin.

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 lgica 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 patrn MVC grficamente 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 grficamente el patrn MVC.

El diagrama de la figura 5, explica el patrn 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 peticin al Modelo.
3. El modelo (si es necesario) llama a la vista para su actualizacin.
4. Para cumplir con la actualizacin la Vista puede solicitar datos al Modelo.
5. El Controlador recibe el control.
63

PatrnArquitectnicoBroker


Es un patrn arquitectnico aplicado en la estructuracin de sistemas distribuidos en los
cuales es necesaria la interaccin remota de componentes altamente desacoplados, lo
anterior se logra al introducir un componente Broker cuya funcin principal es lograr el
desacoplamiento de los clientes y de los servidores, tambin registra a los servidores,
logrando de esta forma que los servicios que estos ofrecen estn disponibles a los
posibles clientes.

Adems de los componentes Broker, servidores y clientes, este patrn est tambin
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 anlogos 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, adems se encargan de recibir resultados y excepciones del servidor,
empaquetarlos y enviarlos al Broker.

Por otra parte, los componentes Bridges tienen como principal funcin ocultar los detalles
de implementacin 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 caractersticas de calidad ms importantes que se
ponen en evidencia para el patrn Broker son: la interoperabilidad, la transparencia de
ubicacin, la capacidad de manejar los cambios con eficiencia (flexibilidad) y la
adaptabilidad (portabilidad).


64

Patrn Componentes Comportamiento Caractersticas de
calidad
Broker Broker, proxies,
servidores, clientes,
bridges
dinmico Cambios a nivel
dinmico,
extensibilidad,
reutilizacin,
portabilidad
(adaptabilidad),
transparencia
respecto
Tabla 1, Caractersticas del patrn arquitectnico Broker

El patrn arquitectnico de broker introduce una capa de servicios de software que realiza
las operaciones de conversin y acoplamiento necesarias para simplificar el intercambio
de informacin entre los sistemas.

Gracias a las facilidades que brinda por este patrn 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.

ObjetivodelpatrnBroker

El patrn Broker arquitectnico puede ser usado para estructurar sistemas de software
distribuidos con componentes que interacten de forma disociada por las llamadas de un
servicio remoto. Un componente Broker es responsable de coordinar las cuestiones de
comunicacin, tales como solicitudes de reenvo, as como para la transmisin de
resultados y excepciones.

Motivacin

La principal motivacin que tuvo el autor para desarrollar este patrn es el poder introducir
un componente intermediario para lograr un mejor desacoplamiento de los clientes y
servidores.
65

Lo ideal para los Servidores sera poderse registrar en un Broker y poner sus
servicios a disposicin de los clientes a travs de interfaces de mtodo.
Para los clientes tener acceso a la funcionalidad de los servidores mediante el
envo de peticiones a travs del Broker.

A las tareas incluyen la localizacin de los Brokers en el servidor apropiado, la solicitud de
reenvo en el servidor y la transmisin los resultados y excepciones al cliente.
Al usar el patrn Broker, una aplicacin debe poder tener acceso a servicios distribuidos,
simplemente mediante el envo de mensaje al objeto apropiado, en lugar de centrarse en
cosas de bajo nivel de comunicacin entre procesos.

Adems, la arquitectura Broker es flexible, ya que permite un cambio dinmico, adicin,
supresin y traslado de objetos.

El patrn Broker reduce la complejidad que implica en el desarrollo de aplicaciones
distribuidas, ya que hace que la distribucin transparente para el desarrollador,
logra este objetivo mediante la introduccin 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 integracin de dos
tecnologas fundamentales: la distribucin y la tecnologa de objetos.

UsosConocidosdelpatrnarquitectnicoBroker

Este patrn se ha utilizado en los siguientes sistemas:

CORBA. Common Object Request Broker Architecture, es una tecnologa orientada
a objetos para la distribucin de objetos en sistemas heterogneos. CORBA fue
definido por el Object Management Group y utiliza el patrn arquitectnico Broker.
Se fundamentan en dar uso a este patrn para mejorar el apoyo de la
interoperabilidad de los clientes y los objetos servidor buscando disponibilidad a
travs de un lenguaje de definicin.

66

IBM SOM / DSOM. Se trata de un sistema CORBA Broker compatible que combina
la definicin de la interfaz CORBA y un idioma con un protocolo binario.

Microsoft OLE 2.x utiliza el patrn Broker y define un estndar binario para la
exposicin y el acceso a interfaces de servidor.

World Wide Web utiliza el patrn brker para que los navegadores acten 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 conmutacin de telecomunicaciones basada en la aplicacin de ATM
Message Broker como una variante del sistema.

CaractersticasBenficasdelPatrnArquitectnicoBroker

Variabilidad
Extensibilidad de componentes
Interoperabilidad entre
Transparencia
Portabilidad


67

PatrnArquitectnicoPipesandFilters

Contexto

El patrn arquitectnico 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 travs de tubos entre filtros adyacentes. Re
combinar filtros permite construir familias de sistemas relacionados.

Motivacin

El patrn arquitectnico Pipes and Filters divide la tarea de un sistema en varios pasos de
procesamiento secuencial. Estas medidas estn conectadas por el flujo de datos a travs
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 tuberas.
Cada tubo implementa el flujo de datos entre los pasos de procesamiento adyacentes. La
secuencia de filtros combinados por tuberas se denomina lnea de proceso.

La aplicacin de este patrn ofrece que se puedan combinar y reutilizar en diferentes
aplicaciones:

Muchas aplicaciones puedan procesar grandes volmenes de elementos de datos
similares. Por ejemplo, los sistemas comerciales puedan manejar cotizaciones de
bolsa, los sistemas de facturacin de telecomunicaciones puedan manejar los
68

registros de llamadas de datos, sistemas de informacin y gestin 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.

UsosConocidos

Este patrn se ha utilizado en los siguientes sistemas:

UNIX hizo popular al patrn 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
tuberas de UNIX.

Caractersticas Benficas

Eficiencia
Procesamiento
Flexibilidad
69

CAPITULO 3. Propuesta de solucin usando el Patrn
ArquitectnicoPiramidalylaArquitecturaPiramidaldeSistemas
Distribuidos


En este captulo se explicar a detalle el funcionamiento, estructura, caractersticas, flujo
de trabajo y ventajas que tiene la propuesta de los patrones piramidales.
Tambin 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 solucin de pagos en la que se tiene un sistema de Terminal Punto de
Venta que trabaja sobre terminales mviles de forma convencional, con una Arquitectura
cliente servidor, entre las terminales y el autorizador de transacciones.
Se harn pruebas y se especificarn los detalles de la propuesta con el fin de llegar a un
ambiente productivo exitosamente.



70

ElPatrnPiramidal

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 excepcin.

El patrn piramidal pretende ser un modelo a soluciones basadas en elementos que se
comunican entre s, con la caracterstica de que la comunicacin sea jerrquica. Es decir
que exista un orden entre elementos y que cada elemento se comunique solo con un
elemento del siguiente nivel segn el orden en el que se encuentren.

El patrn piramidal se orienta a sistemas distribuidos que como se mencion requieren de
una comunicacin jerrquica, ya sea por diseo o por seguridad o para evitar
inconsistencia de datos.

Por mucho tiempo la forma piramidal se ha utilizado para denotar jerarqua entre los
niveles que la conforman. El patrn piramidal denota tres niveles en su estructura, el nivel
base, el nivel de interpretacin y el nivel fuente:


Figura 6. Niveles del Patrn Piramidal
71

El nivel base es el primer nivel de la pirmide y del cual se generan las peticiones o
solicitudes de procesamiento de datos. El nivel base contiene todos los componentes que
interactan directamente con el usuario final.

Por otra parte el nivel de interpretacin, 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 pirmide y contiene el procesamiento final de la peticin,
este nivel contiene componentes que proveen diversos servicios de terceros y por
consecuencia la arquitectura de este nivel se considera como una caja negra.

CaractersticasdeNiveles

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 interpretacin a travs de un lenguaje o
protocolo de comunicacin estndar, como XML, por HTTP POST, GET o
SOAP.
o Por el tipo de comunicacin con el nivel de interpretacin los componentes
del nivel base deben tener salida a internet o intranet.

Nivel de Interpretacin
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 travs del mismo protocolo o lenguaje de comunicacin.
72

o Este nivel decide si la peticin que se hace en el nivel base puede ser
enviada al nivel fuente o no. Si la peticin no puede ser procesada se
genera el mensaje correspondiente y se enva de regreso la peticin al nivel
base, de lo contrario si la peticin si puede ser procesada se genera un
mensaje entendible para el nivel fuente y se enva.
o Los componentes de este nivel se comunican con los componentes del nivel
fuente a travs 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 pirmide y es donde se procesa la
respuesta final de la peticin que se genera en el nivel fuente y que el nivel
de interpretacin considera correcto.
o La arquitectura de los componentes o la operacin de estos se considera
como una caja negra ya que provienen de servicios de terceros.

FlujodeOperacindelPatrnPiramidal

1. Un usuario a travs de un componente del nivel base genera una peticin.

2. El componente del nivel base genera un mensaje que cumple con caractersticas
comunes entendibles para algn componente del nivel de interpretacin, se
empaqueta el mensaje y se enva a travs de un protocolo de comunicacin.

3. El componente del nivel de interpretacin que fue invocado por el componente del
nivel base, recibe el mensaje y lo interpreta.

4. El componente del nivel de interpretacin valida el mensaje y decide si puede ser
procesado y enviado a algn componente del nivel fuente o si debe ser retornado
al nivel base.

73

5. Una vez que el mensaje que enva el componente del nivel base es correcto el
componente del nivel de interpretacin, 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 interpretacin.

6. El componente o servicio del nivel fuente recibe la peticin del nivel de
interpretacin, la procesa y genera un nuevo mensaje con la respuesta para
enviarlo al componente del nivel de interpretacin.

7. El componente del nivel de interpretacin 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 patrn piramidal toma como el nivel ms alto de la pirmide el o los
componentes que provean la informacin final de una peticin, es por esto que se les
llama componentes fuente.

Por otra parte, el componente en el nivel ms bajo de la pirmide (nivel base), hace una
peticin o una solicitud de informacin la cual la debe recibir el siguiente nivel de la
pirmide (nivel de interpretacin) 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 informacin y lo devuelve de la misma manera pero ahora
descendentemente hasta llegar al componente base que dio origen a la solicitud.

Si descomponemos al patrn piramidal en capas cada nivel debera representar una de
las siguientes capas:

Lgica de Presentacin. (Nivel Base)
Lgica de Dominio. (Nivel de Interpretacin)
Lgica de Fuente de datos.
74


Es importante sealar que el patrn piramidal es la primicia para generar una arquitectura
piramidal de sistemas distribuidos.
CaractersticasGenerales

Deben existir forzosamente tres niveles que son la base, interpretacin y la fuente.

Cada nivel puede tener mltiples componentes que tengan la misma jerarqua de
procesamiento de la informacin.

Los componentes que se encuentran en cada nivel son independientes no es
necesario que exista comunicacin entre ellos.

La comunicacin entre niveles debe ser jerrquica y puede ser ascendente y
descendente.

Pueden existir peticiones simultneas, pero cada una debe cumplir un ciclo
jerrquico en la pirmide.

Dentro del nivel de interpretacin pueden existir validaciones de asignacin para
emitir la peticin a uno o a otro componente del mismo nivel.

El patrn piramidal puede ser considerado genrico por su estructura y modo de
procesamiento, ms adelante se comentar el por qu se le puede considerar
genrico.

75

VentajasdelPatrnPiramidal

Facilita la colocacin de la solucin sobre cualquier plataforma, sin importar el
lenguaje de programacin, es debido a que todos los niveles se comunican a
travs de protocolos estndar de comunicacin.

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 interpretacin.

No tiene restricciones sobre el modo en el que se comuniquen los niveles de la
pirmide, puede ser cualquier protocolo de comunicacin estndar.

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 interpretacin, se tiene mayor
control de las peticiones que se hacen a los servicios de terceros y as tambin se
tiene control de las respuestas que ofrecen dichos servicios, En este nivel se debe
llevar el registro y administracin 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 aplicacin para celular, el usuario podra acceder a un servicio
desde su dispositivo.

Por la estructura de niveles cualquier operacin realizada en el nivel base, se
registra en el nivel de interpretacin y posteriormente se puede acceder al registro
de dichas operaciones a travs de un componente base que haga una peticin de
consulta al nivel de interpretacin.

76

Los componentes del nivel base solo se preocupan por establecer una sola forma
de comunicacin, es decir la que establezcan con el nivel de interpretacin, por
definicin 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
comunicacin.

Al estar centralizado el nivel de interpretacin 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 estndar el que se utiliza para comunicarse con el
nivel de interpretacin se facilita la integracin de nuevos tipos o escenarios en el
nivel fuente.

77

Mltiples plataformas y
mltiples dispositivos
Componentes
centralizados sobre
servidores en diferentes
Mltiples servicios de
terceros.
ElPatrnPiramidaldesdeunaperspectivagenrica

Una de las pretensiones que se tienen con el patrn piramidal es que este pueda ser
aplicado como solucin a problemas de aplicacin en las que se requiera tener acceso a
servicios.

Se puede considerar genrico por las siguientes causas.

1. No importa el lenguaje de programacin en ninguno de los niveles.
2. No importa el sistema operativo en ninguno de los niveles.
3. La comunicacin entre niveles es estndar.
4. Solo basta con establecer el medio de comunicacin entre niveles para generar
peticiones y respuestas.
5. No importa el tipo de dispositivo que se encuentre en el nivel base, pueden ser
dispositivos mviles, laptops, PC, etc.
6. El nivel de interpretacin solo debe ser un server centralizado con salida a
internet.

Figura 7, Patrn Piramidal, un enfoque genrico
78

Introduccinalcasodeestudio

Como es notable una aplicacin que se encarga del manejo de transacciones bancarias
es de suma importancia el manejo correcto y seguro de la informacin.

Para este caso de estudio se tomar en cuenta una aplicacin que hace cobros
bancarios, la cual tiene como objetivo realizar cobros bancarios con tarjeta presente y no
presente.

La Aplicacin de Cobros Bancarios es una plataforma que permite a las compaas,
consolidar, y hacer ms eficiente la gestin de cobros con tarjeta bancaria acoplndose a
las estrategias del negocio.

La Aplicacin 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.

ModeloBsicodeOperacin

Existe un modelo bsico de operacin que aplica de manera genrica 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 depsitos, realizando estas dos entidades todo un intercambio,
compensacin y liquidacin 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
ttulo garantizando (medio de pago) y respaldando el pago de su cliente.
79

La entidad financiera Adquirente, banco del Comercio, que adquiere los ttulos
anteriores y los deposita al Comercio.
Un sistema para intercambiar, compensar y liquidar estos ttulos 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

ProcesamientodeMediosdePagoElectrnicos

El procesamiento de tarjetas de crdito ocurre en dos pasos: la autorizacin en tiempo
real y la compensacin de los fondos que fueron autorizados.

Autorizacin

Una transaccin comienza cuando el tarjetahabiente presenta su tarjeta de pago al
Comercio para adquirir bienes o servicios. La informacin de la transaccin es enviada
electrnicamente al Banco Emisor para solicitar la autorizacin del cobro cargo. El banco
verifica que la tarjeta sea vlida, evala si tiene saldo disponible, checa el cdigo de
seguridad, y regresa una respuesta: Aprobada, Rechazada u otras. El Comercio recibe la
respuesta segundos despus de hacer la solicitud.

Liquidacin y Compensacin

La compensacin bancaria es una forma de extincin de deudas entre instituciones
financieras por la que dos o ms de ellas equilibran sus deudas recprocas. La
liquidacin es la transferencia de fondos, proceso por el cual una operacin es saldada.

Diariamente se compensan las cuentas bancarias y se liquidan los fondos de las
transacciones realizadas en el periodo. Una vez realizada la compensacin, 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 transaccin. El Comercio depende de terceros para asegurar que el
consumidor puede pagar por la transaccin y para autentificar que el consumidor est
autorizado para realizar la compra.
Problemtica

El problema nace por la necesidad de poder implementar la plataforma de La Aplicacin
de Cobros Bancarios en diferentes escenarios con el fin de poderlo masificar y utilizar
81

desde diversos dispositivos, pero siempre cumpliendo con diferentes estndares de
seguridad y resguardo de la informacin.

Con el objetivo de acrecentar el nmero de clientes potenciales de la aplicacin y as
poder llevar la solucin a muchos ms dispositivos y en consecuencia a ms clientes.

Tambin el problema nace de la necesidad de ofrecer un producto distinto a terminales
punto de venta, tradicionales, se pretende ofrecer una solucin centralizada con diferentes
posibilidades de accesibilidad e integracin. Una solucin verstil, que permita utilizar
componentes prediseados listos para usarse, o bien, ofrecer herramientas para que
aplicaciones ya existentes puedan integrar la solucin mediante componentes ya
elaborados.
ExplicacinTcnicadelaProblemtica

Tcnicamente la aplicacin de Cobros Bancarios cuenta con una arquitectura cliente
servidor la cual bsicamente se trata de componentes fsicos de software y hardware que
se encuentran instalados en un ordenador cliente y que hacen peticiones a los servicios
bancarios a travs de mensajes ISO 8583.

El problema se encuentra en que cuando se necesita integrar una nueva plataforma o un
nuevo dispositivo o una nueva aplicacin prcticamente se requiere regenerar la
aplicacin y adaptarla al lenguaje de programacin correspondiente, lo que es una tarea
de alto costo, prcticamente se tiene una aplicacin por cada escenario o interfaz.

Esta situacin detiene bastante el objetivo de masificar la solucin 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 solucin 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 aplicacin de cobros bancarios

PropuestadeSolucinalaproblemtica

A continuacin se describen los pasos para el procesamiento electrnico de una
transaccin, aplicando un modelo arquitectnico 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 eleccin.

2. El Comercio somete una transaccin de tarjeta de crdito al Gateway de Pagos en
nombre del cliente, a travs de una conexin segura desde diferentes canales de venta:
Internet, mostrador, correo, terminal mvil.

83

3. El Gateway de Pagos, cumpliendo con los requisitos de seguridad y transmisin,
traduce la informacin de la transaccin en un mensaje de solicitud de autorizacin y lo
transmite al Procesador.

4. El Procesador en ruta la solicitud de autorizacin al Banco Emisor de la tarjeta para su
autorizacin.

5. El Emisor aprueba o declina la transaccin en base a los fondos disponibles del Cliente
y pasa el resultado de la transaccin de regreso al Procesador.

6. El Procesador transmite el resultado de la transaccin al Gateway de Pagos.

7. El Gateway de Pagos almacena el resultado de la transaccin y lo enva al Comercio.

8. El Comercio termina la transaccin y libera la mercanca al Cliente.

9. El Banco Emisor transfiere al Procesador los fondos de la operacin (precio de venta -
la tasa de intercambio).

10. El Procesador enva 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 transaccin (precio de venta +cuotas por
servicio e intereses sobre el saldo) a la cuenta del tarjetahabiente y le enva su estado de
cuenta de manera mensual.

84


Figura 10, Procesamiento Electrnico de Transacciones.

Con el fin de solucionar la problemtica presentada, se harn pruebas de implementacin
utilizando el patrn arquitectnico piramidal.

El patrn piramidal principalmente establece tres niveles sobre los cuales se encuentra
distribuida una aplicacin.

Nivel Base.
Nivel de interpretacin.
Nivel Fuente.

85

Como recordamos el nivel base es en dnde literalmente nacen las peticiones de
procesamiento de la informacin, en este nivel se pueden encontrar gran cantidad de
vistas que generen solicitud de informacin.

Para este caso principalmente interesa este nivel, ya que es aqu en donde el negocio
pretende masificar su servicio, permitiendo abrir las posibilidades a ms clientes con
distintas plataformas integradas.

Con la definicin que se tiene del patrn piramidal, podemos atacar el punto de la
masificacin interponiendo en el nivel base componentes integrables a diferentes
lenguajes tales DLLs, J ars, OCX, etc. En resumen bibliotecas que puedan implementarse
en diferentes lenguajes. Tambin es conveniente generar vistas para el nivel base que
estn 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 mltiples 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 aplicacin e cobros bancarios sin aadir alguna interfaz propia.

Generar una interfaz web que permita a los clientes ingresar y generar cobros desde
portal para casos muy especficos realizar la interfaz sobre la plataforma de la aplicacin
pero basar la funcionalidad de La Aplicacin de Cobros Bancarios en alguna biblioteca.


Figura 11, Componentes del Nivel Base
86

Es necesario generar o acordar un protocolo de comunicacin va web entre el nivel base
y el nivel de integracin, para este caso se utilizarn web services basados en SOAP.

Una vez que se llega a un acuerdo con el tipo de comunicacin, se debe definir un
lenguaje de consultas que exista entre el nivel de interpretacin y el nivel fuente, para este
caso se utilizar XML.

Por qu es conveniente usar XML? Porque los negocios de hoy en da dependen de la
informacin y los datos pueden provenir de varios orgenes de informacin distintos:
bases de datos, pginas Web, archivos de hojas de clculo y correo electrnico, por
mencionar slo algunos. XML permite trabajar con ms datos de ms orgenes y hacer
ms 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 interpretacin 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 ms trfico ya que pasan por el tanto peticiones de los
clientes como respuestas de servicios de terceros.

87

Recordemos que en el nivel de interpretacin 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 Aplicacin de Cobros Bancarios.

En este caso se utilizar una base de datos Oracle 9i, en donde se almacenarn todos los
registros de las transacciones, as como los usuarios, privilegios, catlogos y dems
registros propios del comercio y necesarios para la correcta operacin del sistema en
general.

El lenguaje que se utilizar para los componentes que se encuentren en el nivel fuente
ser J ava utilizando los beneficios que ofrece el framework Spring a travs de Web
Services.

Este Web Service principalmente se encargar de tomar las peticiones de los clientes
recibiendo un solo parmetro de tipo String en cada uno de sus mtodos, este parmetro
deber estar encriptado y en l se contendr el XML con los nodos correspondientes a la
peticin que est haciendo el componente que se encuentre en el nivel base.

El objetivo de recibir un solo parmetro de tipo String y no un objeto es porque el String es
un tipo de dato muy estndar que prcticamente cualquier lenguaje de programacin tiene
y con esto podemos garantizar que se establezca una comunicacin sin problemas de
compatibilidad entre los componentes del nivel base y del nivel fuente.


Figura 13, Componentes del Nivel de Interpretacin

Para el nivel fuente el lenguaje y mensajera es establecido por el tercero dueo del
servicio que se desea explotar, en este caso existir una comunicacin por medio de web
88

servcies y enviando como parmetros mensajes de tipo ISO 8583, los cuales se enviaran
entre el procesador y La Aplicacin de Cobros Bancarios.

El procesador es una empresa que dedica a recibir peticiones o solicitudes de cobros
bancarios y los enva a los diferentes bancos emisores para su autorizacin o rechazo.

Procesador Bancario
Banco
Internet
ISO
COMPONENTES DEL NIVEL FUENTE

Figura 14, Componentes del Nivel Fuente

A continuacin, se mostrar el flujo completo de la pirmide, tomando los diferentes
niveles y los componentes que los conforman.

89


Figura 15, Patrn Piramidal
FlujodeImplementacindelPatrnPiramidal

A continuacin se explica el flujo utilizando la propuesta del patrn piramidal.

1. Se deben especificar las reglas de negocio a nivel base de datos, as como
establecer restricciones y normalizacin de la misma.

2. Se sugiere generar procedimientos almacenados y transacciones para la
manipulacin de la base de datos y no agregar queries al cdigo de la aplicacin.

3. Posteriormente es conveniente iniciar con el anlisis y programacin del Web
Service que se instalar en el nivel de interpretacin, en este Web Service se
deben establecer reglas de negocio acorde a las necesidades.

4. Establecer protocolos de comunicacin y conexin con servicios de terceros
mismos que se pretenden consumir y que se encuentran en el ltimo nivel de la
pirmide (nivel fuente).

90

5. Se debe establecer el lenguaje y medio de comunicacin para la interaccin entre
el nivel de interpretacin 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 mtodo del Web Service reciba parmetros de tipo
String en este caso se recomienda recibir solo un parmetro encriptado por
algn mtodo genrico y no usar un mtodo de encripcin propio de algn
lenguaje, este parmetro contendr el XML con la informacin de la
operacin 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 PCs de los usuarios finales y de donde se
generarn las peticiones, este programa representa el nivel base de la pirmide.
En estas vistas existirn validaciones, interaccin 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 peticin para invocar el Web
Service que se encuentra en el nivel de interpretacin, as tambin reciben
los XML de respuesta para generar el flujo correspondiente.
91

E
s
ta
b
le
c
e
r
p
ro
to
c
o
lo
s
d
e

c
o
m
u
n
ic
a
c
i
n
y

c
o
n
e
x
i
n
c
o
n

s
e
rv
ic
io
s
d
e

te
rc
e
ro
s

Anlisis y
program
acin del
Web Service
P
r
o
c
e
d
im
ie
n
to
s
y

tr
a
n
s
a
c
c
io
n
e
s
p
a
ra
la

m
a
n
ip
u
la
c
i
n
d
e
la
B
D
E
s
p
e
c
ific
a
r
R
e
g
la
s
a
n
iv
e
l
B
D
G
e
n
e
ra
r p
ro
g
ra
m
a
s

c
lie
n
te
L
e
n
g
u
a
je
y
m
e
d
io
d
e

c
o
m
u
n
ic
a
c
i
n
, X
M
L
FlujodeImplementacindelPatrnPiramidal

Figura 16, Flujo de Implementacin del Patrn Piramidal.
92

CAPTULO4,ImplementandoelPatrnPiramidal.






En este captulo se detallar el proceso por el cual se lleva a cabo una implementacin
del patrn piramidal, tomando en cuenta los elementos citados en el captulo anterior.

As tambin se pretende ilustrar esta implementacin a travs de la aplicacin de cobros
bancarios antes mencionada.

93

ConsideracionesPrevias

Antes de comenzar debemos tomar en cuenta las herramientas y recursos necesarios
para el caso de estudio, como recordamos se llevar a cabo la implementacin de Patrn
Piramidal en una aplicacin de cobros bancarios. A continuacin se enlistan las
herramientas que se utilizarn para este caso:
NivelBase
Herramienta Versin Uso
C#.net 2008 Se utilizar este lenguaje para la creacin del front
end principal en el cual se ingresarn datos
necesarios para iniciar una transaccin.
Visual Basic 6.0 Se utilizar esta herramienta para la creacin 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
ms que implemente las funcionalidades de la DLL
en un ambiente Web.
VB.net 2008 Se utilizar este lenguaje para crear una aplicacin
mvil que pueda invocar el servicio de cobro desde
un telfono con Windows Mobile.
WML/WMLS con Java. 1.6 Se implementar una aplicacin front que corra
sobre terminales punto de venta.
XML Se utilizar para enviar cadenas el nivel de
interpretacin con los datos de la venta.
Tabla 2, Herramientas del Nivel Base

Principalmente estas herramientas estn orientadas a la explotacin de los servicios
desde la vista del usuario, es decir son aquellas aplicaciones que permitirn a los usuarios
comenzar un ciclo de cobro y en general de solicitud a servicios.

94

NiveldeInterpretacin
Herramienta Versin Uso
Java 1.6 Este lenguaje se utilizar para crear el Web Service
de interaccin con el nivel de base y el nivel fuente.
Frameworks Spring 2.0 Se utilizar este frameworks como base de la
programacin java para crear el web services
utilizando las ventajas que ofrece.
SOAP Se utilizar para establecer la comunicacin del
Web Services.
ISO Estandar de mensajera 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 almacenarn
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 Interpretacin

Las herramientas de este nivel, principalmente estn orientadas a servir a las peticiones
que se originan de las vistas que se encuentran en el nivel base, como podemos observar
se utilizarn herramientas orientadas a los servicios y se tomarn ventajas del frameworks
de Spring para lograr mayor nivel de mantenimiento y explotacin.
NivelFuente
Herramienta Versin 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 autorizacin o rechazo de las
transacciones, esta entidad no est controlada por
el proyecto.
Tabla 4, Herramientas del Nivel Fuente
95

PrimerPaso,EspecificarReglasaNivelBasedeDatos

Tomando en cuenta el flujo mostrado en la figura 16, seguiremos los pasos
recomendados y se har cita a la implementacin 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 normalizacin 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
configuracin de la aplicacin, como roles, permisos, catlogos, etctera. A continuacin
se muestra el grupo de tablas tanto transaccionales como no transaccionales, en forma de
un Diagrama Entidad-Relacin:


Figura 17, Agrupacin de tablas transaccionales y no transaccionales
96

DefinicindeElementosdelaBasedeDatos

Para la definicin 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 intencin es indicar los estndares de nomenclatura para Base de Datos, que se
deben utilizar en el desarrollo de aplicaciones y configuraciones tcnicas de la plataforma
distribuida.
El objetivo del establecimiento de estndares dentro es homogeneizar la forma de
definicin de las Bases de datos, as como las mejores prcticas para lograr altos niveles
de productividad y eficiencia de los recursos tecnolgicos 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.
NombredelaInstancia
Nomenclatura:
Baanepp[nmero]
En donde:
B : Identificador fijo, sealando Base de Datos
aa : Identificador de la aplicacin 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 pas (ver Tabla 3: Tabla de pases )
nmero : 1...9
Ejemplos:
Instancias de produccin en Venezuela de la aplicacin con cdigo LA:
BLABPVE1
BasesdeDatos
Nomenclatura:
Baanepp[nmero]
En donde:
B : Identificador fijo, sealando Base de Datos
aa : Identificador de la aplicacin 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 pas (ver Tabla 3: Tabla de pases )
nmero : 1...9
Ejemplos:
Base de Datos de produccin en Venezuela de la aplicacin con cdigo 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 : Nmero consecutivo en tres posiciones
consecutivo : Nmero 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 aplicacin de 3 a 5 posiciones
[numero]: Nmero consecutivo en tres posiciones
mmm : Descripcin mnemnica del contenido de la tabla (20 caracteres)
en singular.
98

Ejemplo:
Tabla de sucursales de la aplicacin LAR: TLA002_SUCURSAL
Columnas
Nomenclatura:
pp_mmm
En donde:
pp : Prefijo que indica el tipo de dato
st : status
id: identificadores
cd: cdigos,claves
pw: password
fh: fechas
hm: hora
tm: timestamp
im : importe
nb : nombres, descripciones
nu : nmero
pc : porcentajes
tp : tipos
tx : textos
cc: credit card
mmm : Mnemnico 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 telfono 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 descripcin de sus actividades: tx_actividades
Columna para indicar la tarjeta de crdito: cc_
Vistas
Nomenclatura:
Vaa[numero]_mmm
En donde:
V : Identificador fijo, para indicar vista
aa : Identificador de la aplicacin de 2 a 5 posiciones
[numero]: Nmero consecutivo en tres posiciones, igual a la tabla de la que
proviene en caso de ser solo una tabla
mmm : Descripcin mnemnica del contenido de la vista (20 caracteres)
en singular.
Ejemplo:
Vista de sucursales de la aplicacin PBA: VPBA001_EMPLEADO
ndices
Nomenclatura:
Iaannnt[numero]_mmm
En donde:
I : Identificador fijo, para indicar ndices
aa : Identificador de la aplicacin de 2 a 5 posiciones
nnn :1..999 Nmero consecutivo de la tabla a la cual pertenece en 3
posiciones
t : - Guin bajo
[numero]: 1..9 Nmero consecutivo en 1 posicin
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
Llavesforneas
Nomenclatura:
Rpppddd[numero] Se llamar igual que su Regla de Integridad Referencial
En donde:
R : Identificador fijo, para indicar regla de integridad referencial
ppp : Nmero consecutivo de la tabla padre.
ddd : Nmero consecutivo de la tabla hijo
[numero]: Nmero consecutivo en una posicin
Ejemplo:
Llave fornea 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 : Nemnico a 3 primeras posiciones de la tabla padre.
ddd : Nemnico 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 : Nemnico de la tabla padre.
Ejemplo:
Trigger de insercin de la tabla PBA001_SUCURSAL: TGINS_SUCURSAL
Procedimiento
Nomenclatura:
sp_ppp
En donde:
sp : Identificador fijo, para indicar que es un procedimiento almacenado
ppp : Nemnico de hasta 20 posiciones
Ejemplo:
Procedimiento de selecciones de campaas: SP_SELECC_CAMPANIA

Funcin
Nomenclatura:
fn_ppp
En donde:
fn : Identificador fijo, para indicar que es una funcin
ppp : Nemnico de hasta 20 posiciones
Ejemplo:
Funcin de selecciones de campaas: FC_SELECC_CAMPANIA

Secuencia
Nomenclatura:
sq_ppp

En donde:
sq : Identificador fijo, para indicar que es una secuencia
ppp : Nemnico de hasta 20 posiciones de la secuencia
102

Ejemplo:
Secuencia de campaas: SQ_CAMPANIA (si se genera consecutivo para la
tabla PBA013_CAMP_PROMO).

Ligasdebasededatos(databaselink)
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
Sinnimo
Nomenclatura:
Nombre de la tabla o vista original.
Ejemplo:
Sinnimo pblico 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 : Nemnico de hasta 20 posiciones

Ejemplo:
Paquete de selecciones de campaas: PG_SELECC_CAMPANIA
Usuario
Nomenclatura:
Usr Prefijo fijo
ppp Nombre de la aplicacin
103

Ejemplo:
Base de Datos de Aplicacin pruebas: Usrpbas
Role
Nomenclatura:
rl_ppp
En donde:
rl : Identificador fijo, para indicar que es un role.
ppp : Nemnico 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 : Nemnico de hasta 20 posiciones
Ejemplo:
Role para usuario de seguridad de datos: PF_SEGURIDAD

104

SegundoPaso,ManipulacindelaBasedeDatos

Una vez definida toda la estructura de la Base de Datos es momento de implementar
procedimientos, funciones, transacciones, disparadores que permitan la manipulacin de
los datos.

El objetivo de implementar directamente en la base de datos parte de la lgica del negocio
es para evitar recompilar el Web Service al momento de hacer algn cambio en alguna
consulta o el algn cambio de la estructura de la base de datos, como por ejemplo
agregar o eliminar un campo, una tabla, etctera.

Tambin es para explotar las bondades de las transacciones utilizando sus elementos
como el Commit y Rollback en caso de algn problema y as evitar problemas de
inconsistencia en los datos.

Se sugiere generar procedimientos almacenados y transacciones para la manipulacin de la base de datos y no agregar
querys al cdigo de la aplicacin.

A continuacin se muestra la estructura de una funcin, la cual siempre devuelve como
resultado de consulta un valor booleano, en este caso se muestra esta funcin con el fin
de ejemplificar la forma propuesta para la manipulacin 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 definicin.

Procedimiento/Funcin/Transaccin Descripcin
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 descripcin 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 transaccin 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, Descripcin de Procedimientos
106

TercerPaso,AnlisisyDesarrollodelWebService

Una vez establecida la estructura de la Base de Datos es pertinente generar el Web
Service que se implantar en el nivel de interpretacin el cual fungir como intrprete de
mensajes entre el nivel base y el nivel fuente.
Posteriormente es conveniente iniciar con el anlisis y programacin del Web Service que se instalar en el nivel de
interpretacin, en este Web Service se deben establecer reglas de negocio acorde a las necesidades.

A continuacin se enlistaran las clases que contendr el web services y se dar una
explicacin de su funcionalidad.

Clase Descripcin
XMLService Esta clase se encargar del manejo de los esquemas XML as
como de la construccin y validacin 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 enve 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 conexin con la
base de datos as como la invocacin de los procedimientos
almacenados, transacciones y funciones.
LogService Esta clase se encargar de guardar los eventos que sucedan
entre el flujo de la operacin.
ComService Esta clase contendr los mtodos necesarios para establecer una
comunicacin entre los niveles.
TransactionService Esta clase contendr los mtodos de las operaciones a realizar.
Tabla 6, Descripcin de Clases
107

En seguida se enlistan nuevamente las clases, pero ahora se incluyen sus mtodos y una
breve descripcin de estos:

XMLServices:
Accesibilidad Mtodo Descripcin
+ ValidateSchema (String XML)
: String
Valida que el esquema de la operacin 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 transaccin a realizar recibe un string
con el ttulo 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
transaccin el cual se devolver al nivel
base y recibe un arraylist con los valores
y nombre de los tags.
Tabla 7, Descripcin de los Mtodos de la Clase XMLServices

ISOServices
Accesibilidad Mtodo Descripcin
+ 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, Descripcin de los Mtodos de la Clase ISOServices

ValidateService
Accesibilidad Mtodo Descripcin
+ 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, Descripcin de los Mtodos de la Clase ValidateService

DBService
Accesibilidad Mtodo Descripcin
+ ExecuteNoQuery (String
TitleProcedure, ArrayList
Parameters) : Boolean
Ejecuta el procedimiento almacenado,
funcin o transaccin con el ttulo
asignado a la variable string y devuelve
un booleano que indica si la ejecucin
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, Descripcin de los Mtodos de la Clase DBService

SecurityService
Accesibilidad Mtodo Descripcin
+ EncryptStringTripeDES
(String Data) : String
Encripta una cadena con el algorimo de
encripcin TripleDES.
+ DecryptStringTripleDES
(String Data) : String
Desencripta una cadena con el
algoritmo TripleDES.
+ GenerateKey (String
FirstKey, String SecondKey)
Genera una llave con base a los
parmetros que se le setean y la
establece como llave de encripcin.
+ HexConvert (String Data) :
String
Convierte la cadena resultante de una
encripcin en caracteres hexadecimales
para que al momento que viajen no
surjan problemas de caracteres
extraos.
Tabla 11, Descripcin de los Mtodos de la Clase SecurityService

109

LogService
Accesibilidad Mtodo Descripcin
+ 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, Descripcin de los Mtodos de la Clase LogService

ComService
Accesibilidad Mtodo Descripcin
+ SendISO (String Method,
ArrayList Parameters) : String
Enva un mensaje ISO 8583 al Web
Service del procesador y devuelve una
cadena con la respuesta del Web
Service.
Tabla 13, Descripcin de los Mtodos de la Clase ComServices

TransactionService
Accesibilidad Mtodo Descripcin
+ ExecuteOperation (String
Transaction, String XML) :
String
Recibe el ttulo y XML correspondientes
a una operacin invocada desde el nivel
base por ejemplo una venta,
cancelacin, etc, devuelve una cadena
encriptada que contiene el XML de
respuesta para los componentes del
nivel base.
Tabla 14, Descripcin de los Mtodos de la Clase TransactionServices

110

CuartoPaso,ProtocolosdeComunicacinyConexinconservicios

En este paso se debern establecer los medios de comunicacin con los servicios de
terceros que se encuentran en el nivel fuente. En este caso ser con el procesador de
cobros bancarios.

Protocolodecomunicacin

Para este caso de estudio la comunicacin 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 interpretacin 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 funcin de notificar en caso de que se caiga la comunicacin entre estos.


Figura 17 Protocolo de Comunicacin entre el nivel de interpretacin y el nivel fuente

Los sockets son un sistema de comunicacin entre procesos de diferentes mquinas de
una red, un socket es un punto de comunicacin por el cual un proceso puede emitir o
recibir informacin.
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 comunicacin, para conectarse a una mquina
remota en un determinado puerto que est disponible, para escuchar en l, para leer o
escribir y publicar informacin en l, y finalmente para desconectarse (Marshall K.
McKusick, 2004).

EstndarISO8583,Conexinconelprocesadorbancario

Como se ha venido mencionando a lo largo del desarrollo de este caso de estudio, existe
un estndar diseado nica y exclusivamente para el manejo de mensajes de tipo
financieros para la autorizacin de cobros bancarios.

En este caso de estudio se utilizar este estndar para la comunicacin entre el nivel de
interpretacin y el nivel fuente, como ya sabemos estos mensajes se transportarn a
travs de sockets.


Figura 18, Pas de mensajes IS0 8583 entre niveles de interpretacin y fuente.

112

ISO 8583 es un estndar para Transacciones Financieras con Mensajes originados en
una tarjeta bancaria (ISO 8583-1:2003, 2007).

Es el estndar ISO se debe utilizar para sistemas que intercambian transacciones
electrnicas realizadas por poseedores de tarjetas de bancarias.

Una transaccin basada en una tarjeta usualmente sale desde un dispositivo de compra,
tal como un POS o un cajero automtico ATM, a travs de una red (o redes) hacia un
sistema del emisor de la tarjeta para obtener una autorizacin en funcin de la cuenta del
titular de la tarjeta.

La transaccin contiene informacin que se obtiene de la tarjeta (ej. nmero de cuenta), la
terminal (ej. nro. de comercio), la transaccin (ej. importe) en conjunto con otra
informacin que se puede generar o agregar dinmicamente por los sistemas
intervinientes.

El sistema emisor de la tarjeta podr autorizar o rechazar la transaccin, 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 comunicacin para que diferentes
sistemas puedan intercambiar estas transacciones.

La mayora de las operaciones realizadas en ATM usan ISO 8583 en algunos puntos de la
cadena de comunicacin, as como tambin 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 estndar ISO 8583. Las transacciones incluyen compras,
extracciones, depsitos, reintegros, reversos, consultas de saldo, pagos y transferencias
entre cuentas. ISO 8583 tambin define mensajes entre sistemas para intercambios
seguros de claves, conciliacin de totales y otros propsitos administrativos.

Aunque el ISO 8583 define un estndar comn, no se usa normalmente en forma directa
por sistemas o redes. En lugar de eso cada red adapta el estndar para su propio uso con
campos adaptados a sus necesidades particulares.
113

La ubicacin de los cambios en diferentes versiones del estndar varia, por ejemplo, los
elementos que definen la moneda (currency elements) de las versiones 1987 y 1993 no
se usan ms en la versin 2003, lo que hace que la moneda sea un sub-elemento de
cualquier elemento monto. LA ISO 8583:2003 todava tiene que obtener aceptacin.
Un mensaje ISO 8583 consta de las siguientes partes:

Message Type Indicator (MTI) - Indicador de Tipo de Mensaje
Uno o ms bitmaps, indicando que elementos estn presentes en el mensaje
Data elements, los campos del mensaje


Figura 19, El estndar ISO 8583
Consultada, http://blog.jotadeveloper.com/2009/01/25/conociendo-el-standard-iso8583/

Message Type Indicator (MTI): Este es un campo numrico de 4 dgitos que clasifica la
funcin de alto nivel del mensaje. Un MTI incluye la versin ISO 8583, la clase (Message
Class), la funcin (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 estn presentes.
Puede existir un mapa de bits secundario, generalmente como elemento 1 que indica que
campos del 65 al 128 estn 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

Explicacin del Bitmap (8 bytes, Bitmap Primario =64 Bit) campo 4210001102C04804

BYTE1 : 01000010 =42x (contando de izquierda, el segundo y el sptimo bit son 1,
indicando que los campos 2 y 7 estn presentes)
BYTE2 : 00010000 =10x (campo 12 est presente)
BYTE3 : 00000000 =00x (no hay campos presentes)
BYTE4 : 00010001 =11x (campos 28 y 32 estn presentes)
BYTE5 : 00000010 =02x (campo 39 est presente)
BYTE6 : 11000000 =C0x (campos 41 y 42 estn presentes)
BYTE7 : 01001000 =48x (campos 50 y 53 estn 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 informacin sustancial acerca de la transaccin.

Hay 128 campos definidos en el estndar ISO8583:1987, y 192 en posteriores releases.
La revisin 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 especfico, el estndar
tambin incluye algunos campos de propsito general y algunos especiales para sistemas
o pases, los cuales varan sustancialmente en su forma y uso de una implementacin a
otra.

Cada campo se describe en un formato estndar que define el contenido permitido del
campo (numrico, binario, etc.) y el largo del campo (variable o fijo), de acuerdo a la
siguiente tabla:

Abreviatura Significado
a Alfanumrico, incluyendo los espacios
n Slo valores numricos
s Slo caracteres especiales
an Alfanumrico
as Slo caracteres alfanumricos y especiales
ns Slo caracteres numricos y especiales
ans Caracteres Alfabeticos, numericos y especiales
b Informacin binaria
z Tracks 2 y 3 code set como se define en la ISO 4909 y en ISO 7813.
Tabla 16, Definicin de campos de los Data Elements.

Como observamos es todo un estndar que se debe cumplir para poder establecer
comunicacin con el procesador de transacciones, a continuacin se muestra un mensaje
ISO 8583, que el Web Service del nivel de interpretacin debe enviar al procesador de
transacciones bancarias:

ISO0250000500200B238C40128A1801A000000001000019C0000000000066549820708183620891267123620070807083
009012015215474848000327682=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 comunicacin ISO 8583 es obligatoria para toda aquella entidad que desee incorporar
a sus procesos de negocio el envo electrnico de transacciones bancarias, ya sean
procesadores, gateways, cajeros automticos, etc.

El estndar ISO 8583, sera el cuarto paso de este caso de estudio de implementacin del
patrn piramidal.
117

Quinto paso, Lenguaje y medio de comunicacin entre el nivel base e
interpretacin

En estos momentos ya tenemos desarrollado un Web Service que se encuentra en el
nivel de interpretacin as como su comunicacin con el nivel fuente, en estos momentos
toca desarrollar un lenguaje y medio de comunicacin entre los niveles base y de
interpretacin.

Como se ha venido mencionando, es recomendable establecer un lenguaje estndar que
se pueda ser interpretado por casi cualquier lenguaje de programacin.

Para este caso de estudio se recomienda utilizar esquemas XSD para establecer la
tipologa de los datos y el XML para intercambiar informacin respetando siempre los
esquemas.

EsquemasXSDcomoLenguajedeInterpretacin

Los esquemas XSD son un vocabulario para expresar las reglas de los datos que se
utilizarn y sirve de referencia para validar los datos que aparecern 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 continuacin:

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 nmero de hijos de los elementos.
Define cuando un elemento es vaco 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 errneo.

Los XSD se utilizan para validar mucho sobre la estructura de los XML, a continuacin se
enlistan varios de sus usos:

Validar el contenido de un documento XML.
Determinar que el documento XML es una instancia vlida del vocabulario
(gramtica 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 vaco 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 nmero 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 caracterstica
ms 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 opcin no resulta especialmente til.
119

EjemplodeunesquemaXSD
El siguiente ejemplo muestra un sencillo esquema XML que podra ser til para gestionar
los productos existentes en un almacn:

<?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 estndar XSD y
es la que nos permite definir esquemas de acuerdo con el estndar 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 programacin, indicando
los elementos correspondientes a cada dato almacenado acerca de los productos de
nuestro almacn, su identificador y su tipo.

Los elementos se utilizan para especificar las etiquetas vlidas en un documento XML
(name) y su tipo (t ype), tal como aparece en el ejemplo anterior. Adems, 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 definicin de elementos y atributos de un esquema XML y
nos permiten especificar restricciones adicionales sobre los datos que pueden aparecer
en un documento XML vlido.
120

NotacinXSDparaelniveldeinterpretacin

Para el nivel de interpretacin se utilizarn 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 interpretacin contendr cuatro esquemas que representarn las
funcionalidades que existen en el nivel base a las que tendrn alcance los usuarios, los
esquemas representan las siguientes funcionalidades:

Solicitud de Cobro bancario.
Solicitud de Cancelacin de un cobro antes realizado.
Reimpresin de un voucher.
Consulta de transacciones.

Los XSD para este nivel estarn subdivididos por dos elementos fundamentales, uno que
contendr datos del comercio y otro que contendr datos especficos de la funcionalidad o
transaccin a realizar.


Figura 20, elemento business de los esquemas del nivel de interpretacin

El elemento business, contiene la informacin 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, tambin para verificar si este usuario tiene permisos para llevar a
cabo esta operacin, 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 identificacin de
los comercios que generen peticiones, a continuacin se explican los elementos
contenidos en el tag business.

122

Elemento Caractersticas
id_company Tipo dato: String
Longitud mxima: 4 posiciones
Naturaleza: Obligatorio
Aplica a Operaciones: Todas
Valor Fijo: Nmero de Comercio.
id_branch Tipo dato: String
Longitud mxima: 10 posiciones
Naturaleza: Obligatorio
Aplica a Operaciones: Todas
Valor Fijo: Nmero de unidad de
negocio (Por ejemplo: sucursal).
country Tipo dato: String
Longitud mxima: 3 posiciones
Naturaleza: Obligatorio
Aplica a Operaciones: Todas
Valor: Pas desde donde se enva la
solicitud de cargo.
user Tipo dato: String
Longitud mxima: 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 mxima: 15 posiciones
Naturaleza: Obligatorio
Aplica a Operaciones: Todas
Valor: Contrasea asociada al
usuario.
Tabla 17, elementos del tag business


123

El segundo elemento (transacction) contendr informacin ms especfica de la
operativa a realizar, y es variable de acuerdo a dicha operativa.

SolicituddeCobrobancario
Esta funcin 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
transaccin 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 jerrquica en dos elementos,
uno que contiene datos del comercio que da origen a la peticin y otro que contiene los
datos de la operacin dichos con los cuales se generar el mensaje ISO 8583.

A continuacin se muestra esta funcionalidad a forma de esquema con el fin de denotar
las reglas de formato que se establecen en el nivel de interpretacin y que toda interfaz
del nivel base debe cumplir, para que su peticin 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 operacin de cobro, a continuacin se explican los elementos del tag
transacction.

127

Los siguientes son los parmetros utilizados en las funciones de cobro, su utilizacin
depende si se trata de una transaccin con las variantes de con Tarjeta Presente.

Estos parmetros indican detalle de la transaccin y muchos de ellos sern tomados por
la clase ISOService, para generar el mensaje ISO 8583 que ser enviado al procesador
que se encuentra en el nivel fuente.

Parmetro Naturaleza Descripcin
amount Obligatorio Cantidad a cobrar.
crypto Depende
de la
operacin
Bandera que indica el nivel de encripcin para el
nmero de la tarjeta.
0 =no est encriptado
1=esta encriptado solo el nmero de la tarjeta
2=toda la informacin del track est encriptada
currency Obligatorio Tipo de moneda.
merchant Obligatorio Referencia del nmero de afiliacin del
Comercio.
reference Obligatorio Nmero referencia de la transaccin.
tp_operation Obligatorio Indica el escenario que se encuentra en el nivel
base del cual proviene la peticin.
usrtransacction Opcional Cdigo de usuario por transaccin.
tracks Obligatorio Contiene la informacin 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 interpretacin, para la realizacin 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>

SolicituddecancelacindeunCobro
Otra de las funcionalidades a las cuales tendrn acceso los usuarios de las interfaces o
escenarios que se encuentren en el nivel base, ser la cancelacin de una transaccin
bancaria ya realizada con anterioridad, para lo cual tambin se han de establecer
esquemas y atributos necesarios para ejecutar esta operacin.

Esta funcin permite al Comercio cancelar una transaccin que se haya realizado durante
el da.

Como dato adicional podemos decir que esta funcionalidad slo podr realizarse antes del
horario de corte bancario (usualmente a las 11:00 p.m.), ya que posteriormente, tendr
que realizarse una devolucin administrativa.

A continuacin se muestra la figura del esquema que se debe cumplir para originar una
solicitud de cancelacin de un cobro bancario.

129


Figura 22, Esquema para la cancelacin 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 prcticamente el
mismo, el cual como ya se haba mencionado contiene los datos necesarios para la
identificacin del comercio que origina la peticin.

Por su parte el tag transacction, contiene informacin especfica de la operacin, a
continuacin se describen los elementos de este tag.

Parmetro Naturaleza Descripcin
amount Obligatorio Cantidad a cobrar.
crypto Depende
de la
operacin
Bandera que indica el nivel de encripcin .
130

usrtransacction Opcional Cdigo de usuario por transaccin.
no_operacion Depende
de la
operacin
Nmero asignado a la operacin original que se
desea cancelar.
auth Obigatorio Nmero de autorizacin de la operacin, se
enva para transacciones como cancelacin,
venta forzada, reverso, etc.
Tabla 19, Elementos del tag transacction de una cancelacin

Ejemplo de un XML que cumple con el esquema expuesto para la cancelacin 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>

SolicituddeReimpresin
Esta funcin permite al Comercio re-imprimir el voucher de una transaccin, de igual
forma el nivel de interpretacin 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 identificacin del
comercio que origina la peticin (business) y otros que contienen informacin especfica
de la operacin.

131

Es importante sealar que esta funcionalidad a diferencia del cobro y cancelacin, no
requiere ir al nivel fuente, ya que en este caso la informacin que requiere la peticin
puede extraerse de la base de datos que se encuentra en el nivel de interpretacin.

A continuacin se muestra el esquema que se debe cumplir para originar una solicitud
correcta de una reimpresin de un voucher.


Figura 23, Esquema para la reimpresin de un voucher


Parmetro Naturaleza Descripcin
crypto Depende
de la
operacin
Bandera que indica el nivel de encripcin.
no_operacion Depende
de la
operacin
Nmero asignado a la operacin original que se
desea cancelar.
Tabla 20, tags complementarios de una reimpresin

//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>
SolicituddeConsultadeTransacciones
Esta funcin permite al Comercio realizar una consulta de las operaciones que ha
realizado con una referencia o fecha especfica.

La funcionalidad es til cuando el Comercio manda datos nicos en este campo, como
nmero de cliente, nmero de factura, nmero de orden, nmero de pliza, nmero de
suscriptor, etc. Se pueden consultar slo una o todas las operaciones del da.

De la misma forma se debe cumplir con un esquema similar a los anteriores con datos
tanto de identificacin como especficos de la operacin.

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

SextoPaso,GenerarProgramasCliente

Una vez establecidos los XML de intercambio se debe generar el programa cliente el cual ser el que se instale en las PCs
de los usuarios finales y de donde se generarn las peticiones, este programa representa el nivel base de la pirmide.

Este paso es en donde se establecen los componentes que conformarn el nivel base de
la pirmide, es decir, de donde se generarn las peticiones.

Los componentes de este nivel deben cumplir con las condiciones de comunicacin, tanto
de mensajera como de flujo que establece el nivel de interpretacin.

En este nivel como se ha mencionado se recomienda generar componentes que incluyan
toda la interaccin con el nivel de interpretacin 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 (DLLs) y
bibliotecas J ava (J ARs), con el fin de que este contenga toda la funcionalidad de
interaccin con el Web Service que se encuentra en el nivel de interpretacin, estos
objetos deben ser capaz de crear los mensajes XML y de enviarlos al nivel de
interpretacin 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 interaccin con los
servicios se quede a nivel de una llamada a un objeto o referencia.
134

CreandoObjetosparainteraccinconelniveldeinterpretacin
ComponenteActivexDLL
Un componente es cualquier software compatible con Automatizacin, por lo que puede
usarse mediante programacin en una aplicacin personalizada. Incluye controles
ActiveX, servidores de Automatizacin basados en Visual Basic y servidores de
Automatizacin basados en Visual C.

La automatizacin es una tecnologa que permite que las aplicaciones proporcionen
objetos de una forma coherente a otras aplicaciones, herramientas de programacin y
lenguajes de macros.

Las siglas COM significan Component Object Model que traducido sera algo as como
modelo de objetos componentes. COM es el "modelo de objetos" fundamental sobre el
que se generan OLE (Object Linking and Embedding, Vinculacin e incrustacin de
objetos) y los controles ActiveX. COM permite que un objeto exponga su funcionalidad a
otros componentes y aloje aplicaciones. Define cmo el objeto se expone a s mismo y
cmo funciona dicha exposicin en procesos y en redes. Adems, COM define el ciclo de
vida del objeto.

Los componentes COM son programas que permiten ser utilizados desde otro programas
mediante automatizacin. 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 creacin de uno de estos componentes
nos permite escribir un cdigo que "posiblemente" nos servir para usarlo en ms de una
aplicacin, adems 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 cdigo de ese
componente, slo tendremos que distribuir esa biblioteca y no el resto de la aplicacin,
incluso puede ser que ese componente se ejecute desde un servidor, con lo cual
simplemente actualizndolo en el servidor, el resto de las aplicaciones "cliente" que lo
utilicen estarn actualizados a la ltima versin.
135

En este caso de estudio las interfaces que funcionen sobre un sistema operativo Win32
debern 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 mtodos y propiedades, solicitudes de Autorizacin de Transacciones con
Tarjeta de Crdito y Dbito.

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 Interpretacin 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 mtodo y parmetros
correspondientes a la transaccin que se desea realizar.

La DLL invocar al servicio con los datos de la transaccin, con los que el Nivel de
Interpretacin hace una solicitud de Autorizacin de Transaccin al procesador que se
encuentra en el Nivel Fuente. El resultado de la Solicitud de Autorizacin es
proporcionada a la interfaz de acuerdo a las especificaciones de la DLL.

El Control cpIntegracionEMV.dll deber realizar una conexin a travs 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 fungirn como referencias o dependencias de este componente.
136

Otro punto importante que vale la pena mencionar es que este componente tambin
contendr interaccin con dispositivos lectores de tarjetas bancarias.

A continuacin se detalla el flujo de operacin de una transaccin de cobro con presencia
de tarjeta bancaria, desde el componente DLL.

Este flujo que deber ser programado en la aplicacin del Nivel Base, para integrar de
manera efectiva la interaccin con el Nivel de Interpretacin con el control
cpIntegracionEMV.dll.

# Funcin Comentario
1 .dbgSetUrl URL al que se conectar la aplicacin del Nivel Base con el Nivel de
Interpretacin.
.dbgSetReader Devuelve true cuando encuentra un lector vlido y false cuando no hay
ningn lector conectado.
2 .dbgStartTxEMV Prepara a la DLL y establece la comunicacin con el dispositivo de lectura
para iniciar el proceso de la transaccin.
3 .chkCc_ExpMonth,
.chkCc_ExpYear,
.chkCc_Name,
.chkCc_Number.
Si la lectura es exitosa, los parmetros chkCc*, la aplicacin podr mostrar
los datos correspondientes a la tarjeta leda.
4 .sndVentaDirectaEMV Una vez leda la tarjeta, se debe ejecutar esta funcin con sus parmetros
correspondientes para enviar la transaccin al Web Service del Nivel de
Interpretacin 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 transaccin, principalmente la funcin
getRspDsResponse la cual trae tres posibles valores: aproved, denied o
error. Con base al resultado, se sabr qu acciones tomar, por ejemplo:
- Si la transaccin fue aprobada la aplicacin del Nivel Base podr llamar a la
funcin getRspVoucher para imprimir el vaucher resultante o la funcin
getRspAuth para obtener el nmero de autorizacin asignado a la
transaccin.
- Si la transaccin ha sido rechazada se puede mandar un mensaje en
pantalla de que la transaccin se deneg.
- En caso de que el resultado sea error puede mandar a llamar la funcin
getRspDsError para saber el detalle del error o la funcin getRspCdError
para saber el cdigo del error generado por el Web Service.
6 dbgEndOperation Antes de salir de la aplicacin, se debe ejecutar esta funcin para eliminar la
conexin con el dispositivo de lectura.
Tabla 21, Flujo de Operacin control Activex del Nivel Base

137

Con este flujo de operacin las aplicaciones del Nivel Base podrn mostrar a los usuarios
el resultado de una peticin de cobro bancario.

Se establecen parmetros de conexin
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 funcin para el envo de cobro con tarjeta
Se enva la solicitud de
autorizacin
.sndVentaDirectaEMV
Se analiza la respuesta de la solicitud
Aprobada, Declinada o
Error
getRspDsResponse
Flujo de Operacin

Figura 25, Flujo de Operacin 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 Interpretacin.

SolicituddeCobrobancarioaNivelBaseconActivex

En seguida se mostrarn los esquemas en el que se detallan los parmetros que debe
recibir la DLL con los cuales internamente generar el mensaje XML para enviarlo al Nivel
de Interpretacin, para cada uno de los mtodos del Web Service.

138

La primer operativa a analizar es la de un cobro bancario esta funcin permitir a la
aplicacin 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 aplicacin que invoque a la DLL deber
generar una transaccin asociada a una referencia, importe, y forma de pago.



Figura 26, Funciones de entrada en la DLL para generar un mensaje de cobro
139

SolicituddecancelacindeunCobroaNivelBaseconActivex

Esta funcin permite a la aplicacin del Nivel Base cancelar una transaccin que se haya
realizado durante el da proporcionando el nmero de operacin, la autorizacin e
importe.

La operacin de cancelacin puede ser interpretada como una devolucin considerando
que se haga en el mismo momento del cobro.


Figura 27, Funciones de entrada en la DLL para generar un mensaje de cancelacin

140

SolicituddeReimpresinaNivelBaseconActivex

Esta funcin permite a la aplicacin del Nivel Base reimprimir el voucher de una
transaccin, para lo cual es necesario enviar el Nmero de Operacin
(Tx_OperationNumber). La funcin getRspVoucher, devolver una cadena con el voucher
listo para imprimir; la funcin getRspXML, devolver el XML de los campos que componen
el voucher. En caso de que la aplicacin del Nivel Base requiera extraer los datos que
contiene el voucher, deber hacerlo de la funcin getRspXML.


Figura 28, Funciones de entrada en la DLL para generar un mensaje de reimpresin

141

SolicituddeConsultadeTransaccionesaNivelBaseconActivex

Con esta funcin la aplicacin del Nivel Base a travs de la DLL, obtendr detalle de las
transacciones que ha realizado hasta el momento parametrizando por nmero de
operacin, referencia y fecha.

Las aplicaciones debe obtener el resultado del query ejecutado en el Nivel de
Interpretacin a travs de la funcin getRespXML en formato XML y con esto la
aplicacin deber ser capaz de procesar el resultado y mostrarlo al usuario o ejecutar
alguna operacin propia de dicha aplicacin.


Figura 29, Funciones de entrada en la DLL para generar un mensaje de consulta
142

InterfacesalasqueaplicaelcontrolActivex

Como ya se ha mencionado un control Activex es un componente que puede ser
referenciado por diferentes lenguajes de programacin 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, J avascript, VBScript, Visual Data Flex, entre muchos
otros. De hecho esta es la intencin de crear un componente que encapsule la
funcionalidad de comunicacin con el Nivel de Interpretacin, 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, adems de la posibilidad de que el comercio pueda integrar
a su propia interfaz estas funciones, una de estas interfaces es una aplicacin 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, Aplicacin a 32bits del Nivel Base
143


Otra interfaz que contendr esta funcionalidad ser un dispositivo mvil basado en
Windows Mobile y contendr de la misma forma una referencia a un componente que se
comunique con el Nivel de Interpretacin, en seguida se muestra una pantalla ejemplo de
esta aplicacin.


Figura 31, Aplicacin basada en Mobile

Por otra parte con este modelo se pueden hacer llamadas al Nivel de Interpretacin,
desde el Nivel Base, integrando la DLL en un ambiente Web, a travs de un J avaScript, a
continuacin se muestra el ejemplo de una pantalla que contendra la funcionalidad en un
ambiente Web.

Figura 32, Aplicacin 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 J AR fueron principalmente pensados para los applets de J ava con el fin de
empaquetar todos los componentes necesarios para su ejecucin y es una abreviacin de
J ava Archive.

Un archivo J AR es una coleccin de clases J ava compiladas y otros recursos que pueden
requerir las clases en tiempo de ejecucin, un J AR permite la agrupacin de los archivos y
recursos en un archivo que puede ser comprimido y es 100% compatible con archivos Zip.

Un J AR permite empaquetar las clases de un proyecto en un solo archivo y
posteriormente desde otra aplicacin hacer una referencia a ese J AR 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 J AR, para las aplicaciones del Nivel Base basadas en J ava.

La arquitectura J avaBeans est basada en modelos de componentes y programacin
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 programacin.

Los componentes J avaBean son conocidos como Beans. Los J avaBeans,
independientemente de su funcionalidad, se definen por las siguientes caractersticas.

Los Beans soportan introspeccin, que permite a una herramienta de programacin
analizar cmo funcionan los Beans. Se adhieren a reglas especficas llamada Patrones de
Diseo para nombrar las caractersticas de los Beans. Una propiedad es un atributo de un
Bean que afecta a su apariencia. Por ejemplo, un botn puede tener las siguientes
propiedades: el tamao, la posicin, etc.
145

Las herramientas de programacin realizan la introspeccin de un Bean para descubrir
sus propiedades y exponerlos para su manipulacin. Las propiedades de un Bean pueden
examinarse y modificarse mediante mtodos o funciones miembro, que acceden a dicha
propiedad, y pueden ser de dos tipos:

Mtodo get: lee el valor de la propiedad
Mtodo set: cambia el valor de la propiedad.

Conforme a la Programacin Orientada a Objetos y la arquitectura J avaBeans, a
continuacin se describe la estructura del componente J ava J AR que formar parte de los
componentes del Nivel Base.

Deben existir dos clases que representan los grupos de operativas.
Cada clase debe contener mtodos que son comparables con los pasos de la
transaccin a realizar; es decir, representan la funcionalidad de la clase.
Todos los Beans contarn con sus propios mtodos get y set, para obtener y
asignar valores, respectivamente.
Deben existir Beans de Operacin, que soportan la operacin de las transacciones.
Deben existir Beans propios de cada operativa, los cuales almacenan datos propios
de cada operacin.

Clases Mtodos Beans de Operacin Beans propios de
cada operativa
Tarjeta Presente datosTarjeta
transacciona
imprime
cancela
Receptor
Transaccion
Respuesta
VentaDirectaBanda
Administrativas imprime
Cancelacin
Reimpresin
Consultas
Cancelacin
Reimpresin
Consultas
Cancelacin
Reimpresin
Consultas
Tabla 22, Descripcin de Clases

146

DescripcindeMtodosdeclases

Los mtodos 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 transaccin disponible en el nivel.

Mtodo E/S Descripcin
datosTarjeta(BeanTransaccion) Parmetros: objeto
BeanTransaccion
Devuelve: void
Clases: Se utiliza solo
en TarjetaPresente
Este mtodo es el primer paso a seguir al ejecutar una
operacin con tarjeta presente ya que es el encargado de
establecer comunicacin con la terminal lectora de tarjetas
asignada en el objeto beanTransaccion en su campo lector.
transacciona(BeanTransaccion) Parmetros: objeto
BeanTransaccion
Devuelve: void
Clases: Se utiliza en
TarjetaPresente y
TarjetaNoPresente
Este mtodo es el encargado de tomar los datos de la
empresa receptora y los datos de la tarjeta para
realizar una transaccin desde el nivel base.
imprime(BeanTransaccion) Parmetros: objeto
BeanTransaccion
Devuelve: void
Clases: Se utiliza en
TarjetaPresente,
TarjetaNoPresente y
Administrativas
Este es el ltimo paso de una transaccin y puede o no
ser ejecutado ya que su uso no afecta el resultado de
la operacin realizada.
cancela() Parmetros: Ninguno
Devuelve: void
Clases: Se utiliza en
TarjetaPresente
Este mtodo puede ser empleado de manera opcional
e idealmente se debe de ejuctar despus del mtodo
datosTarjeta.
Consultas (BeanTransaccion) Parmetros: objeto
BeanTransaccion
Devuelve: void
Clases: Se utiliza en
Administrativas
Este mtodo muestra las transacciones que se llevaron
a cabo en un da en especfico o con una referencia
especfica. Recibe un objeto Bean de tipo
BeanConsultas que tiene asignado el dao referencia
que se desea consultar, o ambas, el objeto
BeanConsultas est dentro de BeanTransaccion.
Reimpresion
(BeanTransaccion)
Parmetros: objeto
BeanTransaccion
Devuelve: void
Clases: Se utiliza en
Administrativas
Este mtodo sirve para obtener una copia del voucher
de determinada transaccin. Para hacer esto solo es
necesario especificar el nmero de operacin que
deseemos reimprimir.
Cancelacion (BeanTransaccion) Parmetros: objeto
BeanTransaccion
Devuelve: void
Clases: Se utiliza en
Administrativas
Recibe un objeto Bean de tipo BeanCancelacion que
tiene asignado el nmero de operacin que se desea
cancelar y el nmero de autorizacin (auth), el objeto
BeanCancelacion est dentro de BeanTransaccion.
Tabla 23, Descripcin de Mtodos de Clases

147

DescripcindeBeansdeoperacin

Como ya se haban mencionado en la tabla anterior, existirn tres tipos principales de
beans con lo que se operar este componente del nivel base, a continuacin se
mencionan:

BeanTransaccion que funciona como contenedor de los dems Beans de
operacin.
BeanReceptor que almacena los datos del comercio en el que se encuentra la
aplicacin que integra al objeto J ar.
BeanRespuesta que contiene el resultado de la operacin que fue enviada a los
niveles posteriores.

Bean Descipcin
beanTransaccion Este es el Bean principal y es el encargado de soportar otros Beans
necesarios para completar cualquier operacin desde el nivel base. El
BeanTransaccin guarda datos del Comercio a travs de BeanReceptor y los
resultados de la operacin 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 travs de los mtodos set del Bean.
beanReceptor Este Bean contiene la informacin relacionada al negocio, se deben llenar
con datos propios del comercio. Contiene adems datos generales que son
compartidos por diferentes operativas.
beanRespuesta Al trmino de cualquier operacin, el resultado es recibido en un objeto del
tipo BeanRespuesta, esta sera la respuesta que viene desde el nivel fuente
y ya se encuentra formateada para que la aplicacin que integre el
componente Jar pueda acceder a todos los datos.
Tabla 24, Descripcin de Beans de Operacin


BeansdeFuncin

Estos Beans representan las funciones a las cuales se desea acceder, es decir son
aquellas las cuales tienen un esquema en el Nivel de Interpretacin. Para acceder a estas
funciones el J ar debe generar un mensaje con un XML que con la informacin accedida a
a las propiedades de los beans, a continuacin se describen los beans de funcin.

148

Funcionalidad Beans Descripcin
Venta Directa Banda Bean: BeanVentaDirectaBanda
Asignar a Bean Tipo: BeanTransaccion
Parmetros propios: Ninguno
Operacin con presencia del cliente y de
la tarjeta en el Comercio; los datos de la
tarjeta son extrados por algn dispositivo
que lee la banda magntica de la tarjeta
o del CHIP para las tarjetas que cuenten
con l.
Cancelacion Bean: BeanCancelacion
Asignar a Bean Tipo: BeanTransaccion
Parmetros propios: operationNumber, auth
Cancela la una transaccin que se haya
realizado con anterioridad en el
comercio.
Reimpresion Bean: BeanReimpresion
Asignar a Bean Tipo: BeanTransaccion
Parmetros propios: operationNumber
Permite reimprimir un voucher de una
trasnaccin.
Consultas Bean: BeanConsultas
Asignar a Bean Tipo: BeanTransaccion
Parmetros propios: date
Esta funcin permite al Comercio realizar
una consulta de las operaciones que ha
realizado.
Tabla 25, Beans de Funcin
InterfacesalasqueaplicaelcomponenteJAR.

Como podemos observar el J AR integra la posibilidad de explotar las funcionalidades de
los niveles posteriores pero a diferencia de la DLL ser a travs de aplicaciones hechas
en J AVA, como aplicaciones Web, Swing, Applets, Servlets e incluso otros Web Services.
La aplicacin que explotar la funcionalidad del J AR 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 conexin a travs de GPRS de un chip de telefona celular.
A continuacin se muestra una figura que contiene el flujo y algunas pantallas para
acceder a la funcionalidad del Nivel de Interpretacin desde una TPV.


Figura 33, Aplicacin TPV Nivel Base
149

ResultadosObtenidos

Si recordamos la problemtica 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 Aplicacin de Cobros Bancarios en diferentes
escenarios con el fin de poderlo masificar y utilizar desde diversos dispositivos, pero siempre cumpliendo con diferentes
estndares de seguridad y resguardo de la informacin.

Como podemos darnos cuenta al final en seis pasos obtuvimos una pirmide con tres
niveles en el primero (Nivel Base) un par de componentes integrables (DLL y J AR) a
diferentes aplicaciones desarrolladas en distintos lenguajes de programacin y que se
comunican con el Nivel de Interpretacin a travs de mensajes XML por medio de SOAP.

En el segundo nivel (Nivel de Interpretacin) 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 travs de responder a las peticiones por medio de SOAP y con mensajes en XML
y que se comunica con el Nivel Fuente a travs 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 Interpretacin por medio de sockets y recibe y
contesta con mensajes de tipo ISO 8583.

Con esta implementacin se permiti a la aplicacin ser modificable e integrable en varios
puntos de venta sin importar la interfaz y lenguaje de programacin de este y as desde el
punto de vista comercial se obtuvo una aplicacin que se puede ofrecer a ms clientes de
distintos tipos.

150

Conclusiones

El patrn piramidal es un conjunto de herramientas orientadas a la creacin arquitectnica
de soluciones distribuidas, buscando siempre un punto genrico con el fin de hacer
genricas a las soluciones como tal, y por lo tanto poder aplicarlas a diversos proyectos,
principalmente aquellos que pretendan masificar soluciones.

El patrn piramidal permite crear estructuras arquitectnicas basadas en tres Niveles
conformados en forma jerrquica. Cada Nivel cuenta con una funcionalidad en especfico,
el Nivel Base que es el primer nivel de la pirmide y del que nacen las peticiones, el Nivel
de Interpretacin l se segundo nivel de la pirmide 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 patrn piramidal no debe haber limitaciones de lenguajes de programacin ya que
la comunicacin entre los Niveles debe estar basada en protocolos de comunicacin
estndar como SOAP y los mensajes pueden estar conformados por cadenas por ejemplo
XML lo cual tambin es estndar. Por este punto es posible utilizar diferentes lenguajes
entre los Niveles.

El patrn piramidal en consecuencia puede ser aplicado a soluciones basadas
principalmente en servicios. Por ejemplo se podra 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 ms amplio en la actualidad es posible conectarse con un Web
Service de las compaas de telefona celular. Con esto podemos considerar como el
Nivel Fuente el Web Service de la compaa de telefnica celular, tambin es posible
151

generar un Web Service que explote el Web Service de la telefona 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
tambin 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 comunicacin
entre los niveles, aplicar reglas de negocio y mejor an podemos implementar una
aplicacin que corra desde cualquier dispositivo y que llame al Web Service de acceso a
datos y no al Web Service de la compaa celular directamente.

Con esto es posible masificar esta solucin y agregar la posibilidad a los comercios
asociados que puedan vender tiempo aire desde una aplicacin ya existente que ellos
utilicen con solo implementar alguno de los componentes del Nivel Base o con una
aplicacin 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 operacin, entonces con esto es posible integrar a su sistema
un componente del Nivel Base y aadir a este mismo sistema la posibilidad de acceder a
la venta de tiempo Aire.


Figura 34, Patrn Piramidal de Venta de Tiempo Aire
152

Como es notable una caracterstica y fin tambin de este patrn es la posibilidad de
integrar la solucin a aplicaciones ya generadas por terceros aadiendo algn
componente del Nivel Base, inclusive comercialmente hablando una empresa que venda
un servicio bajo este patrn podr tener acceso a mayor cantidad de clientes.

El patrn piramidal tambin 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 patrn piramidal permite generar soluciones arquitectnicas fcilmente
integrables y flexibles para sistemas distribuidos.

Con el patrn arquitectnico piramidal se puede tener ms 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 comunicacin
entre dos aplicaciones.

ADL - Lenguaje de Descripcin Arquitectnica - Architecture Description Language), es un
enfoque lingstico a la representacin 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 tecnologas relacionadas
con XML de forma rpida y fcil. XMLSpy incluye un original diseador grfico de
esquemas XML, permitiendo disear y documentar complejos esquemas fcilmente.

ATM - Automated Teller Machine, Es una forma en de llamar a los cajeros automticos
que se encuentran en los bancos.

C
CORBA - Common Object Request Broker Architecture arquitectura comn de
intermediarios en peticiones a objetos

CSC - Card Security Code, es una caracterstica de seguridad para tarjeta de crdito o
dbito, con el fin de dar proteccin contra fraude, son los ltimos tres dgitos de la parte
posterior de una tarjeta bancaria, tambin se conoce como CVV o CVC.

D
154

DLL - Una biblioteca de enlace dinmico es el trmino con el que se refiere a
los archivos con cdigo ejecutable que se cargan bajo demanda de un programa por parte
del sistema operativo.

F
Framework - Se refieren a dominios o clases de problemas especficos

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 comunicacin. Su propsito es traducir la informacin 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 electrnicas realizadas por poseedores de tarjetas de crdito.

J
JAR - Un archivo J AR (por sus siglas en ingls, J ava ARchive) es un tipo de archivo que
permite ejecutar aplicaciones escritas en lenguaje J ava.

155

M
MIL - Lenguajes de interconexin de mdulos

O
OCX - Es un acrnimo que significa "OLE Control Extensin". OLE a su vez significa
Object Linking and Embedding. OCX hace referencia a mdulos que publican controles y
funciones para ser utilizados en programas para Windows, incluyendo especialmente el
navegador Internet Explorer. Tpicamente, estas bibliotecas se presentan en bibliotecas
de enlace dinmico (DLL) almacenadas con extensin .OCX.

S
SOAP - (siglas de Simple Object Access Protocol) es un protocolo estndar que define
cmo 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 ingls, Unified Modeling
Language

W
WSDL - "Lenguaje de Descripcin de Servicios Web" (o "Web Services Description
Language"), Lenguaje basado en XML que permite la descripcin de servicios web
desplegados. WSDL se utiliza tambin para la localizacin y ubicacin de servicios en
Internet.

X
XML - Siglas en ingls 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 utilizarn y sirve de referencia para validar los datos que aparecern en un XML
157

Bibliografa

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. J acobson, 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 J ohnson, J ohn 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. AddisonWesley,
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.