You are on page 1of 122

LICENCIATURA EN INFORMTICA

UNIVERSIDAD NACIONAL DE LA PATAGONIA SAN JUAN BOSCO


TESINA DE LICENCIATURA

SOCIEDAD DE LA INFORMACIN
SWITCH TRANSACCIONAL

INFORME DE TESIS
PUERTO MADRYN, DICIEMBRE 2007

Autor: Damin Barry


Tutor de Tesis: Magster Gustavo Cajaraville
Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

El caos es un orden por descifrar


(Jos Saramago)

Un puente es un hombre cruzando


un puente
(Julio Cortazar)

Informe de Tesina

Proyecto Switch Transaccional Pgina 2 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Agradecimientos

Necesariamente a la familia ya que sin Nora, Matas y Manuel seria impensable haber alcanzado este logro y el soporte
y apoyo necesario para que a los 40 aos haya toma la decisin de terminar esta carrera que tanto amo.

A mi viejo el Peke (deformacin ietesca de Jefe) por ser el visionario que ha impulsado, en gran medida, parte de
los conceptos aqu vertidos y por lo tanto haber sido el compaero que da el sustento filosfico y social a esta tesis.

Al Magster Gustavo Cajaraville porque como tutor de esta tesis me ha dado la libertad necesaria y el apoyo requerido
para encarar lucidamente los temas aqu tratados.

Al Licenciado Carlos Buckle, porque sin su desinteresado asesoramiento me hubiera sido imposible salir del
estancamiento tcnico en que se encontraba la tesis.

En toda formacin universitaria deben existir necesariamente esos impulsores que provocan que uno est seguro de la
carrera elegida, sin duda en ese aspecto debo mi formacin profesional y agradecimiento al Licenciado Ricardo Bustelo
y al Ingeniero Ernesto Mayorga (los duros) por haber compartido y transferido conocimientos y pasin por la profesin
y al Contador Ricardo Barrera por la formacin particularmente lcida en sistemas y en lo sistmico, generado
apertura a nuevas ideas.

Por ltimo a la Universidad Nacional de la Patagonia San Juan Bosco por ser el lugar en el que transcurre gran parte
de mi vida, generador de amistades y alegras en todos estos aos.

Informe de Tesina

Proyecto Switch Transaccional Pgina 3 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Contenido
Agradecimientos...................................................................................................3
Captulo 1 Introduccin......................................................................................6
Encuadre del Proyecto.................................................................................................6
Resumen............................................................................................................................................................
6
Introduccin.........................................................................................................................
.............................6
Descripcin del Proyecto..............................................................................................7
Propsito, Alcances y Objetivos.......................................................................................................... ................7
Justificacin..................................................................................................................................
.....................8
Principales caractersticas........................................................................................................................ ...........9
Resumen de Actividades.................................................................................................................................... .9
Arquitectura............................................................................................................................................
...........9

Capitulo 2 Fundamentacin Terica..................................................................11


Resumen..................................................................................................................11
Cambio de Paradigma: Globalizacin y Sociedad de la Informacin................................11
La (in)evolucin de los sistemas de informacin...........................................................12
Democratizar la Informacin.......................................................................................13
Sistemas organizacionales e interacciones...................................................................14
Actores, roles y necesidades........................................................................................................................
.....14
Sistemas e interoperabilidad.....................................................................................................................
........14
Organizaciones dedicadas a la interoperabilidad...........................................................16
OASIS..............................................................................................................................................
................16
HL7...........................................................................................................................................................
.......17
Tecnologas necesarias..............................................................................................18
SOA...........................................................................................................................................
......................18
Web Services...................................................................................................................................................21
BPM - Orquestacin de Servicios....................................................................................................................... 23
Estndares SOA.................................................................................................................. .............................28

Captulo 3 Proyecto: Switch Transaccional.........................................................39


Proceso de Implementacin.......................................................................................39
Entallamiento del proceso de implementacin..............................................................................................
.....39
Cronograma Original del Proyecto...............................................................................40
Plan de infraestructura y Configuraciones....................................................................41
Introduccin..................................................................................................................................................
...41
Arquitectura.....................................................................................................................................
................42
Definicin de Ambientes..................................................................................................................... ..............43
Ambiente de Desarrollo.................................................................................................................. ..................44

Informe de Tesina

Proyecto Switch Transaccional Pgina 4 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Ambientes de Testing................................................................................................................................
.......46
Ambiente de produccin..........................................................................................................................
.........46
Control de configuraciones...........................................................................................................
....................47
Plan de Contingencia...............................................................................................................................
.........48
Administracin del proyecto.......................................................................................49
Detalle de Horas por Historias del usuario (User Story) Ejecutadas en el Proyecto.............................................49
Resumen de iteraciones.........................................................................................................
..........................51
Solucin...................................................................................................................53
Principales Casos de Uso.................................................................................................................
.................53
Diseo del Switch Transaccional........................................................................................................ ...............56
Modelo de Datos...........................................................................................................................
...................59
Componentes........................................................................................................................................
...........62
Implementacin y Pruebas Formales....................................................................................... .........................68

Captulo 4 Conclusiones...................................................................................70
Bibliografa y referencias.....................................................................................71
Anexos..............................................................................................................72
Anexo A - XML Tags usados para definir un mensaje SOAP...........................................72
Anexo B Proceso General de Implementacin............................................................73
Introduccin..................................................................................................................................................
...73
Elementos del proceso iterativo......................................................................................................... ...............78
Proceso General de Implementacin - Generalidades............................................................................... .........81
Fases e iteraciones del PGI......................................................................................................................... ......84
Roles del PGI..........................................................................................................................
.........................85
Actividades, Responsables y Entregables del PGI................................................................................ ..............88
Anexo C: Detalle del Sistema Operativo.......................................................................94
Anexo D: Detalle Servidor de Base de Datos................................................................97
Anexo E: Detalle del Servidor de Aplicaciones..............................................................98
Anexo F: Detalle de las etapas de implementacin......................................................101
Detalle de iteraciones.....................................................................................................................
................101

Informe de Tesina

Proyecto Switch Transaccional Pgina 5 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Captulo 1 Introduccin
Encuadre del Proyecto
Esta investigacin se realiza como tesina de finalizacin de la carrera de Licenciatura en Informtica dictada por la
Facultad de Ingeniera de la Universidad Nacional de la Patagonia San Juan Bosco Sede Puerto Madryn.
Integrantes: Damin Pablo Barry
Tutor propuesto: Magster Gustavo Cajaraville.

RESUMEN
El objeto del presente trabajo es analizar cmo la sociedad de la informacin tiene un rol primordial para resolver la
problemtica actual en la integracin de aplicaciones, que no es solo econmica sino conceptual y estructural, para ello
intentar por un lado una aproximacin sumaria a la teora del pensamiento complejo y por el otro las capacidades
actuales del estado de la tecnologa como una herramienta de integracin de aplicaciones, basndose para ello en los
distintos consorcios y comits encargados de la definicin de estndares de integracin y conectividad.
Acompaando a la base terica de integracin de aplicaciones se desarrolla un Software denominado Switch
Transaccional que permite gestionar la integracin de distintas aplicaciones agregando una capa de procesos y
validacin de circuitos entre partes, en definitiva el Switch transaccional deber actuar como regulador y controlador
del contrato de intercambio de informacin entre partes.
Palabras claves: Sociedad de la Informacin, Entropa, Neguentropa, Estndares, Comunicacin, Tecnologa, XML,
A2A, B2B, OASIS, W3 Consortium, SOA, Web Services, SOAP, BPM, BPEL, WS-Security.

INTRODUCCIN
A modo de introduccin utilizar algunos textos que ilustrarn la concepcin base que fundamenta este trabajo.
As, desorden y orden a la vez se confunden, se llaman, se necesitan, se combaten, se contradicen. Esta Dialgica se
pone en marcha en el gran juego fenomnico de las interacciones, transformaciones, organizaciones, donde trabajan
cada uno para si, cada uno para todos, todos contra uno y todos contra todos....
El orden viviente es tan refinado y delicado que sera de una fragilidad extrema, si precisamente su refinamiento no le
permitiera manipular el desorden en su provecho y sobre todo regenerarse y reorganizarse permanentemente.
En la ciencia y sobre todo en la poltica, las ideas, a menudo ms testarudas que los hechos, resisten el embate de los
datos y de las pruebas. Los hechos se estrellan efectivamente contra las ideas, mientras no exista nada que pueda
reorganizar de otra manera la experiencia.
En efecto la teora del sistema se anima all donde hay juego activo de interacciones, retroacciones, emergencias,
constreimientos, all donde los antagonismos entre partes, entre las partes y el todo, entre lo emergente y lo
sumergido, lo estructural y lo fenomnico se ponen en movimiento. La teora del sistema toma vida all donde hay vida
y su inters terico mas grande, se despliega a nivel de las sociedades humanas....
La idea de cibernticaarte-ciencia del gobierno puede integrarse y transformarse en co-ciberntica arte-ciencia de

Informe de Tesina

Proyecto Switch Transaccional Pgina 6 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

pilotear conjuntamente, donde la comunicacin ya no es til del mando, sino una forma simblica compleja de
organizacin.
La informacin generativa y la informacin circulante pueden transformarse la una en la otra, pero la transformacin
de una informacin circulante o de seales de informacin generativa no es posible ms que si se encuentra un
aparato capaz de registrarla y tratarla.
As la informacin solo puede nacer a partir de una interaccin entre una organizacin generativa y una perturbacin
aleatoria al ruido. Ergo la informacin no puede desarrollarse ms que a partir del ruido. Y desde luego, en el
nacimiento de una informacin, siempre se necesita una actitud organizacional de carcter negentrpico que se supere
a si misma transformando el evento en novedad, el error en verdad
La informacin es inseparable de la actividad de la totalidad en tanto que totalidad, no obstante, no se diluye en una
confusin holstica. Por el contrario, se convierte en uno de los conceptos cuajados en la idea de organizacin
negentrpica geno - fenomnica de naturaleza informacional / comunicacional.
Edgar Morin, Ctedra Itinerante UNESCO para el Pensamiento Complejo.
As como es indebido anteponer los problemas a las necesidades, la explicacin a la comprensin y la accin al
pensamiento, se torna indispensable aplicar el concepto de interdependencia. Por lo tanto, debemos respetar la
secuencia en la que no hay:
Deseos sin Estructura
Estructura sin Sistema
Sistema sin Funcin
Funcin sin rgano
rgano sin Finalidad
Esta cascada conceptual posee un valor nuclear, pues corrige las representaciones polticas preestablecidas por el
deseo, que indican cmo deben ser o dejar de ser las respectivas construcciones, pero no cmo son y cmo funcionan
en realidad.
Esta Funcin coordina procesos integrados que cruzan y resignifican las funciones tradicionales. De la correcta
aplicacin de esta ecuacin, depende la eficiencia y la equidad del sistema.
La crisis desdibuja su perfil cuando se la generaliza, pues se la vaca de contenido y se diluye la responsabilidad de sus
componentes. Se impone por lo tanto centrarnos en los objetivos y en los aspectos tcnicos y as contener el
desaliento que enturbia la visin del escenario y deforma a los protagonistas.
O revisamos las modalidades polticas que nos condujeron al fracaso, profundizaremos la crisis, que a su vez acenta
la incapacidad de resolverla.
Ignacio Katz, Doctor en Medicina (UBA).
A partir de las experiencias en sistemas de informacin para la administracin y control de gestin y ante el creciente
uso de tecnologa para la interconexin de aplicaciones y dentro de la problemtica poltico-social planteada en la
introduccin, intentar expresar cmo interactan todos los factores de la sociedad y cmo la Sociedad de la
Informacin contribuye al cambio del paradigma social.
Para ello ser clave el desarrollo de un Switch Transaccional que mediante la aplicacin de arquitectura SOA (Service
Oriented Architecture) garantice un medio flexible para la aplicacin de estndares y procesos de negocio.

Descripcin del Proyecto

PROPSITO, ALCANCES Y OBJETIVOS.


Debido a la alta interoperabilidad y los mltiples actores que intervienen en los distintos sistemas y a la creciente
administracin de informacin y transacciones en todo tipo de sistema comunitario (distribuido) (Salud, gobierno,
educacin, justicia, etc.) es necesario disponer de soluciones que permitan integrar a todas las partes, proveyendo

Informe de Tesina

Proyecto Switch Transaccional Pgina 7 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

mtodos y mecanismos seguros para el transporte de dicha informacin. Este integrador tendr la finalidad de
garantizar las reglas de juego establecidas entre las partes, la seguridad y disponibilidad de los servicios ofrecidos y
solicitados. A dicho integrador lo llamaremos Switch Transaccional.
El Switch Transaccional es un conjunto de aplicativos e infraestructura que permiten soportar toda la exigencia y
eficiencia en la integracin de las distintas aplicaciones entre clientes de un servicio y los oferentes del mismo,
soportando mecanismos de seguridad de informacin transportada, flujo de procesos, aplicacin de reglas de negocio
y la recuperacin, seguimiento y continuidad de los servicios de transacciones ofrecidos.
EL Switch Transaccional debe ser considerado ms que un servicio de conectividad un Portal transaccional donde se
obtendrn los siguientes beneficios:
Publicacin de contenidos mediante Web Services a travs del portal del switch, permitiendo la personalizacin
de los mismos a cada usuario.
Tecnologa.
Web Enable.
Administracin y distribucin de mensajes y componentes.
Metamodelos para la definicin dinmica de servicios y procesos transaccionales.
Estndares del mercado: SOA, XML, BPEL, OASIS y W3C.
Posibilidad de conectar mltiples dispositivos de conexin front-end: IVR, POS, Aplicacin cliente PC, Internet.
Conectividad con todos los actores de los distintos sistemas a integrar. Permite mediante protocolos de
comunicacin estndar, conectar las distintas organizaciones y actores, facilitando la interoperabilidad entre
los mismos.
Integra informacin entre las distintas aplicaciones back office del sistema: Construye informacin, permite
publicar mediante servicios informacin de inters de los distintos actores.
Provee independencia entre las aplicaciones back office y las aplicaciones transaccionales. Back office y el
dispositivo front-end
Reglas para el comportamiento de la red. Descomposicin de servicios en sub-servicios dependiendo de pasos
y reglas configurables para cada servicio.

JUSTIFICACIN.
Cada da es mayor la incidencia de las tecnologas de informacin dentro de la sociedad, generando nuevos
paradigmas y enfrentando distintos intereses de la sociedad. Por ello es necesario generar mecanismos que permitan
democratizar la informacin y servicios de las distintas organizaciones que intervienen en la sociedad.
Desde la perspectiva del estado como regulador y controlador de las distintas actividades de los actores de una
sociedad y desde la perspectiva de los ciudadanos como usuario e interesados en la imposicin de mecanismos
garanticen mayor justicia, ecuanimidad y que permitan el acceso a informacin de inters de los particulares y de las
distinats organizaciones.
Por lo tanto es necesaria la construccin de herramientas de infraestructura tecnolgica que faciliten la integracin de
las partes.
Por ello el presente proyecto adems de basarse en estndares de integracin de aplicaciones y servicios promover el
uso de los mismo y la promocin de software Open Source, generando con el presente trabajo un base para futuros
proyectos Open Source enmarcados dentro del mbito universitario. Para alcanzar este objetivo adems de usar
exclusivamente herramientas Open Source el producto resultante queda registrado dentro del esquema de Copy Left,
pasando a formar parte del dominio pblico, para ello se ha registrado dentro del portal de Google para registracin de
Software Open Source utilizando una licencia GLP v2. (http://switchtransaccional.googlecode.com)

Informe de Tesina

Proyecto Switch Transaccional Pgina 8 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

PRINCIPALES CARACTERSTICAS.

Con el Switch Transaccional se intentar:


Promover una estandarizacin de mensajes, transacciones, procesos y conectividad para distintos mercados
verticales, basados en estndares mundiales como SOA, XML, BPEL, OASIS y W3C. Se tomar como base de
investigacin verticales tales como Salud, Justicia y Gobierno en general.
Promover el uso de herramientas y conceptos Open Source. Aportar a la comunidad Open Source una
herramienta de integracin de servicios transaccionales.
Unificar y concentrar el trfico de solicitudes de servicios y transacciones de los distintos sistemas entre las
Organizaciones Privadas y estatales, Empresas, Ciudadanos, Entidades Bancarias o Crediticias, Etc.
Comunicacin y re-envo de mensajes de servicios y transacciones entre redes transaccionales y de servicios.
Proveer configuracin entre una transaccin y los controles a ejecutar en la misma segn la Organizacin
servidora y el demandante, identificando el tipo de control a ejecutar y donde dependiendo de la transaccin y
las partes. Construccin de servicios Back-End en funcin de un conjunto de servicios provistos por los Back-
office. Procesamiento de servicios orientado al contenido.
Registracin de las transacciones ejecutadas y comunicacin de las mismas al Back Office de la Organizacin
duea del servicio prestado, incluyendo un servicio de billing (facturacin) de las transacciones y servicios.
Mapa de integracin. Sponsorizacin de los servicios.

RESUMEN DE ACTIVIDADES
Investigacin sobre los estndares a utilizar: SOA, XML, BPEL, OASIS y W3C.
Investigacin de casos de xito de implementaciones concretas en la integracin de aplicaciones y servicios a
nivel e-Gobierno y comunidad.
Elaboracin de un Paper resumiendo las investigaciones realizadas.
Relevamiento de requerimientos necesarios para el diseo del Switch Transaccional. Escritura de StoryBoard
que representen la funcionalidad operativa requerida por el Switch Transaccional.
Definicin y administracin de la Arquitectura tecnolgica en la cual se soportar el Switch transaccional.
Arquitectura y Diseo del Switch Transaccional, utilizando UML.
Casos de Uso.
Diagrama de Actividades.
Diagrama de Datos y Clases.
Diagrama de Secuencia.
Diagrama de estados.
Construccin
Construccin de los parsers dinmicos mediante el uso de metamodelos para la validacin de los mensajes
y servicios.
Construccin del flujo de procesos dinmico mediante el uso de metamodelos para la composicin y
construccin de superservicios. Administracin de respuestas a los clientes.
Construccin del router de mensajes y servicios hacia los back-office.
Construccin del modulo de administracin del portal. Usuarios, Servicios, Back-office, Front-End.
Construccin del mdulo de logging.
Pruebas Formales.
Puesta en marcha.

ARQUITECTURA.
La Arquitectura del Switch Transaccional prev como primer medida el ruteo y sincronizacin de servicios entre

Informe de Tesina

Proyecto Switch Transaccional Pgina 9 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

organizaciones y entidades, de esta forma el intercambio de servicios y mensajes queda concentrado y estandarizado
en el Switch Transaccional.

Informe de Tesina

Proyecto Switch Transaccional Pgina 10 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Capitulo 2 Fundamentacin Terica


Sociedad de la Informacin Switch transaccional
Uso de Tecnologa, Estndares y Conectividad

Resumen
El objeto del presente trabajo es analizar cmo la sociedad de la informacin tiene un rol primordial para resolver la
problemtica actual en la integracin de aplicaciones, que no es solo econmica sino conceptual y estructural, para
ello intentar por un lado una aproximacin sumaria a la teora del pensamiento complejo en relacin al concepto de
organizacin sistemas y sub-sistemas interdependientes y la comunicacin transformada en informacin como
elemento complejo, que acelera los procesos de negentropa de los sistemas-organizaciones evitando de esta manera
la entropa de los mismos y por el otro las capacidades actuales del estado de la tecnologa como elemento clave en
la sociedad de la informacin y en particular asociado a los estndares de integracin de aplicaciones promovidos por
OASIS.

Cambio de Paradigma: Globalizacin y Sociedad de la


Informacin.
Estamos participando de un cambio de paradigma, de una transformacin de los criterios bsicos con los que
comprendemos la realidad: Durante muchos siglos se conocieron discursos (religiosos, culturales, polticos y
cientficos) que la pretendieron unificar; siempre se propuso una explicacin que redujera lo que sucede a un solo
principio: lo que Derrida llam logocentrismo y, en palabras de Gilles Deleuze, se podra denominar mono lgica.
La lgica virtual, la lgica informtica, la presencia de Internet, ya se est instalando como aquel criterio en el que se
disuelve toda idea de centro.
Cules son las caractersticas que podemos avistar del nuevo mundo? Por de pronto el debilitamiento de la idea de
verdad. De diversos modos, segn la disciplina que se trate, la suposicin de que existen verdades inamovibles, cede
paso a la admisin de la eficiencia. A su vez la eficiencia se admite siempre dentro de un paradigma, que no es prueba
de verdad si no que funciona dentro de lo que est preparado para resolver. Otra de las cosas que ha variado es la
idea de deber. La vieja tica que supona verdades absolutas ha cedido paso a una ms abierta, ms difusa, que slo
reconoce valores dentro de los campos en los que funciona.
Puede decirse que el mundo occidental actual est viviendo no slo profundos cambios sino que se est instalando la
inestabilidad (aunque suene una paradoja) Cada vez ms se va advirtiendo que no hay leyes, sino reglas de juego. Lo
que antes era comprendido y experimentado como deber ser, hoy se va desplazando al poder ser. Se esta pasando
de la fijeza de un ser idntico y estable a un acontecer que se muestra como fluir. De este modo, nada de lo que es,
est obligado a ser sino que slo es una posibilidad. Esto abre el mundo a un tipo de actitud. Ahora sabemos que nada
es fijo (y no porque maana pueda cambiar) sino que hoy mismo ya no lo es, lo que nos exige una gran flexibilidad.
Este es, ni mas ni menos, el pasaje del deber ser al poder ser.
Las sociedad del siglo XXI no es ya un paradigma ideolgico puede en realidad concebirse como varios sistemas que a
su vez cada uno de ellos est integrado por varios otros sub-sistemas y todos ellos conforman organizaciones
complejas que interaccionan entre s y que son permanentemente modificadas y reorganizadas por estas interacciones
que las someten a todas a un sistema organizacin mayor que podra llamarse Organizacin Socio Poltica que no
es ms que un todo de las partes, abriendo paso al concepto holstico de sistema. A su vez estas partes sistemas

Informe de Tesina

Proyecto Switch Transaccional Pgina 11 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

conforman distintas organizaciones que interactan e interaccionan entre si y con la Organizacin Global. As en el
sistema, cada interaccin, cada contrato, cada accin impacta en el todo y cada una de las partes como un todo.
La unidad menor de este sistema y objeto mayor es el hombre, organizacin a su vez biolgica-cultural que integra los
sistemas y sub-sistemas sociales, econmicos, polticos, culturales etc. y que es tambin permanentemente,
interactuado por fenmenos directos, indirectos y emergentes o sumergentes de los mismos. Por ejemplo su salud
como su calidad de vida, estarn ntimamente ligados a su sistema biolgico, cultural, social, poltico, econmico,
ecolgico, medio ambiente etc. y las interacciones de cada uno de estos, ms sus propios comportamientos como
interactuante, receptor, generador y modificador de los mismos.
Por otra parte algunos de estos individuos son integrantes de sub-sistemas de las distintas organizaciones. Su visin
del problema y su resolucin ser diferente porque de acuerdo a su ubicacin y su situacin sus determinaciones sern
distintas.
Conectividad (Internet), intercambio de informacin, interaccin de las partes e interoperabilidad, tableros de
comando, monitoreo y seguimiento de polticas, sern el desafo tecnolgico del futuro que garantizar una mejor
calidad de vida al hombre asegurando una mejor utilizacin de los recursos econmicos, profesionales, logsticos,
culturales y sociales disponibles dentro de cualquier tipo de organizacin poltica y garantizando el equilibrio entre
todas las partes tanto pblicas como privadas, equilibrando sus contradicciones y potenciando sus cualidades.
Obligando al uso racional de la informacin y a reducir la brecha sobre el conocimiento que existe actualmente.
La informacin que intercambien las partes ser en algunos casos determinante de acciones de distinto tipo por cada
uno de los actores y los sistemas que integran. Pero en la medida que esta informacin circule como una unidad entre
las partes y las acciones que determinen puedan ser monitoreadas y cuantificadas y su resultado dimensionable en
calidad de vida, garantas jurdicas y viabilidad de aplicacin, econmica, cultural, social etc. el sistema tender a la
fortificacin y cada una de las partes se beneficiar, pero de continuar por el camino en que estn hoy los sistemas de
informacin, la entropa es inevitable y la consecuente disolucin o dispersin de cada uno de los sub-sistemas
tambin.
Este es el gran desafo de la tecnologa y el nico camino que tienen por seguir aquellos que estn solo interesados en
mejorar la calidad de vida del hombre y sus organizaciones y sistemas.

La (in)evolucin de los sistemas de informacin.


La problemtica en la generacin y obtencin de informacin de los sistemas de informticos y organizacionales, no es
nueva. De hecho el empeo puesto en los procedimientos y procesos orientados a garantizar el correcto
funcionamiento tanto administrativo, econmico y de procedimientos administrativos ha sido indispensable para
garantizar el funcionamiento de las organizaciones.
Esta problemtica inclusive es anterior a la implementacin de estos procesos en medios electrnicos. Justamente la
evolucin tecnolgica y el afn de ordenamiento en la administracin de la informacin son en parte los causantes de
las deficiencias actuales en la administracin de la informacin. En un afn de las empresas de tecnologa de
insertarlas en los distintos mbitos de las organizaciones, han derivado en el des-concepto que era ms importante la
tecnologa que el procedimiento y la informacin, perdiendo de vista para qu se desarrollaban esas nuevas
tecnologas, diluyendo el centro verdadero que es el hombre.
La cantidad de actores del los distintos sistema y sub-sistemas organizacionales y los distintos intereses han
predominado frente al bien comn.
La evolucin en los sistemas de informacin ha ido de lo operacional administrativo-econmico a la utilizacin de
tcnicas ms avanzadas de sistematizacin centrando la problemtica en las interacciones y flujos de informacin que
sucedan en el mbito de las organizaciones.
Consecuencia de este desorden ha producido los siguientes inconvenientes:
Mltiples repositorios de datos.
Circuitos y procedimientos administrativos orientados y alineados con los sistemas informticos. Las
organizaciones alineadas al servicio de los sistemas de informacin y no al revs.

Informe de Tesina

Proyecto Switch Transaccional Pgina 12 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Inexistencia de centros codificadores (vocabularios, glosarios e identificadores).


Falta de patrones de diseo de sistemas informticos transaccionales. Modelos de datos y atributos comunes:
Lenguaje comn.
Integracin de aplicaciones punto a punto, propietarias y especficas para dicha integracin.
Falta de estndares y de polticas de administracin e intercambio de informacin.
La falta de interpretacin de los requerimientos y de las reglas de negocio por parte de las reas de tecnologa ha
desembocado en una puja con viso de soberbia entre los generadores de las polticas y los responsables de
implementarlas tecnolgicamente.
Por otra parte el crecimiento en la produccin de informacin ha desembocado en la postura de los mismos
organismos a no compartir la informacin producida. Muchas veces la actitud ha sido provocada por la falta de
controles y normas de seguridad en el intercambio de informacin y otras lisa y llanamente por el poder que da contar
con cierta informacin mientras no sea pblica.
Por lo tanto entender la controversia determinada por la gran cantidad de actores en el sistema y los distintos
intereses de los mismos ha frenado o cuanto menos lentificado la evolucin en la produccin de informacin
neguentrpica clave para evolucionar hacia la sociedad de la informacin.

Democratizar la Informacin.
Las comunicaciones favorecen el intercambio y la interaccin democrtica de la informacin, permitiendo si se utiliza
correctamente, sinergia y crecimiento entre las distintas partes y actores que acceden a ella, eliminado,
probablemente, intereses particulares de las partes. Compartir y regular la informacin permite auditar y controlar las
actividades de los distintos actores de los sistemas y organizaciones.
La tecnologa y las comunicaciones son el factor impulsor de este intercambio. La capacidad de los distintos sistemas
que procesen dicha informacin, permitir implementar procedimientos cualitativamente superiores, debido al acceso a
dicha informacin y a la posibilidad de interactuar en lnea sobre los diversos sucesos de los sistemas interactuantes.
Los sistemas y los actores deben alimentarse del flujo de informacin para trabajar con ella en todos los niveles. Cada
parte tomar de la informacin circulante lo que necesita para aprender y crecer. Este crecimiento y la interaccin de
los actores mantendrn en equilibrio el sistema de informacin y permitir mejorarlo.
En este sentido el trabajo interdisciplinario y multidisciplinario es clave para enriquecer los servicios que prestan las
organizaciones brindados en todos los niveles.
Actualmente el crecimiento exponencial en el uso de Internet y el acceso a herramientas y comunicaciones cada vez
ms econmicas y accesibles, permiten suponer que lograr sinergia de informacin entre los sistemas y sus sub-
sistemas posibilitando la neguentropa ser una realidad posible.
En este sentido, es clave, la integracin geogrfica de todos los actores y sus sistemas de informacin, logrando
transformar un modelo fsico de lejana geogrfica, en un modelo de informacin virtualmente sin distancias ni brechas
temporales.
De todas formas no se debe descuidar la gran debilidad que puede significar la utilizacin de tecnologa en pases en
vas de desarrollo como lo son los pases que integramos Latinoamrica. Ya que si hablamos de democratizar la
informacin, bajo ningn concepto debemos ni podemos hacer que la utilizacin de tecnologa no sea un recurso
sustentable.
Para ello es importante la participacin del estado en la regulacin y en la administracin de un crecimiento
homogneo y democrtico en la utilizacin de tecnologa y ms an en las polticas de acceso y distribucin de
informacin.

Informe de Tesina

Proyecto Switch Transaccional Pgina 13 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Sistemas organizacionales e interacciones.

ACTORES, ROLES Y NECESIDADES

Dentro de los distintos sistemas organizacionales, ya sean privados, pblicos o de gobierno, nos encontramos con una
gran cantidad de actores que necesitan intercambiar servicios e informacin. Estas operaciones estn sumamente
atomizadas, requiriendo la intervencin simultanea de los actores mencionados.
A dichas operaciones se agregan adems intereses contrapuestos y necesidades de control y contralor que lo hacen
mas complejo an.
Esta complejidad genera una gran cantidad de dialectos de comunicacin entre las partes, provocando el clsico
telfono descompuesto. Debido esto, normalmente, a reglas de interpretacin poco claras. Donde el principal
damnificado es el hombre, donde normalmente es sometido a largas esperas y en algunos casos re-hacer los trmites
y operaciones por dicha falta de interpretacin.
Es por ello que la alta interoperabilidad de dichos servicios e informacin requiere de una interpretacin precisa de lo
que se solicita como servicio y de lo que se pretende informar o recibir como informacin.
De aqu que la mayor necesidad de las organizaciones y actores intervinientes sea la definicin de estndares de
servicios y comunicaciones que garanticen o por lo menos minimicen la posibilidad de confusiones y malas
interpretaciones en el intercambio de informacin.
Esta situacin no es menor si tenemos en cuenta que muchos de los servicios propuestos tienen una criticidad muy
alta, como puede ser por ejemplo la correcta identificacin de una persona como paciente en un hospital y el acceso a
su historia clnica centralizada. Fallar en esta situacin podra en algunos casos provocar la muerte del paciente por
falta o mala interpretacin de la informacin requerida.

SISTEMAS E INTEROPERABILIDAD

La sociedad y su sistema de organizacin social, requiere que sus organizaciones, ya sean privadas, semi pblicas o
pblicas interaccionen tanto con los ciudadanos (en cualquiera de sus roles) como con otras organizaciones.

Contexto Social de interacciones

Informe de Tesina

Proyecto Switch Transaccional Pgina 14 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Los ciudadanos estn ligados a distintos organismos y organizaciones por diversos motivos dentro de sus
obligaciones y derechos. Tambin estn vinculados a organizaciones privadas o semi-publicas por motivos de
distinto grado de pertenencia de acuerdo a sus inclinaciones, actividades sociales y profesionales.
As un maestro est ligado a la escuela e indirectamente al ministerio de educacin.
Un paciente, est ligado al sistema de salud: hospitales, centros de atencin Obra social o pre-paga.
Un ciudadano est vinculado a los gobiernos municipales, provinciales y nacionales debido a sus obligaciones.
El nexo comn es la sociedad en si misma.
El factor impulsor es la organizacin de dicha sociedad con sus actividades, sociales, econmicas y las
obligaciones y derechos de los ciudadanos y actividad privada (empresas y organizaciones).
El estado est obligado a supervisar y ordenar todas las actividades ejecutadas dentro de una sociedad.
Todos los integrantes de dicha sociedad tienen un alto nivel de interdependencia.
En la figura presentada a continuacin se puede apreciar un ejemplo solamente para el rea de salud

Claramente se puede observar el nivel de interoperabilidad, dependencia y atomizacin que nos llevan a concluir el
siguiente diagnstico:
Sistema atomizado con muchos intermediarios.
Industria de informacin intensiva.
Gastos transaccionales y operacionales elevados con tendencia a la ineficiencia.
Situacin econmico / financiera comprometida.
Falta de polticas integrales y estndares.
Escasa inversin en tecnologa.
Es importante destacar el rol central que tienen los factores econmicos dentro de esta interoperabilidad y el papel
preponderante que juegan las organizaciones financiadoras y el gobierno como factores de equilibrio entre calidad y
distribucin de las prestaciones.

Informe de Tesina

Proyecto Switch Transaccional Pgina 15 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

La evolucin de los sistemas sociales hace pensar que estamos frente a una problemtica de demanda infinita y
recursos limitados y es aqu donde estas organizaciones tienen la responsabilidad de administrar y distribuir en toda la
poblacin el derecho y acceso a la informacin y un equilibrio entre las actividades desarrolladas en una sociedad.

Organizaciones dedicadas a la interoperabilidad

OASIS
OASIS, acrnimo de (Organization for the Advancement of Structured Information Standards) es un consorcio
internacional sin fines de lucro que se orienta al desarrollo, consenso y adopcin de estndares para el intercambio
de informacin entre aplicaciones (e-Business, e-Government).
Los miembros del consorcio deciden cmo y qu trabajos se deben emprender a travs de un proceso abierto y
democrtico.
Los trabajos tcnicos abarcan las siguientes categoras: Adoption Services, Computing Management, Document-Centric
Applications, e-Commerce, Law & Government, SOA, Standards Adoption, Web Services, XML Processing.

HISTORIA:
OASIS fue fundada inicialmente en 1993 como una asociacin comercial, denominada SGML Open, para promover la
adopcin del estndar SGML. Principalmente mediante el desarrollo de actividades educativas, incluyendo tambin
actividades tcnicas como el intercambio de especificaciones en organizaciones administrativas.
En 1998, con el apogeo de XML en TI, SGML cambio su enfoque de SGML a XML, y cambio su nombre a OASIS. El
rea de inters del consorcio abarca desde promociones de adopcin de estndares hasta el desarrollo de
especificaciones tcnicas de los mismos. En julio del 2000 se creo un nuevo comit tcnico. En la actualidad hay cerca
de 70 comits.
Durante 1999 OASIS se reuni con la UN/CEFACT, el comit de las Naciones Unidas para negociar los estndares de
negocios, para que conjuntamente se desarrollen nuevas normas y estndares para el intercambio de informacin
electrnica. La junta inicial se la llamo ebXML y se reunieron por primera vez en Noviembre de 1999, fue establecida
por un periodo de 3 aos. En la reunin final bajo los primeros estatutos, en Viena, UN/CEFACT y OASIS coincidieron
en dividir el trabajo en las dos organizaciones y coordinar la finalizacin de los trabajos en comits especficos. En
2004 OASIS propuso la especificacin de ebXML a la ISO TC154 donde fue aprobada como la ISO 15000.
Algunos de los estndares desarrollados por OASIS:
DITA (OASIS Darwin Information Typing Architecture) es un modulo portable y extensible basado en el lenguaje
XML para temas bsicos como ayuda on-line, documentacin de proyectos, asesoramientos y capacitacin.
OpenDocument (OASIS Open Document Format for Office Applications) es un formato de documento abierto
para el respaldo de documentos de oficina tales como documentos de texto, planillas de clculo, presentaciones,
memos, y grficos.
SAML (Security Assertion Markup Language) es un estndar basado en XML para la seguridad en el intercambio,
autenticacin y autorizacin de informacin.
XRI (eXtensible Resource Identifier) es un esquema compatible con URI y un protocolo de resoluciones usado
por identificadores abstractos para la identificacin y intercambio de recursos a travs de dominios y
aplicaciones.
XDI (XRI Data Interchange) es un estndar para el intercambio, interconexin y sincronizacin de datos
(dataweb) mediante el uso de mltiples dominios y aplicaciones usando documentos XML (XRIs, eXtensible
Resource Identifiers) y nuevos mtodos distribuidos de control de datos llamados linkContract.

Informe de Tesina

Proyecto Switch Transaccional Pgina 16 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

LegalXML es un estndar para el intercambio de informacin legal y jurdica entre todas las partes del sistema
judicial.
EL consorcio es de carcter internacional y por lo tanto crea las normas para un mercado internacional. Con la oficina
principal en Estado Unidos de Amrica, el consorcio tiene la representacin corporativa en Europa y Asia, y
participacin activa de miembros en los cinco continentes.
Los miembros incluyen:
1. Usuarios que buscan asegurar sus requisitos comerciales.
2. Agencias gubernamentales que quieren minimizar la superposicin de normas y reducir el riesgo de la
nueva tecnologa.
3. Los proveedores de software impulsando la cooperacin de la industria a travs de normas y estndares.
Adems ofrece un rango de niveles de miembros para los usuarios y vendedores, gobiernos y universidades, grupos de
comercio y proveedores de servicios.
Los archivos de los Comits Tcnicos de OASIS, documentos y los correos electrnicos son pblicamente accesibles
incluso para los no-miembros y pueden ser supervisados y mejorados abiertamente.
OASIS se caracteriza por su gobierno y su forma de operacin. Los mismos miembros fijan la agenda tcnica, usando
un proceso sencillo diseado para promover el consenso en la industria y para unir esfuerzos dispares. Los trabajos
completados son debatidos mediante el voto abierto (Ballot). Los funcionarios de la Junta Directiva de OASIS y la
Junta Asesora Tcnica son escogidos por eleccin democrtica para servir por el trmino de dos aos. La Direccin del
consorcio esta basada en el mrito individual y no en su contribucin financiera, situacin corporativa o cita especial.
OASIS mantiene participacin y relaciones con algunas de siguientes organizaciones:
W3C
ISO
ISO/IEC JTC1
ITU
UNECE
RosettaNet
Y muchas otras...

HL7
HL7 (Health Level Seven) es una organizacin sin fines de lucro que desarrolla estndares para minimizar las
incompatibilidades entre sistemas de informacin en salud, permitiendo la interaccin y el intercambio productivo de
datos entre aplicaciones heterogneas, independientemente de su plataforma tecnolgica o de su lenguaje de
desarrollo.
Diferentes sectores: prestadores de servicios de salud, desarrolladores de software, consultores, usuarios finales,
organizaciones gubernamentales y no gubernamentales; participan en forma colaborativa en la discusin y en el
desarrollo de estndares por consenso, en un entorno abierto. Estos estndares ofrecen un marco que permite a los
diferentes sistemas de informacin, comunicarse a travs de mensajes estandarizados que viajan por una nica
interfaz.
Se trata de una iniciativa que comenz en 1987, en base a la necesidad de normalizar las interfaces entre los mltiples
sistemas heterogneos de informacin, y rpidamente se convirti en el estndar de facto para el intercambio
electrnico de datos clnicos y administrativos en los servicios de salud de los Estados Unidos.
La amplia difusin de los estndares desarrollados, dio origen en los ltimos aos a filiales internacionales (Canad,

Informe de Tesina

Proyecto Switch Transaccional Pgina 17 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Australia, China, Finlandia, Alemania, India, Japn, Corea, Holanda, Nueva Zelanda, Sudfrica, Reino Unido, Argentina,
Brasil, para mencionar solo algunos), y a un comit internacional, que permite armonizar y discutir las necesidades
locales de adaptar los estndares en distintas partes del mundo.
La estructura internacional de la organizacin, el procedimiento de votacin balanceado, y las polticas abiertas de
asociacin, aseguran que todos los requerimientos sean tenidos en cuenta uniformemente y equitativamente con
calidad y consistencia. Adems todas las organizaciones HL7 y sus desarrollos, estn reconocidas en Estados Unidos
por el instituto ANSI (American National Standards Institute) y por la SDO (Standards Developing Organization).

Tecnologas necesarias.
La tecnologa por si misma no podra modificar absolutamente nada dentro de la sociedad de la informacin. Esta es
solamente el soporte, la infraestructura necesaria para que las comunidades que la utilizan construyan a partir de ella.
En este sentido las comunidades internacionales estn dando ejemplo que la construccin cooperativa de sistemas es
posible.
Claramente el ejemplo ms contundente lo ha dado la misma comunidad que desarrolla y promueve los estndares
mencionados anteriormente.
Otro ejemplo contundente y adems basado en el concepto de componentes distribuidos lo ha dado la comunidad
Java a travs de la especificacin JEE (Java Enterprise Edition) y sin duda el esfuerzo mayor lo han dado las mismas
empresas de tecnologa mediante la voluntad de crear en Internet estndares que permitan la integracin de cualquier
sistema independientemente de su plataforma mediante la utilizacin de XML y Web Services.

SOA

DEFINICIN.
SOA es la sigla que en ingles representa a Service Oriented Arquitectura (Arquitectura Orientada a los servicios).
Bsicamente la arquitectura propuesta es un nuevo paradigma dentro de las ciencias informticas que permite
organizar y utilizar distintas capacidades distribuidas (servicios) ofrecidos por distintos actores (personas y/u
organizaciones) a lo largo de Internet.
Esta arquitectura toma mas fuerza gracias al surgimiento del concepto de Web Services (servicio Web) que se
explicar ms adelante.
Hasta ahora, la mayora de las discusiones sobre SOA, giraban en torno a temas sobre la integracin de sistemas
dispares, el aprovechamiento de las Bases de Datos existentes en una organizacin o la creacin de una arquitectura
robusta. Si bien todos estos temas son relevantes para SOA, existen otros temas significativos e interesantes
relacionados con SOA que merecen atencin. Para lograr su objetivo de conectar sistemas heterogneos y autnomos,
SOA se adhiere a varios principios de diseo esenciales. Uno de los principios mantiene que la existencia de servicios
independientes implica la presencia de partes de cdigo y datos interconectados mediante mensajera.
Es ms, los servicios estn ntimamente vinculados a la mensajera ya que el nico camino de entrada y salida de un
servicio es a travs de mensajes. No obstante, los servicios seguirn funcionando de forma independiente de los
dems.
Por lo tanto SOA proporciona una metodologa y un entorno de trabajo para documentar capacidades de negocio y
puede dar soporte a las actividades de integracin y consolidacin entre organizaciones.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios
independientes a los que tienen acceso de un modo estandarizado. La mayora de las definiciones SOA identifican la
utilizacin de Servicios Web (empleando SOAP y WSDL) en su implementacin, no obstante se puede implementar
SOA utilizando cualquier tecnologa basada en servicios.

Informe de Tesina

Proyecto Switch Transaccional Pgina 18 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Nube se Servicios

Al contrario de las arquitecturas orientadas a objetos, SOAs est formada por servicios de aplicacin dbilmente
acoplados y altamente interoperables. Para comunicarse entre s, estos servicios se basan en una definicin formal
independiente de la plataforma subyacente y del lenguaje de programacin (por ejemplo WSDL. Ver Web Services ms
adelante). La definicin de la interfaz encapsula (oculta) las particularidades de una implementacin, lo que la hace
independiente del fabricante, del lenguaje de programacin o de la tecnologa de desarrollo (como Java o .NET). Con
esta arquitectura, se pretende que los componentes de software desarrollados sean muy reusables, ya que la interfaz
se define siguiendo un estndar; as, un servicio C Sharp podra ser usado por una aplicacin Java.
Dos ejemplos de soluciones comerciales SOA seran "Java Enterprise System" de Sun Microsystems y "Connected
Services Framework" (BizTalk Server + SQL Server + Windows Server + .NET Framework) de Microsoft.
Los lenguajes de alto nivel como BPEL (ver mas adelante) llevan el concepto de servicio un paso adelante al
proporcionar mtodos de definicin y soporte para flujos de trabajo y procesos de negocio.

EL CAMBIO HACIA LOS SERVICIOS

Uno de los problemas de SOA se encuentra en los servicios independientes que requieren la presencia de partes de
cdigo y datos, y en los servicios de interconexin de mensajes. Cada servicio es una coleccin nica de cdigo y
datos que es autnoma e independiente de los dems servicios. No obstante, cada servicio est interconectado con
otros servicios a travs de la mensajera.
La mensajera tiene una importancia enorme en SOA. Los mensajes se envan entre servicios y flotan entre ellos. La
definicin de esquema para cada mensaje y el contrato que define el flujo de los mensajes especifican el
comportamiento de "caja negra" del servicio. Los servicios estn vinculados a la mensajera ya que el nico camino de
entrada y salida de un servicio es a travs de mensajes. Un servicio asociado slo est pendiente de la secuencia de
los mensajes que fluyen de un lado a otro.
A veces, se envan muchos mensajes relacionados entre dos servicios distintos. Estos dos servicios pueden
intercambiar mensajes durante un perodo de semanas o meses.

Informe de Tesina

Proyecto Switch Transaccional Pgina 19 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Transmisin de Servicios (Mensajes) encadenados y dependientes

Los servicios son el centro de atencin del proceso evolutivo. Los servicios proporcionan una manera de establecer una
divisin granular de mayor tamao y con ms independencia entre los fragmentos de cdigo que las funciones y los
componentes. En primer lugar, los servicios siempre interactan entre s mediante mensajes. En segundo lugar,
normalmente son duraderos, lo que les permite sobrevivir cuando el sistema presenta un error o se reinicia. Por
ltimo, los servicios tienen entornos de implementacin opacos en los que desde el exterior slo es posible ver las
interacciones de los mensajes.

Estructura de Servicios y Componentes

DEFINICIONES SOA
W3C (World Wide Web Consortium): Conjunto de componentes que pueden ser invocados, cuyas descripciones
de interfaces se pueden publicar y descubrir
CBDI (Service Oriented Architecture Practice Portal) rechaza esa definicin:
Los componentes pueden no ser conjuntos. La definicin slo considera los componentes y no la prctica o el
arte de construir la arquitectura. Por lo tanto presenta la siguiente definicin:
Estilo resultante de polticas, prcticas y frameworks que permiten que la funcionalidad de una aplicacin se
pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor.
Los servicios pueden invocarse, publicarse y descubrirse y estn abstrados de su implementacin utilizando
una sola forma estndar de interfaz.

Informe de Tesina

Proyecto Switch Transaccional Pgina 20 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Infraestructura de alto nivel basada en best practices y patrones para crear soluciones basadas en servicios, de
alta cohesin y bajo acoplamiento (Geniant).
Estilo arquitectnico apto para implementar bajo acoplamiento entre agentes. Los agentes son proveedores y
consumidores de servicios, que son la unidad de trabajo. (Hao He).
Una arquitectura de aplicacin en la cual todas las funciones se definen como servicios independientes con
interfaces invocables bien definidas, que pueden ser llamadas en secuencias definidas para formar procesos de
negocios (IBM).
MITRE (System Engineering and Advanced Technology to Critical National Problems):
Una aplicacin SOA es una coleccin de servicios

Un servicio es la unidad atmica de una SOA

Los servicios encapsulan procesos de negocios

Los proveedores de servicios se registran solos

Un servicio involucra: Find, Bind, Execute

Las instancias ms conocidas son los Web services

Gartner:
SOA es una arquitectura de software que comienza con una definicin de interfaz y construye toda la topologa
de la aplicacin como una topologa de interfaces, implementaciones y llamados a interfaces. Sera mejor
llamada arquitectura orientada a interfaces. SOA es una relacin de servicios y consumidores de servicios,
ambos suficientemente amplios para representar una funcin de negocios completa.

Comportamiento SOA

WEB SERVICES
Un servicio Web es una coleccin de protocolos y estndares que sirve para intercambiar datos entre aplicaciones.
Distintas aplicaciones de software desarrolladas en lenguajes de programacin diferente y ejecutada sobre cualquier

Informe de Tesina

Proyecto Switch Transaccional Pgina 21 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

plataforma pueden utilizar Web Services para intercambiar mensajes (servicios) en redes como Internet. La
interoperabilidad se consigue mediante la adopcin de estndares abiertos. OASIS y W3C son los comits responsables
de la arquitectura y reglamentacin de los Web Services.
Los Web Services, garantizando el uso de estndares en la tecnologa subyacente utilizada, permiten el gran
crecimiento del concepto SOA en la actualidad. Ya que los Web Services permiten independizarse de la plataforma y
de los lenguajes de programacin a ser utilizados.
Los Web Services, no son por lo tanto aplicaciones con una interfaz grfica con la que las personas puedan
interactuar, sino que son un conjunto de especificaciones de software accesible en Internet (o en redes privadas que
usen tecnologas Internet) por otras aplicaciones. De esta forma podemos desarrollar aplicaciones que hagan uso de
otras aplicaciones que estn disponibles en Internet.
Un tpico ejemplo podra ser un Web Service al que se le pudiese preguntar por una empresa y que nos retornase en
tiempo real el valor al que estn cotizando las acciones de dicha compaa.
De esta forma cualquier aplicacin (ya sea Web o de escritorio) que quiera mostrar esta informacin slo tendra que
solicitarla a travs de Internet al Web Service cuando la necesitase.
Otro ejemplo podra ser uno que al pasarle el nombre de una ciudad, nos devolviese la temperatura, humedad, y otras
condiciones de clima.

ESTNDARES EMPLEADOS

1. Web Services Protocol Stack: As se denomina al conjunto de servicios y protocolos de los servicios Web.
2. XML (eXtensible Markup Language): Es el formato estndar para los datos que se vayan a intercambiar.
3. SOAP (Simple Object Access Protocol) o XML-RPC: Protocolos sobre los que se establece el intercambio.
4. Otros protocolos: los datos en XML tambin pueden enviarse de una aplicacin a otra mediante protocolos
normales como HTTP, FTP, o SMTP.
5. WSDL (Web Service Definition Language ): Es el lenguaje de la interfaz pblica para los servicios Web. Es
una descripcin basada en XML de los requisitos funcionales necesarios para establecer una comunicacin
con los servicios Web.
6. UDDI (Universal Description, Discovery, and Integration): Protocolo para publicar la informacin de los
servicios Web. Permite a las aplicaciones comprobar qu servicios web estn disponibles.
7. WS-Security: Protocolo de seguridad aceptado como estndar por OASIS. Garantiza la autenticacin de los
actores y la confidencialidad de los mensajes enviados.

Funcionamiento Bsico de un Web Service

Informe de Tesina

Proyecto Switch Transaccional Pgina 22 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Tecnologas usadas en la Arquitectura de Web Services

BPM - ORQUESTACIN DE SERVICIOS


Otro punto importante a tener en cuenta dentro de la mensajera en general y el uso de XML en particular es la
necesidad de construir adaptadores que nos permitan integrar dichas aplicaciones. Sin estos adaptadores no
podramos comunicar una aplicacin que habla un idioma X con otra que habla un idioma Z, para ello son
fundamentales lo que en la arquitectura se denominan parsers.
Conjuntamente con los parsers se debe contar con un proceso que nos permita coordinar esta interaccin entre
partes. Ya que muchas veces cuando hablamos de Web services no nos limitamos solamente al uso de un servicio
sencillo sino a la ejecucin distribuida de aplicaciones complejas. Como solucin y componente fundamental veremos
que los lenguajes de Proceso o como se denominan normalmente BPM (Business Process Modeling) permiten
estandarizar y orquestar una relacin compleja entre servicios y proceso.
Dentro de una arquitectura SOA usando Web services correctamente orquestados se debe pensar seriamente en
intermediarios que permitan la correcta distribucin de mensajes y aplicacin de procesos y reglas de negocio.
Tambin a estos intermediarios se los suele denomina HUB o Switch de integracin de aplicaciones. Un ejemplo de ello
es lo implementado por el HIPPA (Health Insurance Portability & Accountability Act) que ha regulado la
implementacin de lo que ha denominado como Clearing Houses que tienen la responsabilidad de administrar
mensajes, solicitudes y reclamaciones entre asegurados, aseguradoras y hospitales y clnicas dentro de USA.

Informe de Tesina

Proyecto Switch Transaccional Pgina 23 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Elementos para la Orquestacin de servicios

Para tener una mayor comprensin del significado de la mencionada coordinacin, veremos distintas topologas de
coordinacin (orquestacin) para transacciones y mensajes entre servicios:
1. Relacin Binaria: El contexto y la actividad estn implcitas en cada servicio, logrando de esta forma un criterio
de auto-coordinacin.

Coordinacin Binaria

Informe de Tesina

Proyecto Switch Transaccional Pgina 24 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

2. Hub o Spoke: Relacin entre servicios coordinados por un concentrador de transacciones que tiene la
responsabilidad del intercambio como as las actividades de control, validacin, flujo de proceso y seguridad.

Coordinacin Hub o Spoke

3. Punto a punto en Multigrupo: Existe un coordinador que auspicia de rbitro entre las partes, pero tanto el
contexto como las actividades son explcitas pero dependientes de cada servicio. Este esquema es una
solucin mixta entre el esquema concentrador y el distribuido punto a punto.

Coordinacin Multigrupo

Informe de Tesina

Proyecto Switch Transaccional Pgina 25 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Arquitectura de un Coordinador

Actualmente se encuentran disponibles varios lenguajes estndar de orquestacin y especificacin de procesos entre
los que podemos encontrar:
1. XLANG - XML Business Process Language.
2. BPML - Business Process Modeling Language.
3. BPSS Business Process Specification Schema.
4. WSFL - Web Services Flow Language.
5. WSCL Web Services Conversation Language.
6. WSCI - Web Service Choreography Interface.
7. BTP - Business Transaction Protocol.
8. WS-BPEL Web Services Business Process Execution Language.
9. WS-C, WS-T, WS-AT, WS-BA (Coordination, Transaction).
10. BPMN - Business Process Modeling Notation.
De los lenguajes mencionados anteriormente el que se est imponiendo es WSBPEL, ya que siendo originalmente
desarrollado e impulsado por BizTalk e IBM ha sido cedido a OASIS para que forme parte de los estndares que esta
organizacin administra. Este impulso inicial adems ha sido reforzado fuertemente por compaas como Oracle, BEA,
OpenStorm y Microsoft.

Informe de Tesina

Proyecto Switch Transaccional Pgina 26 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

BPEL adems de ser compatible SOA y Web Services, soporta otros tipos de procesos como Java y JCA e incorpora las
especificaciones de WS-Security, lo que lo convierte en un lenguaje de procesos robusto.

En resumen en el siguiente grfico podemos ver la arquitectura completa para realizar una correcta integracin de
aplicaciones y procesos distribuidos.

Informe de Tesina

Proyecto Switch Transaccional Pgina 27 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Resumen de Arquitectura SOA

ESTNDARES SOA

XML
XML (Extensible Markup Language) es un lenguaje extensible de etiquetas, desarrollado por el World Wide Web
Consortium (W3C).
Se propone como un estndar para el intercambio de informacin estructurada entre diferentes plataformas. Permite
compartir la informacin de una manera segura, fiable y sencilla.
Es un subconjunto de SGML (Standard Generalized Markup Language, lenguaje de marcado generalizado estndar), y
su objetivo es permitir el uso de SGML en Internet, de modo que un documento escrito en XML sea servido, recibido y
procesado de la misma manera que un documento HTML. Si bien es una forma restringida de SGML, preserva una
buena parte de su potencial y riqueza, e incluye sus caractersticas ms utilizadas. Fue diseado para que fuera fcil
de implementar, y para interoperar tanto con SGML como con HTML.
El SGML es un lenguaje para describir lenguajes de marcado, particularmente aquellos utilizados en intercambio,
manejo y publicacin de documentos electrnicos. Surgi a mediados de los '80 y se ha mantenido bastante estable.
Gran parte de su estabilidad se debe a que es un lenguaje rico y flexible. Esta flexibilidad, sin embargo, hace que
tenga un alto nivel de complejidad, lo cual impide que pueda utilizarse en varios entornos, incluyendo la Web. Este
lenguaje permite definir la gramtica de lenguajes especficos para diferentes necesidades.
Los objetivos al disear XML fueron:
1. Que fuera directamente utilizable en Internet.
2. Que soportara una amplia variedad de aplicaciones.
3. Que fuera compatible con SGML.
4. Que fuera sencillo escribir programas que procesaran documentos XML.
5. Que la cantidad de caractersticas optativas fuera mnima, en lo posible cero.

Informe de Tesina

Proyecto Switch Transaccional Pgina 28 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

6. Los documentos XML deban ser legibles a nivel humano y razonablemente claro.
7. El diseo de XML deba prepararse rpidamente, ser formal y conciso.
8. Los documentos XML deban ser fciles de crear.
9. Lograr etiquetas concisas sera lo menos importante.
Ventajas del XML:
1. Comunicacin de datos. Permite la transferencia de informacin en texto plano, con formato XML, entre
aplicaciones diferentes.
2. Migracin de datos. Facilita un lenguaje intermedio para escribir los datos de una aplicacin a otra diferente,
por ejemplo para intercambio entre diferentes sistemas de bases de datos.
3. Aplicaciones Web. Una sola aplicacin maneja los datos y cada navegador aplica el estilo adecuado para
mostrarlos.
HTML fue pensado como un lenguaje de publicacin e intercambio de documentos tcnicos y cientficos. Resolva el
problema de la complejidad de SGML especificando un pequeo conjunto de etiquetas para edicin de documentos
relativamente simples. Adems de simplificar la estructura de los documentos, HTML agreg soporte para hipertexto.
Ms tarde se agregaran capacidades multimedia. En un breve lapso de tiempo, HTML se hizo muy popular, y
rpidamente super su propsito original. Desde su creacin, se han agregado nuevos elementos para incluir en el
estndar, y as adaptarlo a mercados ms especializados. Esta gran variedad de nuevos elementos trajo problemas
para operar con documentos entre diferentes plataformas.
En XML es relativamente sencillo introducir nuevos elementos o atributos de elementos. La familia XHTML fue
diseada para acomodar esas extensiones por medio de mdulos XHTML y tcnicas para desarrollar nuevos mdulos
compatibles con XHTML.
Tales mdulos permitirn la combinacin de nuevas caractersticas junto con las existentes.
Constantemente se introducen nuevas formas de acceso a Internet. La familia XHTML fue diseada pensando en la
interoperabilidad de agentes de usuario generales. Mediante un nuevo agente de usuario y un mecanismo de perfilado
de documentos, distintos servidores, proxies y agentes de usuario podrn intercambiar contenidos. Finalmente, ser
posible desarrollar contenido en formato XHTML utilizable por cualquier agente de usuario XHTML.
XHTML (Lenguaje de Marcado de Hipertexto Extensible) es una versin ms estricta y limpia de HTML. Surge con el
objetivo de remplazar a HTML ante su limitacin de uso con las cada vez ms abundantes herramientas basadas en
XML. XHTML extiende HTML 4.0, combinando la sintaxis de HTML, diseado para mostrar datos, con la de XML,
diseado para describir los datos.
XHTML surge como el lenguaje cuyo etiquetado, ms estricto que HTML, va a permitir una correcta interpretacin de
la informacin, independientemente del dispositivo desde el que se accede a ella. XHTML puede incluir otros lenguajes
como MathML, SMIL o SVG.
Beneficios
1. Los documentos XHTML son compatibles con XML. Como tales, pueden verse, editarse y validarse con
herramientas estndares de XML.
2. Los documentos escritos en XHTML son compatibles con los agentes de usuario (ejemplo, navegadores) para
HTML 4.
3. Los documentos XHTML pueden utilizar aplicaciones (por ejemplo scripts, o applets) basados en el modelo de
objetos de documento de HTML o en el modelo de objetos de documento (DOM) de XML.
4. A medida que la familia XHTML evolucione, los documentos basados en XHTML 1.0 podrn operar en y entre
varios entornos XHTML.

Informe de Tesina

Proyecto Switch Transaccional Pgina 29 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

SOAP
El protocolo SOAP (del ingls Single Object Access Protocol) define una estructura que permite el intercambio de
mensajes, como aquellos necesarios en un Servicio Web, a travs de una red, como por ejemplo Internet.
SOAP permite el intercambio de informacin en ambientes distribuidos y descentralizados. Esta basado en XML, y
define un framework de mensajera extensible, proveyendo un formato de mensajes que puede ser utilizado en una
amplia variedad de escenarios. Est diseado para ser independiente de cualquier modelo particular de programacin.
La especificacin original fue diseada por Microsoft e IBM. Actualmente se encuentra a cargo del XML Protocol
Working Group, del W3C.
Estructura de un mensaje
Un mensaje en formato SOAP se divide en dos secciones contenidas dentro de una envoltura ( envelope): un header
o cabecera y un Body o cuerpo.

Estructura de un mensaje SOAP

La envoltura es el elemento raz de un mensaje SOAP. Mediante este, un proceso que reconoce mensajes SOAP puede
identificarlos.
La cabecera cuenta con informacin destinada a los posibles intermediarios que se encuentren durante el viaje del
mensaje hacia su destinatario final, y es una seccin opcional que puede estar vaca. La funcin que cumple es la de
contener informacin de ruteo que le permita desplazarse por los diferentes intermediarios hasta llegar a su destino
final.
Mediante agregados a esta seccin, se puede expandir la funcionalidad de SOAP, por ejemplo agregando informacin
para identificacin, transacciones, etc.
El cuerpo aloja el contenido primario, o sea, la informacin relevante a la aplicacin o sistema, de inters para el
emisor y el receptor final. Puede tambin no contener informacin.
Un mensaje SOAP puede contener, adems, un attachment, que no necesariamente tiene que ser un documento XML:
una imagen, un documento de texto, etc.

Informe de Tesina

Proyecto Switch Transaccional Pgina 30 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Medios de Transporte
SOAP puede ser utilizado sobre varios medios de transporte, como HTTP o SMTP. Actualmente el medio ms utilizado
es HTTP, por su mayor aceptacin y mejor adaptacin a la infraestructura actual de Internet. SOAP puede operar sin
dificultades con firewalls, ya que estos por lo general liberan el puerto necesario para HTTP, o pueden reconocer un
mensaje SOAP (contenido del tipo text/xml-SOAP).
El uso de HTTP como medio de transporte se especifica mediante un HTTP Binding, en el cual se puede indicar el
mtodo de intercambio a utilizar (GET o POST).
El uso de SMTP nos permite incluir el mensaje SOAP en un correo electrnico.
La eleccin de XML como lenguaje para definir el mensaje se debe a la amplia aceptacin de este, y por su
caracterstica multiplataforma, la que se extiende as al protocolo SOAP. Tambin ofrece la ventaja de ofrecer una
sintaxis y estructura compresible para humanos.

Escenarios
El intercambio ms simple que puede ser representado es el patrn requestresponse, como por ejemplo el RPC
(Remote Procedure Call). SOAP es, de hecho, el sucesor del XML RPC.
Un conjunto mucho mayor de escenarios de uso puede ser definido como un intercambio de informacin basada en
XML, a travs de mensajes SOAP. De esta forma se conforma una conversacin entre aplicaciones o sistemas. La
semntica es definida a nivel de aplicacin, por lo cual SOAP es neutral al objetivo de estas.

Los mensajes SOAP son enviados y recibidos por clientes SOAP y servidores con servicios Web. El cliente genera y
enva, a travs de HTTP, un mensaje que es recibido y procesado por el servidor SOAP.

Debilidades
Debido al uso de mensajes XML largos, una solucin SOAP puede ser ms lenta que otra usando CORBA. Tambin se
ha nombrando como una limitacin el hecho de que se dependa del WSDL.
En el Anexo A se puede ver un ejemplo de formato de mensaje SOAP.

WSDL
A medida que la estandarizacin de los protocolos de comunicacin se extiende, la posibilidad de encarar exitosamente
una organizacin estructurada de las comunicaciones se convierte en una realidad. WSDL (del ingls Web Services
Description Language) es un estndar que permite encarar este objetivo ofreciendo descripciones de servicios.
WSDL permite describir la interfaz de un Servicio Web, y cmo debe ser ligado con una direccin de red.
Generalmente se utiliza en combinacin con SOAP para proveer servicios a travs de Internet. Cualquier programa
cliente que se conecte al Servicio Web puede determinar que funcionalidad esta disponible a partir del documento
WSDL asociado.
El estndar WSDL esta siendo desarrollado por el W3C.

Descripcin de un Servicio Web


La descripcin de la interfaz del servicio por parte de WSDL se puede dividir en:

Informe de Tesina

Proyecto Switch Transaccional Pgina 31 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

1. Definiciones
2. Operaciones
3. Service Bindings (Ligaduras de Servicios)
Las definiciones son expresadas, generalmente, en XML. Se encargan de definir los tipos de datos y mensajes
utilizados. El vocabulario XML empleado para las definiciones puede basarse en uno previamente acordado mediante
algn tipo de definicin estndar, o usarse uno especialmente definido si se planea un desarrollo para uso in-house.
Otros lenguajes pueden ser utilizados, como el IDL, aunque se opta por XML por ser el dominador del mercado. Para
asegurar un uso nico de nombres de elementos, definiciones, operaciones, etc, se utiliza un XML Namespace.
Mediante las operaciones se describe las acciones para los mensajes soportadas por el Servicio Web. Existen cuatro
tipos de operaciones:
1. De una va (one-way): mensajes que no necesitan una respuesta.
2. Pedido/Respuesta (request-response): el emisor enva un mensaje, y el receptor responde al recibirlo.
3. Solicitud de respuesta (solicit response): un pedido de respuesta (la definicin especifica an esta pendiente)
4. Notificacin (notificacin): envo de un mensaje a varios destinatarios (la definicin especifica an esta
pendiente)
De esta forma las operaciones indican un patrn de intercambio de uno o ms mensajes, indicando la cardinalidad,
tanto de mensajes enviados como recibidos, y quienes los enviaron y/o recibieron.
Finalmente, las operaciones son agrupadas en port types o interfaces. Las interfaces definen, entonces, el conjunto de
operaciones soportados por el Web Service.
Cabe notar que hasta el momento se ha llevado a cabo una definicin de funcionalidad en un sentido abstracto, sin
referirnos a ningn tipo de formato de transporte o plataforma subyacente. WSDL separa las anteriores definiciones de
los detalles concretos de su implementacin permitiendo la portabilidad y la reutilizacin de estas especificaciones.
El Service binding especfica la forma de conectar una interfase con un puerto o endpoint, definiendo una asociacin
con una direccin de red (por ejemplo, una URL) con dicha interfase. Describe cmo y donde acceder al Servicio Web,
por lo que se trata de una definicin a un nivel concreto. El servicio queda definido entonces a partir de una coleccin
de endpoints. El binding generalmente es creado utilizando SOAP, aunque otros protocolos para el pase de mensajes
pueden ser utilizados, como por ejemplo CORBA IIOP, DCOM, etc.

Significado de la descripcin de un servicio


Una descripcin de un Servicio Web utilizando WSDL indica como se espera que potenciales clientes interacten con el
servicio descrito. Es una declaracin de que el servicio Web implementa y adhiere a lo descrito el documento WSDL.
La interfaz definida, entonces, describe interacciones potenciales, no requeridas: la interaccin descripta no es
necesario que ocurra en absoluto, pero de llegar a ser iniciada, las operaciones describen como debe ocurrir.

UDDI
UDDI, acrnimo de Universal Description, Discovery and Integration, define un registro para negocios o entidades que
quieran dar a conocer en Internet sus servicios disponibles. As, UDDI es un Servicio Web que maneja informacin
sobre proveedores, implementaciones de servicios y datos adicionales sobre ellos. Esta basado en XML y es
independiente de cualquier plataforma. UDDI es otro de los estndares mantenidos por OASIS.
UDDI permite confeccionar un catalogo de negocios, permitiendo publicar listados de servicios y descubrir otros.
Tambin permite definir cmo los servicios o aplicaciones deben interactuar a travs de Internet. De esta manera los
proveedores de servicios Web pueden darse a conocer, y los potenciales clientes realizar bsquedas por servicios que
satisfagan sus necesidades.
La versin actual de UDDI es la V2.0 aprobada como un Estndar OASIS, y ya existen numerosos productos y servicios

Informe de Tesina

Proyecto Switch Transaccional Pgina 32 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

que la implementan. La versin V3.0 esta actualmente bajo desarrollo. Asimismo, UDDI es complementario con otros
proyectos de OASIS y el W3C, como ser SOAP, WSDL, WS-Security, etc.
La informacin que guarda un registro UDDI se puede dividir en un conjunto de categoras de datos simples:
1. Quin? (Who?) Informacin sobre el negocio o institucin. Nombre, identificacin, direccin de contacto,
etc.
2. Qu? (What?) Informacin de categorizacin (por ejemplo, cdigos industriales o clasificaciones de
productos) e informacin descriptiva de los servicios disponibles.
3. Dnde? (Where?) Informacin de registro sobre la URL, direccin de correo electrnico u otro medio a
travs de la cual se accede al servicio.
4. Cmo? (How?) Informacin de cmo funciona una interfase en particular del Servicio Web registrado.
Generalmente se agrupa a estas categoras bajo el nombre de Pginas blancas (Quin?), Pginas amarillas (Qu?) y
Pginas verdes (Dnde? y Cmo?).

UDDI esta diseada para interactuar con SOAP y WSDL. Por medio de un mensaje SOAP se puede interrogar a un
servidor UDDI para que este responda con informacin de acceso a un Servicio Web particular, por medio de un
documento WSDL.

Uso de UDDI
Un negocio u organizacin puede implementar uno o ms registros UDDI privados o pblicos. Un registro privado
permitir acceso slo a usuarios autorizados, mientras que uno pblico no impone restricciones de acceso. Una
combinacin de registros pblicos y privados permite realizar una divisin entre los servicios de informacin internos y
externos.
El beneficio de tener, y ofrecer, acceso a esta informacin es el de proveer medios para que terceros puedan descubrir
las interfaces disponibles para interactuar con un servicio, aumentando la eficacia de la organizacin que lo
implemente.

Informe de Tesina

Proyecto Switch Transaccional Pgina 33 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

UDDI Business Registry


El UDDI Bussines Registry (o UBR) es un registro pblico y gratuito actualmente operado conjuntamente por IBM,
Microsoft, NTT Communitations y SAP. Cualquier entidad tiene la libertad de registrarse y publicar informacin en
cualquiera de los nodos de UBR, as como de realizar bsquedas sobre ellos.

WS-SECURITY
Muchos problemas se asocian con el envo de mensajes en una ruta ms compleja que la de solicitud/respuesta o a
travs de un sistema de transmisin en el que no interviene HTTP. La identidad, integridad y seguridad del mensaje y
el remitente se deben proteger en los distintos saltos. A lo largo de la ruta se deben utilizar varias claves de cifrado.
Los dominios de confianza se cruzarn. HTTP y sus mecanismos de seguridad nicamente hacen frente a la seguridad
punto a punto. Es necesario que las soluciones ms completas incorporen un concepto de seguridad de extremo a
extremo. WS-Security trata el modo de mantener un contexto seguro a travs de una ruta de mensajes de varios
puntos.
WS-Security aborda el tema de la seguridad haciendo uso de las especificaciones y los estndares existentes. Con ello
se evita la necesidad de definir una solucin de seguridad completa en WS-Security. La industria ha resuelto muchos
de estos problemas. Kerberos y X.509 se ocupan del tema de la autenticacin. Asimismo, X.509 emplea la
infraestructura de clave pblica (PKI) existente en la administracin de claves. XML Encryption y XML Signature
describen distintas formas de cifrar y firmar el contenido de los mensajes XML. XML Canonicalization analiza los modos
de hacer que XML est preparado para el proceso de firma y cifrado. Lo que WS-Security aporta a las especificaciones
existentes es un marco para incorporar estos mecanismos a un mensaje SOAP.
WS-Security define un elemento de encabezado SOAP para transportar datos relacionados con la seguridad.
Fundamentalmente, WS-Security es una especificacin para un contenedor de metadatos de seguridad basado en
XML.
En el encabezado, los mensajes pueden almacenar informacin sobre el autor de la llamada y el modo en que se ha
firmado y cifrado el mensaje. WS-Security presenta una solucin extremo a extremo para la seguridad del servicio
Web conservando toda la informacin de seguridad en la parte SOAP del mensaje.
Los tres puntos siguientes son los principales aspectos presentes en el mbito de la seguridad:
1. Autenticacin
2. Firmas
3. Cifrado

Autenticacin
WS-Security proporciona un gran nmero de formas de validar a un usuario. En la especificacin se abordan tres
mtodos de entre todos los dems:
1. Nombre de usuario y contrasea.
2. Infraestructura de clave pblica (PKI) a travs de certificados X.509.
3. Kerberos.

Informe de Tesina

Proyecto Switch Transaccional Pgina 34 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Solicitud y uso de tokens desde un servicio de tokens de seguridad

Nombre de usuario y contrasea


Una de las formas ms comunes de transmitir las credenciales del remitente consiste en la combinacin del nombre de
usuario y contrasea. Esta tcnica se utiliza en la autenticacin implcita y bsica HTTP.

Validacin de un token de seguridad por un servicio

Informe de Tesina

Proyecto Switch Transaccional Pgina 35 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Certificados X.509
El simple envo de un certificado X.509 es otra opcin en el proceso de autenticacin de usuarios. Estos certificados
informan exactamente de la identidad del usuario. Con el uso de PKI, el certificado se puede asignar a un usuario
existente en la aplicacin. El uso del certificado por s mismo podra suponer el riesgo de sufrir ataques repetitivos con
bastante facilidad. Por lo tanto, es una buena alternativa hacer que el remitente tambin firme el mensaje empleando
su clave privada. De este modo, cuando se descifra el mensaje, se sabr que se trata realmente del usuario.

Traduccin de un valor UsernameToken a un valor X509SecurityToken

Kerberos
Para el uso de Kerberos, el usuario presenta una serie de credenciales, como el nombre de usuario y la contrasea o
un certificado X.509. Una vez realizada la comprobacin oportuna, el sistema de seguridad concede al usuario un vale
(TGT). El usuario no podr descifrar los datos ocultos del vale, pero s presentarlos para obtener acceso a otros
recursos. El vale se suele presentar para obtener un vale de servicio (ST). Kerberos resulta una especificacin
interesante, ya que contiene un mecanismo para que el cliente pueda demostrar su identidad en un servicio y
viceversa. El vale de servicio slo es eficaz para tener acceso a un recurso de red que se pueda utilizar para conocer la
identidad del remitente. Cuando se presenta un vale Kerberos en un mensaje, los datos se deben copiar "a ciegas" en
el propio mensaje. WS-Security no explica cmo se obtiene un vale o un vale de servicio.

Firma
Cuando se firma un mensaje, es muy difcil que ste se pueda ver alterado. La firma no protege el contenido del
mensaje de accesos no autorizados. Con la presencia de la firma, el receptor del mensaje SOAP puede saber qu
elementos no se han modificado durante el envo. Siempre que se pueda, se debe utilizar XML Signature, debido a que

Informe de Tesina

Proyecto Switch Transaccional Pgina 36 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

ya administra una serie de elementos dificultosos que se pueden averiguar. WS-Security simplemente explica cmo
utilizar la firma para comprobar que el mensaje no se ha modificado.
La firma se genera utilizando XML Signature. Para firmar un mensaje sencillo como, por ejemplo, "Hola a todos", casi
todos los elementos del mensaje se deben firmar individualmente. Cada vez que cambia un elemento es necesario
actualizar la firma para que el resto de elementos aparezcan de forma correcta. Por qu? Si el contenido cambia,
puede que la firma no coincida. En un mensaje SOAP, las firmas y los datos necesarios adicionales agregan un poco de
informacin adicional.

Cifrado
Existen situaciones en las que no es suficiente con comprobar la identidad del remitente y demostrar que el contenido
del mensaje no se ha visto alterado. Si se enva un nmero de tarjeta de crdito o de cuenta bancaria en texto sin
formato y firmado, un intruso puede llegar a comprobar que ningn otro intruso haya modificado el contenido del
mensaje. Por lo tanto, el intruso tendr una gran seguridad de que los datos son vlidos. Esto no beneficia al usuario
en absoluto. Resultara mucho ms recomendable que los datos se cifraran de tal modo que slo la persona a la que
va destinado el mensaje pudiera consultarlos. Cualquier persona que observe el intercambio de conexin permanecera
ajena respecto al contenido del mensaje. Tal y como sucede con la firma de mensajes, la especificacin WS-Security
toma las medidas adecuadas, adopta un estndar ya existente y, asimismo, realiza la tarea de cifrado. Es decir, se
incorpor XML Encryption.
Cuando se cifran los datos, se puede optar por el uso del cifrado simtrico o asimtrico. El primero de ellos requiere un
secreto compartido. Es decir, la clave utilizada para cifrar el mensaje es la misma que se puede emplear para
descifrarlo. El cifrado simtrico resulta conveniente si se controlan ambos puntos finales y si las personas y
aplicaciones que utilicen las claves son de confianza.

Emisin de un SecurityContextToken desde un servicio de tokens de seguridad

Si los datos se deben enviar utilizando claves fcilmente distribuidas, se debe considerar el uso del cifrado asimtrico.
Los certificados X.509 lo permiten. El punto final que recibe los datos puede enviar pblicamente su certificado y
permitir a cualquier usuario o a todos ellos cifrar la informacin con la clave pblica. El receptor ser el nico que
conozca la clave privada. Por ello, solamente l podr descifrar los datos y hacerlos legibles.

Informe de Tesina

Proyecto Switch Transaccional Pgina 37 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

WS-Security en resumen
WS-Security permite que el mensaje SOAP identifique al remitente, firme el mensaje y cifre su contenido. Siempre que
se pueda, las especificaciones existentes se vuelven a utilizar para reducir la cantidad de innovacin necesaria para
transmitir de forma segura un mensaje SOAP. Debido a que toda la informacin se transmite en el propio mensaje,
existir una neutralidad de transporte. El mensaje puede estar seguro si se transmitiera mediante HTTP, correo
electrnico o CD-ROM.

Informe de Tesina

Proyecto Switch Transaccional Pgina 38 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Captulo 3 Proyecto: Switch


Transaccional
Proceso de Implementacin
Para ejecutar el presente proyecto se defini un proceso general de desarrollo que actu como marco de referencia y
gua de todas las actividades y producciones resultantes del presente proyecto.
El proceso describe como se divide el proyecto, cuales son las distintas responsabilidades y que actividades desarrolla
cada una de estas responsabilidades, como as tambin el conjunto de artefactos de resultado del mismo.
Para un detalle completo ver: Anexo B Proceso General de Implementacin

ENTALLAMIENTO DEL PROCESO DE IMPLEMENTACIN

El proceso general de implementacin describe en forma general el proceso para implementar cualquier tipo de
proyecto de tecnologa. Pero el mismo debe ser adecuado a las realidades de cada proyecto. Por ello en esta seccin
se detallan las particularidades del proceso empleado en el presente proyecto.
El presente entallamiento tiene dos particularidades centrales, la primera es que se enmarca dentro de un trabajo de
tesis de licenciatura y por lo tanto uno de los principales artefactos a producir es el trabajo de investigacin en si. El
cual se encuentra en el Capitulo 2 Fundamentacin Terica la segunda particularidad es el aspecto solitario de
implementacin del presente proyecto, provocando esto que se haya tomado la decisin de utilizar metodologas, que
si bien respetan al PGI, se adaptan mejor a este tipo de situacin.

METODOLOGA DE ADMINISTRACIN DE PROYECTO

Como se mencion, para agilizar la gestin del proyecto, se ha decidido realizar la misma bajo la consigna de las
metodologas Agile. Donde para garantizar su correcto uso se ha utilizado la herramienta XPlanner que se ha adaptado
perfectamente a la tipologa descripta, utilizando en particular la metodologa eXtreme Programming (XP).
A continuacin se describe brevemente (segn Wikipedia) en que consiste dicho paradigma:

La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado por
Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es la
ms destacada de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se
diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la
previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los
requisitos.Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo
de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de
vida del software.

Informe de Tesina

Proyecto Switch Transaccional Pgina 39 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Las caractersticas fundamentales del mtodo son:


Desarrollo iterativo e incremental: pequeas mejoras, unas tras otras.

Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y
discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata.
Frecuente interaccin del equipo de programacin con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.

Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin
no se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en
grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier
parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr
aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y
tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca
utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil
identificar qu se debe y qu no se debe hacer. Mientras ms simple es el sistema, menos tendr que comunicar
sobre este, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de
programadores.

Cronograma Original del Proyecto


El proyecto original se haba planteado en 8 iteraciones, ejecutando un total de 576 horas en 128 das.

FASES DEL PROYECTO

Informe de Tesina

Proyecto Switch Transaccional Pgina 40 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

TAREAS TRANSVERSALES (ADMINISTRACIN)

TAREAS VERTICALES (DESARROLLO)

Plan de infraestructura y Configuraciones

INTRODUCCIN
El presente documento tiene por objetivo describir la infraestructura (equipos informticos, software y
comunicaciones) requerida para el proceso de desarrollo e implementacin de producto Switch Transaccional que ser
desarrollado dentro del marco de la Tesis de Licenciatura en informtica de la Universidad de la Patagonia San Juan
Bosco.

Informe de Tesina

Proyecto Switch Transaccional Pgina 41 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

El presente documento establece el detalle de herramientas de desarrollo como todo el software necesario y requerido
para la puesta en marcha del presente trabajo de tesis.

ARQUITECTURA
La Arquitectura del Switch Transaccional prev como primer medida el ruteo y sincronizacin de servicios entre
organizaciones y entidades, de esta forma el intercambio de servicios y mensajes queda concentrado y estandarizado
en el Switch Transaccional.

Como se puede observar la arquitectura del portal est definida fundamentalmente por un conjunto de servicios back-
end soportados en el concepto de arquitectura B2B (Business to Business) o A2A (Application to Application) basada
en el concepto de colas para aplicaciones distribuidos, en este caso implementadas mediante la implementacin de
Web-Services y el uso de BPEL.

Informe de Tesina

Proyecto Switch Transaccional Pgina 42 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Por otra parte existe un mdulo de configuracin del portal que estar desarrollado en JAVA en una arquitectura en
capas utilizando para ello J2EE y el patrn Model-View-Controller.

DEFINICIN DE AMBIENTES
Un ambiente est definido por un conjunto de Soft de base (SO, Base de datos y servidor de aplicaciones) y por las
herramientas con sus respectivas versiones y configuraciones utilizadas.
Es muy importante para la estabilidad de un ambiente conocer cada herramienta y las versiones utilizadas para
determinar de esta forma una configuracin dada para un ambiente y de esta forma mantenerlo controlado ante los
cambios que deban sufrir (actualizaciones y nuevas versiones).
As mismo los ambientes contienen un conjunto de configuraciones y de datos de la aplicacin a desarrollar que
tambin debern ser controlados por cada ambiente para mantener la integridad de la aplicacin, su desarrollo y las
pruebas que se deban realizar sobre la misma.

DESARROLLO
Formalmente se utilizar la denominacin DESA para referirnos a este ambiente.
Es el ambiente donde se desarrolla todo el proceso implementacin (Anlisis, diseo y Construccin). Por proceso de
implementacin se entiende:
Desarrollo de casos de usos: Requerimientos funcionales de la aplicacin.

Definicin de los requerimientos no funcionales.

Desarrollo de la Arquitectura y diseo.

Construccin de la aplicacin.

Parametrizacin y definicin de datos de los meta-modelos derivados de la Arquitectura.

Informe de Tesina

Proyecto Switch Transaccional Pgina 43 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Construccin de scripts para realizar las distintas pruebas de la aplicacin y ajustes a las configuraciones
existentes.
Construccin de componentes de ingeniera de sistemas y soporte.

TESTING
Formalmente se utilizar la denominacin TEST para referirnos a este ambiente
Es el ambiente donde se realizan las pruebas de conformidad de los casos de uso implementados (durante el proceso
de implementacin), y donde adems se realizan pruebas de carga. Especialmente en el desarrollo de la presente
aplicacin donde su caracterstica de backend se basa fundamentalmente en la actividad transaccional de servicios
Este ambiente tambin se utiliza en los procesos de capacitacin.
El ambiente TEST puede ser clonado de los ambientes DESA o PROD con la finalidad de equiparar cualquiera de los
ambientes y realizar las pruebas respectivas. Este mismo proceso de clonado servir tambin para el testeo de los
paquetes de Deploy, garantizando que la aplicacin de los mismos mantendr la integridad en el ambiente PROD. En
la seccin Control de Configuraciones se detallan los procedimientos asociados al clonado de ambientes.

PRODUCCIN
Formalmente se utilizar la denominacin PROD para referirnos a este ambiente
Es el ambiente de produccin que se utilizar para uso de la Solucin durante y luego de la finalizacin del proceso de
implementacin.
El contenido de datos y funcionalidad de este ambiente va aumentando a medida que se avanza en el proceso de
implementacin y en el refinamiento de casos de uso. Los usuarios del cliente trabajan sobre este ambiente utilizando
todas aquellas funcionalidades que hayan sido puestas en marcha. Cada nuevo caso de uso cuya implementacin haya
sido aprobada por el cliente en el ambiente de TEST, es implementado (siguiendo el plan de estrategia de control de
configuraciones) en este ambiente para su utilizacin por parte de los usuarios.

AMBIENTE DE DESARROLLO
Dada la gnesis del proyecto donde la utilizacin y la produccin de software de cdigo abierto (Open Source) es un
factor impulsor de la Sociedad de la Informacin. El ambiente de desarrollo del producto Switch Transaccional debe
cumplir con las caractersticas mencionadas.
Se debe mencionar que por las caractersticas del producto a construir se ha decidido la utilizacin de Java como
lenguaje debido a la gran integracin que posee el mismo con las tecnologas de aplicaciones distribuidas. De hecho
Java fue pensado como un lenguaje orientado a las aplicaciones en redes y sistemas distribuidos
Para ello se han recorrido distintos ambientes IDE (Integrated development environment) que permitieran lograr los
objetivos Open Source y la utilizacin de Java como lenguaje.
Dicho ambiente deba soportar adems la utilizacin de PlugIns (componentes enchufables o lo que se conoce como
tecnologa de cartuchos). Dichos PlugIns deban permitir la incorporacin de diversas herramientas para la realizacin
del proyecto, no solo desde el punto de vista de desarrollo sino tambin para la Ingeniera de Requerimientos,
Arquitectura, Diseo, Construccin, Testing y Documentacin.
En el proceso se investigaron y probaron varias herramientas de las cuales solo dos cumplan con los requisitos
buscados:
Eclipse de Eclipse Foundation
ver http://www.eclipse.org/org/
NetBeans

Informe de Tesina

Proyecto Switch Transaccional Pgina 44 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

ver http://www.netbeans.org/index_es.html o http://www.netbeans.org/about/index.html


Finalmente se decidi realizar el proyecto utilizando NetBeans debido a que la mayora de los plugins requeridos eran
desarrollados por la misma organizacin NetBeans. Lo que garantiza una mejor integracin de dichos plugins con el
IDE.
Por otra parte algunos de los Plugin requeridos para el proyecto dentro del ambiente Eclipse no eran Open Source
como por ejemplo la herramienta UML.
Tambin dentro de la seleccin de la herramienta pes superlativamente las opciones y soportes que daba el ambiente
para el desarrollo de aplicaciones SOA, donde NetBeans posee herramientas y tutoriales sumamente avanzados,
incluyendo una herramienta de diseo BPEL muy importante para la realizacin del proyecto.
En todos los casos si las condiciones del proyecto lo habilitan se realizarn las actualizaciones (o aplicacin de parches)
de los productos mencionados en el presente documento. Cuando esto sucede se notificaran los cambios realizados a
las plataformas.
Para el detalle tcnico de cada producto se provee el link respectivo al web site del producto con la informacin
tcnica del mismo.

SOFTWARE DE BASE
Sistema Operativo
GNU/Linux Fedora Core 6 de 64 bits. http://www.redhat.es/fedora/ http://fedoraproject.org/
Linux version 2.6.20-1.2952.fc6 (brewbuilder@ls20-bc2-14.build.redhat.com) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007
Ver Anexo C: Detalle del Sistema Operativo
Base de datos
MySQL 5.0.27 http://www.mysql-hispano.org/ http://www.mysql.org/

Ver Anexo D: Detalle Servidor de Base de Datos


Servidor de aplicaciones
Apache Tomcat 5.0.28 http://tomcat.apache.org
GlassFish V2 https://glassfish.dev.java.net/
Ver Anexo E: Detalle del Servidor de Aplicaciones

HERRAMIENTAS DE GESTIN
XPlanner Version 0.7b7 --> Herramienta de planificacin, control y seguimiento de proyectos utilizando
metodologas Agile (eXtreme Programming: XP) http://www.xplanner.org/
OpenOffice.org 2.0.4 --> Herramienta de oficina que permiten gestionar documentos, planillas de clculo y
pesentaciones. http://es.openoffice.org/

HERRAMIENTA DE DESARROLLO
NetBeans IDE 6 (Release Beta1) http://www.netbeans.org/community/releases/60/index.html
Visual Web Pack http://www.netbeans.org/products/visualweb/
Enterprise Pack http://www.netbeans.org/products/enterprise/
UML Modeling http://www.netbeans.org/products/uml/index.html

HARDWARE UTILIZADO
Motherboard: ECS RS485M-M
Procesador: AMD Athlon(tm) 64 X2 Dual Core Processor 3600+

Informe de Tesina

Proyecto Switch Transaccional Pgina 45 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Controlador IDE: ATI 4379 Serial ATA Controller


Disco Rgido: Western Digital de 160 GB de 7500 RPM (WDC WD1600JS-22N)
Memoria: 1 Gb de memoria RAM SDDR 766 Mhz.
Audio: IXP SB400 AC'97 Audio Controller
DVD: HL-DT-STDVD-RAM GSA-H20N
RED: RTL-8139/8139C/8139C+

AMBIENTES DE TESTING
Para el ambiente de Testing se utilizar el mismo hardware, Soft de base y herramientas que para el ambiente de
desarrollo pero se utilizarn un esquema de base de datos diferencial al igual que un deploy diferente en el servidor de
aplicaciones.

AMBIENTE DE PRODUCCIN

Para el ambiente de produccin tambin se utilizar el mismo hardware, Soft de base y herramientas que para el
ambiente de desarrollo. Tambin aqu con el esquema de ambiente diferenciado para la Base de datos y servidor de
aplicaciones.
Pero dada la gnesis de integracin de aplicaciones y simulando las posibles aplicaciones clientes de las organizaciones
que demanden y provean servicios, se agrega una nueva plataforma con el objetivo de realizar dichas pruebas y
garantizar que el Switch Transaccional funciona integrando distintas plataformas de ejecucin

SISTEMA OPERATIVO
GNU/Linux Fedora Core 6 de 64 bits. http://www.redhat.es/fedora/ http://fedoraproject.org/
Linux version 2.6.20-1.2952.fc6 (brewbuilder@ls20-bc2-14.build.redhat.com) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007
Ver Anexo A: Detalle del Sistema Operativo

BASE DE DATOS

MySQL 5.0.27 http://www.mysql-hispano.org/ http://www.mysql.org/

Ver Anexo B: Detalle Servidor de Base de Datos

SERVIDOR DE APLICACIONES

GlassFish V2 https://glassfish.dev.java.net/

Ver Anexo C: Detalle del Servidor de Aplicaciones

HARDWARE UTILIZADO
Motherboard: MICRO-STAR INTERNATIONAL CO., LTD (6A6LVM4D) Bios: Phoenix-Award BIOS v6.00PG
Procesador: AMD Athlon TH (Thoroughbred) / AMD Duron(tm) processor / 1399 Mhz
Controlador: ATA Controller
Disco Rgido: Western Digital de 80 GB de 7500 RPM (WDC WD800LB-55DNA0)
Memoria: 512 MB SDRAM de 60 ns + 256 MB SDRAM de 60 ns.
RED: VIA Rhine II Fast Ethernet Adapter

Informe de Tesina

Proyecto Switch Transaccional Pgina 46 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

CONTROL DE CONFIGURACIONES

METODOLOGA DEL CONTROL DE CONFIGURACIONES.


Resumen
El control de configuraciones estar orientado a las iteraciones del proyecto, donde se preve liberar versiones del
producto integrales. El paquete de instalacin (PI) de cada versin integral deber permitir actualizar la versin
anterior, incrementando al misma un release.
As mismo se preve la generacin de mini actualizaciones o parches que permitirn corregir problemas o defectos
intermedios sin necesidad de esperar a la finalizacin de la iteracin.
Igualmente se deber garantizar que todos los parches estn incluidos en el PI (paquete de Instalacin) del
release siguiente y el PI siguiente no deber afectar ninguna instalacin intermedia.

Definiciones
PI --> Paquete de Instalacin. El mismo contiene las siguientes secciones:
DB:
Actualizacin e instalacin de tablas, vistas, triggers y procedimientos de la Base de datos. El script deber
prever e ir solicitando informacin as corresponda. Usuario de conexin y esquema a instalar. Ser
responsabilidad del instalador conocer el ambiente donde instalar y garantizar que se est instalando el
script en dicho ambiente.
Tambin este proceso debe garantizar la actualizacin de datos cuando corresponda, salvo que se requiera
intervencin de los usuario en cuyo caso deber quedar aclarado en la documentacin general del PI
XML --> Conjunto de XML, XSLT, DTS o XSD de la aplicacin. A tal fin se definir un nico directorio del
servidor de aplicaciones que contendr todos los archivos de este tipo para cada ambiente. Estos archivos
pueden ser tanto de configuracin de uso de la aplicacin, como de definiciones de usuario como puede ser un
proceso BPEL y una parser o transformacin requerida.
JAR --> Conjunto de paquetes Java con la aplicacin en si. A tal fin se definir un nico directorio del servidor
de aplicaciones que contendr todos los archivos de este tipo para cada ambiente.
VGUI --> Conjunto de archivos vinculados a la parte visual de la aplicacin. A tal fin se definir un nico
directorio del servidor de aplicaciones que contendr todos los archivos de este tipo para cada ambiente. Estos
archivos pueden ser tanto Java Server faces (JSF) como Java Server Pages (JSP).
DOC --> Conjunto de archivos vinculados con la documentacin de la aplicacin. A tal fin se definir un nico
directorio del servidor de aplicaciones que contendr todos los archivos de este tipo para cada ambiente. Estos
archivos pueden contener tanto documentos de texto, como hojas de clculo, presentaciones y adems todo el
material UML desarrollado y mantenido en el anlisis y diseo de la aplicacin. Esto permitir garantizar una
trazabilidad entre los objetos de la aplicacin y su documentacin.
AI -->
Actualizacin Intermedia. Este paquete puede contener las mismas secciones anteriores salvo la seccin DB.
De esta forma se garantizar que los AI no contienen cambios estructurales a la aplicacin. Ya que el resto de
las secciones son inocuas ante nuevos Deploy, pero la base de datos no, ya que all se registrar el
comportamiento de la aplicacin mediante una arquitectura de meta informacin de la misma.
Deber quedar claro por lo tanto que no se podr incluir ningn nuevo objeto de la aplicacin que requiera de
dichos cambios de Base de datos. Quedando las actualizaciones limitadas a solucionar problemas existentes en
la aplicacin que impiden realizar, por ejemplo, el plan de pruebas trazado.

Informe de Tesina

Proyecto Switch Transaccional Pgina 47 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

HERRAMIENTAS PARA LA ADMINISTRACIN DEL CONTROL DE CONFIGURACIONES.

Como herramienta de administracin y control de configuraciones se disear una pequea base de datos que
permita registrar las actualizaciones y la registracin de parches instalados en cada ambiente, permitiendo de esta
forma controlar los componentes y las revisiones de instalacin de cada ambiente.
Ser muy importante la clara documentacin de los PI y de los AI que permitir realizar la trazabilidad de los
componentes que contiene cada ambiente y su respectiva versin.

PLAN DE CONTINGENCIA
Debido a la gnesis del proyecto no implica un mayor riesgo la administracin de un plan de contingencia ya que el
proyecto afecta a la tesis de licenciatura donde se involucra a una sola persona y donde no existen riesgos econmicos
afectados a la misma.
Por lo tanto no se describirn posibles escenarios de amenaza ni impactos consecuentes de dichas amenazas. S se
establecer un esquema de resguardo del proyecto y una indicacin de restauracin del mismo y los tiempos
incurridos para la restauracin del mismo.

ESQUEMA DE RESGUARDO Y RECUPERACIN DE AMBIENTES.

Toda la gestin y desarrollo del proyecto se administra desde un slo equipo, por lo tanto el procedimiento que a
continuacin se describe afecta a dicho equipo utilizado en el ambiente DESA y TEST. No se preve respaldo del
ambiente de produccin ya que el mismo es reinstalable y recuperable desde los parches de actualizacin e
instalacin en produccin.

HERRAMIENTA UTILIZADA PARA LA GESTIN DE BACKUP


Se ha decidido utilizar la herramienta Open Source Yakup (yet another backup script) que simplifica mediante el
uso del comando tar la realizacin y gestin de copias de seguridad.
Entre las principales caractersticas se puede mencionar:
Backup completo (full), incrementales y diferenciales.
Resguardo y recuperacin desde disco rgido y medios removibles como CD o DVD.
Administracin avanzada de medios.
Configuracin de copias de seguridad mediante el uso de archivos de configuracin.
Uso de tar. tar compatible.
Compresin de datos mediante uso de gzip o bzip2.

CONFIGURACIN
ARCHIVE_DIR=/media/backup/demian
COMPRESSION=gzip
DEV=/dev/hda
DVD_DIR=/media/dvd
DVD_SIZE=4.7G
EXCLUDE_FILE=/home/demian/excluded.files
INCLUDE_FILE=/home/demian/included.files
LOG_FILE=/home/demian/yakup.log
MEDIA=dvd
MKISOFS_OPTS="-r -J"
PREFIX=yakup%l.$(date +%Y%m%d)
RESTORE_DIR=/media/restore/demian
VOLUME_ID="yakup%l $(date +%F) (%n of %N)"

Informe de Tesina

Proyecto Switch Transaccional Pgina 48 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Administracin del proyecto


A continuacin se realizar un resumen de la bitcora del proyecto segn lo registrado en XPlanner. Para ello se
utilizaran las facilidades de gestin de reportes que posee la herramienta.
Respecto del cronograma original se han realizado las siguientes modificaciones:
Se cambi la cantidad de iteraciones de la fase de refinamiento, ya que en la original se prevan iteraciones de 5
semanas cada una y se pas a un mdulo de 2 semanas cada una, esto debido al cambio de la metodologa XP.
Se extendi el proyecto en tiempo ya que por un lado por cuestiones de ndole personal se tuvo que suspender
el proyecto unos 3 meses y por otra parte se cambi el mdulo diario de trabajo de 4,5 horas a 3 o 4 horas,
generando un desplazamiento en las fechas prevista de finalizacin.
Comparativamente segn el cronograma original se emplearan 576 horas en 128 das y como resultado final se
emplearon 680 horas en 177 das. Lo cual representa un desvo del 18% en el total de horas y un desvo del 38.3% en
el total de das (hbiles de ejecucin).

DETALLE DE HORAS POR HISTORIAS DEL USUARIO (USER STORY) EJECUTADAS EN EL PROYECTO

Informe de Tesina

Proyecto Switch Transaccional Pgina 49 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 50 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

RESUMEN DE ITERACIONES

Para un detalle completo del registro de todas las tareas ejecutadas en el proyecto ver Anexo F: Detalle de las etapas
de implementacin a continuacin se realiza un resumen de los principales hitos y/o entregables de cada iteracin:

FASE LANZAMIENTO - ITERACIN 1


Se instalaron las herramientas iniciales de la infraestructura del proyecto.

FASE ELABORACIN - ITERACIN 2


Se defini y elabor el plan de infraestructura.

Se instalaron las herramientas de desarrollo y se complet y puso en marcha toda la infraestructura


requerida para el proyecto.

FASE ELABORACIN - ITERACIN 3


Se investig y se escribi el trabajo sobre sociedad de la informacin y las herramientas tecnolgicas
que fundamentan el presente trabajo.

FASE REFINAMIENTO - ITERACIN 4


Se establecieron los objetivos del Switch Transaccional.

Se definieron los principales casos de uso y se priorizaron para su implementacin.

FASE REFINAMIENTO - ITERACIN 5


Capacitacin sobre las herramientas tecnolgicas propuestas primera parte: XML, XSLT, XSD.

Se definieron y especificaron las clases Java y las JSP correspondientes a la aplicacin de administracin
del Switch Transaccional.

FASE REFINAMIENTO - ITERACIN 6


Se desarrollaron todos las plantillas JSP que dan origen al estndar de visualizacin de la aplicacin de
administracin del Switch Transaccional.
Se defini y construy toda la ingeniera de base para la aplicacin.

FASE REFINAMIENTO - ITERACIN 7, 8, 9 Y 10


Etapa de construccin de software, donde Se implementaron las aplicaciones base, meta modelos y sus
pantallas para la configuracin genrica del Switch Transaccional, Mdulo de administracin y
comportamiento genrico.

FASE REFINAMIENTO - ITERACIN 11


Capacitacin sobre las herramientas tecnolgicas propuestas segunda parte: Java y XML (WS-RM, WS-
Addressing, JAX-WS, JAXB, SAAJ, StAX).
Se dise el logotipo del Switch Transaccional.

Informe de Tesina

Proyecto Switch Transaccional Pgina 51 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 12


Testing del mdulo de administracin.

Capacitacin sobre las herramientas tecnolgicas propuestas tercera parte: SOA y BPEL.

FASE REFINAMIENTO - ITERACIN 13, 14 Y 15


Se construyeron todos los servicios para dar soporte al funcionamiento del Switch Transaccional .

FASE REFINAMIENTO - ITERACIN 16 Y 17


Construccin del motor BPEL del Switch Transaccional.

Integracin de los componentes desarrollados.

Pruebas formales de integracin de la solucin.

Desarrollo de ejemplo prototipo.

FASE CIERRE - ITERACIN 18


Elaboracin del informe de tesina.

Elaboracin de la presentacin para la defensa del proyecto.

Informe de Tesina

Proyecto Switch Transaccional Pgina 52 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Solucin
La solucin completa del SwitchTransaccional se encuentra registrada en Google Code como proyecto Open Source. Si
se desea una copia completa de los resultados del presente trabajo se debe bajar la informacin de:
http://switchtransaccional.googlecode.com donde en la pestaa source se puede obtener el cdigo y documentacin
completa del proyecto.
A fin de realizar el presente informe se realiza una sntesis y resumen de todos los resultados del proyecto, mostrando
los resultados mas relevantes del proyecto.

PRINCIPALES CASOS DE USO


Los casos de uso aqu presentados ya pasaron todas las etapas de refinamiento y son la versin final.

ADMINISTRACIN DEL META-MODELO DEL SWITCH TRANSACCIONAL

Informe de Tesina

Proyecto Switch Transaccional Pgina 53 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

CONSUMIDORES (CLIENTES) DEL SWITCH TRANSACCIONAL

Informe de Tesina

Proyecto Switch Transaccional Pgina 54 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

PROVEEDORES DEL SWITCH TRANSACCIONAL

SWITCHTRANSACCIONAL

Informe de Tesina

Proyecto Switch Transaccional Pgina 55 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

DISEO DEL SWITCH TRANSACCIONAL

PROCESO DE ATENCIN DEL SWITCH TRANSACCIONAL

Informe de Tesina

Proyecto Switch Transaccional Pgina 56 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

DIAGRAMAS DE SECUENCIA
Mensaje Sincrnico

Informe de Tesina

Proyecto Switch Transaccional Pgina 57 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Mensaje Asincrnico

Informe de Tesina

Proyecto Switch Transaccional Pgina 58 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

MODELO DE DATOS
A continuacin se presenta el modelo de datos completo utilizado para el desarrollo del Switch Transaccional. El detalle
completo del diccionario de datos se encuentra alojado en el sitio Open Source del proyecto:
http://switchtransaccional.googlecode.com

ESQUEMA DE CONFIGURACIN GENRICO

Informe de Tesina

Proyecto Switch Transaccional Pgina 59 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

ENTIDADES EXTERNAS

Informe de Tesina

Proyecto Switch Transaccional Pgina 60 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

SERVICIOS DEL SWITCH TRANSACCIONAL

Informe de Tesina

Proyecto Switch Transaccional Pgina 61 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

COMPONENTES
Las clases del Switch Transaccional se dividen en dos grupos, por un lado todas las clases necesarias para
implementar el patrn MVC (Model/View/Controller) que permiten administrar los meta-modelos y configuraciones del
Switch Transaccional y por otro todos los Web Services y BPEL's que conforman el motor del Switch Transaccional.

RESUMEN DE LAS CLASES MVC


Modelos
Todos los modelos de la aplicacin se implementan utilizando la clase DataStore del Framework SOFIA.
Paquete infraestructura.models
AccesoMenuModel --> Implementa el acceso a la tabla acceso_menu del esquema infraestructura que tiene
como lookup a las tablas website_user, roles y menu.
AtributosConfiguracionModel --> Implementa el acceso a la tabla atributos_configuracion del esquema
infraestructura y tiene como lookup a las tablas atributos_rol, esquema_configuracion y configuracion.
AtributosEntidadModel --> Implementa el acceso a la tabla atributos_entidad del esquema infraestructura y
tiene como lookup a las tablas atributos_rol, entidad_externa y clase_atributo_rol.
AtributosRolModel --> Implementa el acceso a la tabla atributos_rol del esquema infraestructura y tiene
como lookup a las tablas clase_atributo_rol, rol_entidad y clase_lov_atributo.
ClaseAtributoRolModel --> Implementa el acceso a la tabla clase_atributo_rol del esquema infraestructura.

ClaseLovAtributoModel --> Implementa el acceso a la tabla clase_lov_atributo del esquema infraestructura.

ConfiguracionModel --> Implementa el acceso a la tabla configuracion del esquema infraestructura y tiene
como lookup a la tabla esquema_configuracion.
DiccionarioAplicacionModel --> Implementa el acceso a la tabla diccionario_aplicacion del esquema
infraestructura.
EntidadExternaModel --> Implementa el acceso a la tabla entidad_externa del esquema infraestructura.

EsquemaConfiguracionModel --> Implementa el acceso a la tabla esquema_configuracion del esquema


infraestructura.
LovAtributoModel --> Implementa el acceso a la tabla lov_atributo del esquema infraestructura y tiene como
lookup a la tabla clase_lov_atributo.
RolEntidadModel --> Implementa el acceso a la tabla rol_entidad del esquema infraestructura.

RolesEntidadModel --> Implementa el acceso a la tabla roles_entidad del esquema infraestructura y tiene
como lookup a las tablas rol_entidad y entidad_externa.
RolesModel --> Implementa el acceso a la tabla roles del esquema infraestructura.

UsuarioRolesModel --> Implementa el acceso a la tabla usuario_roles del esquema infraestructura y tiene
como lookup a la tabla roles.
WebsiteUserModel --> Implementa el acceso a la tabla website_user del esquema infraestructura.

Paquete switchTransaccional.models
ConfiguracionServicioModel --> Implementa el acceso a la tabla configuracion_servicio del esquema
switchTransaccional y tiene como lookup a las tablas servicio_distribuido e infraestructura.configuracion.
InformeLogView --> Implementa el acceso a la vista informe_log del esquema switchTransaccional.

Informe de Tesina

Proyecto Switch Transaccional Pgina 62 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

RecuperaAtributoModel --> Implementa el acceso a la tabla recupera_atributo del esquema


switchTransaccional y tiene como lookup a las tablas servicio_distribuido e infraestructura.atributos_rol.
ServicioDistribuidoModel --> Implementa el acceso a la tabla servicio_distribuido del esquema
switchTransaccional.
ServiciosEntidadModel --> Implementa el acceso a la tabla servicios_entidad del esquema
switchTransaccional y tiene como lookup a las tablas servicio_distribuido e infraestructura.entidad_externa.

Pginas JSP
Todas las pginas JSP se construyeron usando tags extendidos del Framework SOFIA.
Aplicacin Infraestructura
AbmcAccesoMenu.jsp --> Implementa las altas, bajas, modificaciones y consultas de la configuracin de
acceso a los mens por parte de los usuarios. Utiliza el modelo infraestructura.models.AccesoMenuModel y
el controlador infraestructura.controllers.BaseController.
AbmcAtributoGenerico.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin para
implementar atributos genricos que puedan ser utilizados tanto por entidades externas como por cualquier
tabla declarada en el diccionario de la aplicacin. Utiliza el modelo infraestructura.models.AtributosRolModel
y el controlador infraestructura.controllers.BaseController.
AbmcClaseAtributoRol.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin para
implementar clases de atributos genricos o sea grupo de atributos que permitan clasificar y armar las
pestaas genricas en las pantallas de administracin de atributos. Utiliza el modelo
infraestructura.models.ClaseAtributoRolModel y el controlador infraestructura.controllers.BaseController.
AbmcClaseListaValorAtributo.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin
de valores asociados a un atributo genrico, permitiendo armar listas de validacin dinmica en el alta de los
atributos. Utiliza los modelos infraestructura.models.ClaseLovAtributoModel y
infraestructura.models.LovAtributoModel y el controlador
infraestructura.controllers.AbmcClaseListaValorAtributoController.
AbmcConfiguracion.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de
configuraciones genricas en funcin de valores alcanzados por atributos genrico, permitiendo implementar
comportamientos dinmicos en las aplicaciones. Utiliza los modelos
infraestructura.models.ConfiguracionModel, infraestructura.models.EsquemaConfiguracionModel e
infraestructura.models.AtributosConfiguracionModel y el controlador
infraestructura.controllers.AbmcConfiguracionController.
AbmcDiccionarioAplicacion.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de
objetos de la aplicacin como por ejemplos las tablas de la base de datos. Utiliza el modelo
infraestructura.models.DiccionarioAplicacionModel y el controlador infraestructura.controllers.BaseController.
AbmcEntidadExterna.jsp --> Implementa las altas, bajas, modificaciones y consultas de entidades externas
de la aplicacin, pudiendo estos tomar uno o varios roles definido para la aplicacin. Tambin administra
todos los atributos genricos definidos para la entidad agrupndolos segn su clase. Utiliza los modelos
infraestructura.models.EntidadExternaModel, infraestructura.models.RolesEntidadModel e
infraestructura.models.AtributosEntidadModel y el controlador
infraestructura.controllers.AbmcEntidadExternaController.
AbmcEsquemaConfiguracion.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin
de los posibles esquemas de configuracin genrica que utilizar la aplicacin. Utiliza el modelo
infraestructura.models.EsquemaConfiguracionModel y el controlador
infraestructura.controllers.AbmcEsquemaConfiguracionController.
AbmcMenues.jsp --> Implementa las altas, bajas, modificaciones y consultas de los mens de la aplicacin,

Informe de Tesina

Proyecto Switch Transaccional Pgina 63 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

permitiendo de esta forma configurar cualquier estructura de men genrica. Utiliza el modelo
infraestructura.models.MenuModel y el controlador infraestructura.controllers.BaseController.
AbmcRolEntidad.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de los
posibles roles de entidades externas que se usarn en la aplicacin. Tambin permite asociar que atributos
genricos quedan definidos para el rol. Utiliza los modelos infraestructura.models.RolEntidadModel e
infraestructura.models.AtributosRolModel y el controlador
infraestructura.controllers.AbmcRolEntidadController.
AbmcRoles.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de los roles de
usuario para implementar el acceso a la aplicacin. Utiliza el modelo infraestructura.models.RolesModel y el
controlador infraestructura.controllers.AbmcRolEntidadController.
AbmcWebSiteUsers.jsp --> Implementa las altas, bajas, modificaciones y consultas de los usuarios de la
aplicacin y los roles de acceso. Utiliza los modelos infraestructura.models.WebsiteUserModel e
infraestructura.models.UsuarioRolesModel y el controlador infraestructura.controllers.WebSiteUserController.
Aplicacin SwitchTransaccional
AbmcConfiguracionServicio.jsp --> Implementa las altas, bajas, modificaciones y consultas del
comportamiento especfico para los servicios distribuidos. Utiliza los modelos
switchTransaccional.models.ServicioDistribuidoModel y
switchTransaccional.models.ConfiguracionServicioModel y el controlador
switchTransaccional.controllers.AbmcConfiguracionServicioController.
AbmcRecuperaAtributos.jsp --> Implementa las altas, bajas, modificaciones y consultas que permiten
configurar cmo se recupera el contenido de un atributo de un servicio distribuido. Utiliza los modelos
switchTransaccional.models. RecuperaAtributoModel y switchTransaccional.models. ServicioDistribuidoModel
y el controlador switchTransaccional.controllers.AbmcRecuperaAtributosController.
AbmcServicioDistribuido.jsp --> Implementa las altas, bajas, modificaciones y consultas de lo sservicios
distribuidos que atiende el Switch Transaccional, permitiendo administrar los atributos genricos del mismo
que darn origen al contenido. Utiliza los modelos switchTransaccional.models.ServicioDistribuidoModel e
infraestructura.models.AtributosEntidadModel y el controlador
switchTransaccional.controllers.AbmcServicioDistribuidoController.
AbmcServiciosEntidad.jsp --> Implementa las altas, bajas, modificaciones y consultas de los servicios
asociados a un proveedor de servicios distribuidos que son los responsables de atender los mensajes
enviados por los clientes. Utiliza los modelos switchTransaccional.models.ServiciosEntidadModel y
switchTransaccional.models.ServicioDistribuidoModel y el controlador
switchTransaccional.controllers.AbmcServiciosEntidadController.

Controladores
Los controladores son los mencionados en la seccin Pginas JSP y tiene como misin capturar las interacciones de los
usuarios de las pginas web y la de aplicar las reglas de negocio respectivas para el correcto funcionamiento de las
pginas.
Todos los controladores derivan de infraestructura.controllers.BaseController que es el responsable de controlar el
aspecto general de las pginas, como por ejemplo el men y de la seguridad de acceso a la aplicacin.

RESUMEN DE WEB SERVICES


Todos los Web Services definidos son de soporte al motor del Switch Transaccional y su uso es exclusivo de los BPEL
que son los responsables de implementar los distintos Casos de Uso de atencin de servicios.
Para un ejemplo ver .Diseo del Switch Transaccional
Todos los Web Services se implementaron como EJB (Enterprise Java Beans) definiendo distintos tipos de operaciones.

Informe de Tesina

Proyecto Switch Transaccional Pgina 64 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

RecuperaAtributosServicio

AdministraLogSwitch

Informe de Tesina

Proyecto Switch Transaccional Pgina 65 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 66 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 67 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

DeterminaConfiguracionServicio

RESUMEN DE BPEL'S
Los BPEL de la solucin son el corazn del Switch Transaccional ya que permiten acoplar y orquestar todas las
actividades requeridas para recibir la solicitud de un servicio, interpretar segn su contenido como se descompone el
mismo, re-enviar todos las solicitudes que se requieran y re-ensamblar una respuesta.
Tambin en los BPEL se pueden implementar capas que permita realizar actividades de Parser y transformacin de
mensajes aplicando normalizaciones a los mismos

IMPLEMENTACIN Y PRUEBAS FORMALES


Para poder realizar pruebas formales en el Switch Transaccional es necesario, en definitiva, realizar una
implementacin de un protocolo de mensajera de los definidos en OASIS y HL7. Como realizar una implementacin de
alguno de estos protocolos se ha definido casos tipo que permitan mostrar y validar integralmente toda la solucin
aqu descripta.

Informe de Tesina

Proyecto Switch Transaccional Pgina 68 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

PRESENTACIN DE LOS CASOS

Caso: Solicitud de libre deuda municipal de un automotor


Historia del usuario (Story Board)
1. Un dueo de un automotor o un empleado de una agencia de autos solicita el libre deuda para un dominio.
2. El Switch Transaccional recibe la solicitud y en funcin de los datos de la solicitud: cdigo postal, y la zona
determina que proceso de negocio (circuito) debe ejecutarse, pasndole el control a dicho proceso.
3. El proceso de negocio, divide la solicitud de libre deuda para tres proveedores: La municipalidad, el tribunal de
faltas y el registro del automotor que le corresponde segn su zona. Solicita el libre deuda a cada uno de ellos.
4. Los proveedores procesan la solicitud y dictaminan el estado de libre deuda del dominio en cuestin. Y le
contestan al Switch Transaccional.
5. El SwitchTransaccional ensambla las respuestas obtenidas y consolida la respuesta final.

Diagrama de actividades del caso.

Informe de Tesina

Proyecto Switch Transaccional Pgina 69 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Definicin XSD del mensaje propuesto

Informe de Tesina

Proyecto Switch Transaccional Pgina 70 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Casos testeados

Caso 1 Zona A Caso 2 Zona B Caso 3 Datos no concordantes


<mensaje> <mensaje> <mensaje>
<id>00002</id> <id>00002</id> <id>00002</id>
<contribuyente> <contribuyente> <contribuyente>
<apellido>Barry</apellido> <apellido>Bail</apellido> <apellido>Perez</apellido>
<nombres>Demin</nombres> <nombres>Nora</nombres> <nombres>Pepito</nombres>
<documentos> <documentos> <documentos>
<tipo>DNI</tipo> <tipo>DNI</tipo> <tipo>DNI</tipo>
<numero>18348567</numero> <numero>18741168</numero> <numero>123456789</numero>
</documentos> </documentos> </documentos>
<domicilio> <domicilio> <domicilio>
<calle>Charcas</calle> <calle>Charcas</calle> <calle>Roca</calle>
<numero>54</numero> <numero>54</numero> <numero>32</numero>
<cp>9120</cp> <cp>9120</cp> <cp>9000</cp>
<localidad>Puerto Madryn <localidad>Puerto Madryn <localidad>Puerto Madryn
</localidad> </localidad> </localidad>
<provincia>Chubut</provincia> <provincia>Chubut</provincia> <provincia>Chubut</provincia>
<pais>Argentina</pais> <pais>Argentina</pais> <pais>Argentina</pais>
<zona>A</zona> <zona>B</zona> <zona>C</zona>
</domicilio> </domicilio> </domicilio>
</contribuyente> </contribuyente> </contribuyente>
<dominio>DSJ638</dominio> <dominio>DSJ638</dominio> <dominio>DSJ638</dominio>
</mensaje> </mensaje> </mensaje>

Informe de Tesina

Proyecto Switch Transaccional Pgina 71 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Configuracin requerida

Informe de Tesina

Proyecto Switch Transaccional Pgina 72 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 73 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 74 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Captulo 4 Conclusiones
La humanidad se encuentra hoy atravesando situaciones graves y complejas que estn impactando en todos los
sistemas: sociales, polticos, educativos, econmicos, ambientales, tecnolgicos, comunicacionales, etc. La discusin no
puede ni debe reducirse a los sistemas ideolgicos que en el pasado obraron como grandes impulsores de sistemas
cerrados y estructurados, los anlisis centrados entre los roles predominantes de lo pblico y/o lo privado, lo
econmico o lo social, la libertad o la planificacin. Debern dejar lugar al concepto de racionalidad, eficiencia y
urgencia que la realidad demanda, pero en este anlisis el hombre y su calidad de vida debern ser el imperativo y
centro de toda accin e indiscutible objeto final de cualquier sistema.
La sociedad de la informacin y especialmente la democratizacin de la comunicacin-informacin tendrn un rol
protagnico en los objetivos de lograr la negentropa de los sistemas y evitar caos de los mismos.
La calidad de vida se vern altamente impactadas por los sistemas comunicacionales, transaccionales e informticos.
En el futuro deber decidirse con muy buena informacin proveniente de indicadores adecuados y monitoreo en lnea
y en tiempo real, cada situacin de arbitraje entre los distintos sistemas y sub-sistemas de las organizaciones polticas,
sociales y econmicas.
Con informacin adecuada se podr, por ejemplo, dimensionar daos por impactos industriales en el medio ambiente,
su impacto en la salud de la poblacin involucrada, en el empleo, en la organizacin social, etc., etc. Podrn
interactuar los sistemas y equilibrarse, pudiendo resolver en forma mas adecuada que la actual, en donde
determinadas decisiones emanan de razones econmicas o polticas sin medir su impacto en las consecuencias
terribles en la calidad de vida y el costo asociado que de la misma deriva. Con la informacin en el momento que se
necesita e interactiva se podr analizar cada variable y los sistemas interactuarn mas equitativa y racionalmente.
Ms an si entendemos que en el caso planteado, por lo menos en los pases desarrollados y en vas de desarrollo, la
brecha digital no es significativa debido a que no estamos hablando del acceso de la tecnologa a las personas sino a
las organizaciones. Ms an si consideramos que las tecnologas descriptas en su mayora son de cdigo abierto y por
lo tanto de acceso pblico para su utilizacin, donde el aporte realizado por el Switch Transaccional engrosa slo un
poco ms las herramientas de conocimiento y tecnologa ya existentes, permitiendo como gran avance el
procesamiento de las transacciones orientados al contenido, utilizando para ello reglas definidas en forma genrica.
Por lo tanto el inconveniente econmico mas relevante es el de la infraestructura de comunicaciones requerida para
implementar este conjunto de herramientas e infraestructura ya que el resto de las cuestiones son inherentes a la
voluntad y decisin poltica y social de cada pas, donde lamentablemente en muchsimas ocasiones todos los recursos
existen menos la voluntad de ponerlos en marcha.
El futuro es hoy, porque si dilapidamos los recursos, habremos comprometido la razn de ser de las organizaciones
humanas que es precisamente la sociedad en si misma.

Informe de Tesina

Proyecto Switch Transaccional Pgina 75 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Bibliografa Y Referencias
1. Katz, Ignacio. Retornar al pensamiento lgico. Revista Mdicos Nmero, NEWSLETTER 82 / 24 de Marzo del
2003.
2. Jalfen, Luis J. Globalizacin y Lgica Virtual. Primera Edicin, Ediciones Corregidor, 1998.
3. Morin, Edgar. El Mtodo. Quinta Edicin, Ediciones Ctedra, 1999.
4. Barry, Jorge y Barry, Damin. La Salud en la Sociedad de la Informacin. 32 JAIIO (Jornadas Argentinas de
Informtica e Investigacin Operativa SIS 2003 (Simposio de Informtica y Salud)
5. Varios Autores. eGov-Interop'05 Conference. Observatory On Interoperable eGovernment Services.
6. Helland, Pat. Microsoft Corporation. Datos externos frente a datos internos.
7. Daz Toledano, Moiss Daniel. Web Services -Introduccin y Escenarios para su Uso.
8. OASIS. Organization for the Advancement of Structured Information Standards: http://www.oasis-
open.org/home/index.php
9. Bray Tim. Sun on Open Office XML ISO Certification.
http://www.tbray.org/ongoing/When/200x/2004/09/24/SmartEC.
10. Carrera, Daniel. The Future Is Open: What OpenDocument Is And Why You Should Care.
http://www.groklaw.net/article.php?story=20050130002908154.
11. Seely, Scott. WS-Security. Microsoft Corporation. Octubre de 2002.
http://www.microsoft.com/spanish/msdn/articulos/archivo/121202/voices/understw.asp
12. Magster Freh, Stephan Alexander. Analysis of global eID with focus on Interoperability by using the TFI
Model. Marzo del 2005. Departament of Information systems London School of Economics and Political
Science.
13. Michelson, Adam. SOA Versus the Appliance. Mayo del 2006. revista LinuxWorld.
14. Panda, Debu. An Introduction to Service-Oriented Architecture from a Java Developer Perspective. Enero del
2005. http://www.onjava.com
15. Angelov, Samuil & Grefen, Paul. A Framework for Analysis of B2B Electronic Contracting Support. University of
Twente, The Netherlands.
16. Laskey, Ken. Reference Model for Service Oriented Architecture. Marzo 2006. Developed by OASIS SOA
Reference Model Technical Committe.
17. Varios autores. SOA Application Learning Trail. Netbeans.org. http://www.netbeans.org/kb/trails/soa.html
18. Varios autores.Java EE Applications Learning Trail. http://www.netbeans.org/kb/trails/java-ee.html
19. David Hunter, Kurt Cagle, Chris Dix et al, Beginning XML, 2nd Edition: XML Schemas, SOAP, XSLT, DOM, and
SAX 2.0. Wrox Press 2003.
20. Kim Topley, Java Web Services in Nutshell. O'ReillyPub. Junio 2003.
21. Englander, Robert. Java and SOAP. O'Reilly.
22. St. Laurent, Simon & Johnston, Joe & Dumbil Edd. Programming Web Services with XML-RPC. O'Reilly

Informe de Tesina

Proyecto Switch Transaccional Pgina 76 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Anexos
Anexo A - XML Tags usados para definir un mensaje SOAP
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap,org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePricexmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>

Ejemplo:
El cliente necesita saber que producto corresponde con el cdigo ID 827635
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>827635</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>
El Servicio Web responde con el siguiente mensaje:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName>
<productID>827635</productID>
<description>3-Piece luggage set. Black Polyester.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>

Informe de Tesina

Proyecto Switch Transaccional Pgina 77 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Anexo B Proceso General de Implementacin

INTRODUCCIN
El Proceso General de Implementacin (PGI) provee un mtodo disciplinado de asignacin de tareas y
responsabilidades aplicable al desarrollo de proyectos de tecnologa de la informacin.
El principal objetivo del PGI es el de asegurar la calidad de la implementacin, cumpliendo con las necesidades y
expectativas del Proyecto, dentro de un calendario y un presupuesto predecibles.
La siguiente figura muestra la arquitectura del proceso:

PGI - Visin General


Fases
Lanzamiento Elaboracin Refinamiento Cierre
Tareas
Administracin de Proyecto

Relevamiento de Negocio
Reingeniera de Procesos

Requerimientos

Solucin

Implementacin

Migracin e Integracin

Prueba Formal

Puesta en Marcha

Infraestructura

Control de Configuracin

Aseguramiento de Calidad

Inicial Elab 1 Elab 2 Refin 1 Refin 2 Refin 3 Final

Iteraciones

El PGI tiene dos dimensiones:


El eje horizontal representa el tiempo, y muestra los aspectos relacionados con el ciclo de vida del proceso, a
medida que el mismo progresa cronolgicamente.
El eje vertical representa las tareas centrales del proceso, los cuales agrupan aquellas actividades que se
relacionan entre si en forma natural.
La primera dimensin representa el aspecto dinmico del proceso, y est expresado en trminos de fases, iteraciones,
e hitos.
La segunda dimensin representa el aspecto esttico del proceso, y est expresado en trminos de tareas, actividades,
roles, artefactos.

Informe de Tesina

Proyecto Switch Transaccional Pgina 78 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Las tareas se clasifican en:


Verticales: tareas directamente relacionadas con el objetivo de efectuar la implementacin de la Solucin; por
ejemplo: Relevamiento de Negocio, Anlisis y Diseo, Construccin, etc..
Transversales: tareas que se relacionan solo indirectamente con el objetivo de efectuar la implementacin, y
estn orientadas a dar soporte o servicios a las tareas verticales. Pueden ser vistas como ciclos o rutinas que
se repiten con mnimas variantes a lo largo del proyecto. El ejemplo tpico de este tipo de tareas es la
Administracin del Proyecto.
El diagrama anterior muestra cmo vara el nfasis a lo largo del tiempo (los recuadros con relleno slido indican
mayor nfasis que los recuadros con relleno punteado). Por ejemplo, en las primeras iteraciones se pone ms nfasis
en las actividades relacionadas con el relevamiento de las necesidades del Cliente y el anlisis de las soluciones a las
mismas, mientras que en las ltimas iteraciones el nfasis est puesto en las actividades relacionadas con la
implementacin, migracin de datos, prueba formal y puesta en marcha de la implementacin.
La base terica del PGI se sustenta en dos principios fundamentales:
La utilizacin de un mtodo iterativo e incremental de implementacin.
El empleo de casos de uso para la administracin de los requerimientos.

IMPLEMENTACIN ITERATIVA

El mtodo iterativo plantea una aproximacin progresiva al resultado final en la concrecin del proyecto, la cual se va
desarrollando por medio de la ejecucin de sucesivas iteraciones, cada una de las cuales va agregando nueva
funcionalidad a la ya disponible, a la vez que produce las mejoras que el Cliente o el Proyecto requiera sobre la
funcionalidad implementada en iteraciones anteriores (aspecto dinmico del proceso).
Dentro de cada iteracin se repite con nfasis variable un ciclo de tareas que se inicia con el relevamiento de los
requerimientos del Cliente, y concluye con la puesta en marcha de una porcin de la Solucin (aspecto esttico del
proceso).
Para permitir este avance gradual, el mtodo prev como cierre de cada iteracin la entrega al Cliente de una versin
utilizable de la Solucin, y fomenta el uso de prototipos a lo largo de la implementacin.
El Cliente comprueba peridicamente la validez de las soluciones planteadas no solo por medio de la revisin de la
documentacin generada, sino tambin a travs de de la utilizacin de las porciones de la Solucin que van siendo
implementadas.
Las principales caractersticas del mtodo son las siguientes:
La Solucin se construye en forma incremental, implementando los requerimientos gradualmente.
Se dispone peridicamente de una versin utilizable de la Solucin.
El equipo de trabajo aprende y mejora su rendimiento a lo largo del proyecto.
El proceso se refina a lo largo del proyecto.
El siguiente diagrama muestra la mecnica del proceso iterativo:

Informe de Tesina

Proyecto Switch Transaccional Pgina 79 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Tareas
I nicio de Fase Verticales

Tareas
Transversales

Fase 1

Fin de Fase

Avance del I nicio de Fase


P royecto

Varias
it eraciones
en cada Fase
Fase n

Fin de Fase

CASOS DE USO
Los Casos de Uso (CU) constituyen una metodologa de anlisis de sistemas utilizada para identificar, clarificar y
organizar requerimientos. Cada CU est compuesto por un conjunto de interacciones entre actores (personas fsicas,
personas jurdicas, aplicaciones, mquinas, etc.) dentro de un entorno especfico, y en relacin a una meta particular.
Objetivo que quiere alcanzar el actor principal.
A su vez, cada CU contiene un escenario principal, y diferentes excepciones derivadas de los pasos del escenario
principal. Por lo tanto, un CU puede ser visto como una coleccin de escenarios.
La vista de escenarios de CU es esencial para la administracin de los requerimientos, especialmente desde el punto
de vista de su priorizacin e implementacin dentro del proyecto.
A su vez los CU son derivados de Historias del usuario (Story Boards) que son el relato lineal de las actividades que
desarrolla o ejecuta un actor en particular. Desde esta perspectiva las historias de los usuarios son casos de uso no
refinados que el analista convierte en caso de uso.
Desde un punto de vista general, un CU o conjunto de CU tiene las siguientes caractersticas:
Permite organizar requerimientos funcionales.
Modela las metas de las interacciones entre los actores.
Registra los escenarios dentro de los que se producen las interacciones entre los actores.
Describe un flujo principal de eventos, y posibles flujos alternativos excepcionales.
Los CU pueden ser utilizados con distintos propsitos: desarrollar los requerimientos de un proyecto de desarrollo o
implementacin de software, validar diseos, efectuar pruebas formales, etc. Una de las ventajas principales de su
utilizacin deriva del hecho de que los CU permiten captar los requerimientos desde el punto de vista del Cliente (o del
usuario) y de las metas perseguidas por el mismo. Los caos de uso se centran en los objetivos que deben alcanzar las
personas dentro de una organizacin y por ende capturan los objetivos organizacionales.

Informe de Tesina

Proyecto Switch Transaccional Pgina 80 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Las principales caractersticas de los CU son las siguientes:


Cada CU describe fundamentalmente una meta a alcanzar o una necesidad a cubrir con respecto del negocio o
de la automatizacin de tareas o procesos.
Un CU captura el contrato entre los actores internos de una organizacin acerca de sus responsabilidades en ella
con respecto a dicha meta en particular.
Un CU describe las responsabilidades de la Solucin bajo las distintas condiciones en las cuales debe responder
ante los requerimientos de los actores.
Un CU representa una respuesta a un determinado evento de negocio.
Dada la diversidad de propsitos con los que son utilizados los CU, entre los mismos se puede encontrar una
gran variedad de formatos, estilos de escritura, y nivel de formalidad. Por lo tanto, los CU pueden:
Tener distintos alcances, describiendo el comportamiento de una organizacin completa, de un sistema
funcionando dentro de dicha organizacin, o de un componente dentro de un sistema.
Tener distintos niveles de objetivo: nivel estratgico, nivel de tareas, nivel de sub-funcin.

Tener distintos niveles de definicin: informal, descripcin del escenario principal, descripcin de
extensiones.
Pertenecer a distintos tipos: reales o abstractos.

Pertenecer a distintas clases:


CU de Usuario: Describe los objetivos del usuario con respecto a un sistema. Rescata las necesidades
operacionales del usuario y de su entorno. Identifica los pasos a seguir dado un objetivo. Evala un
escenario principal y sus excepciones.
CU de Negocio: Describe los objetivos del negocio y las necesidades de automatizacin y control. Identifica a
los responsables del negocio, su visin y sus necesidades. Permiten definir el alcance del negocio.
Proceso: Describe los procesos, tanto automatizados como manuales. Establece el flujo principal de tareas
del proceso, y los flujos alternativos que dependen de las situaciones excepcionales. Enumera eventos
disparadores, pre-condiciones y garantas mnimas del flujo de tareas.
Los casos de uso de negocio tienen un rol fundamental ya que el alcance global del proyecto est determinado por el
conjunto de CU que se hayan identificado. De esta manera, estos constituyen la base sobre la cual se efectan las
estimaciones y la planificacin de todo el proyecto.
Por este motivo resulta muy importante que en las primeras iteraciones se haga el mejor intento por identificar la
totalidad de los CU ms relevantes del negocio, ya que los mismos constituyen el principal factor que gua y dirige los
esfuerzos de implementacin.
Los CU relevados al inicio del proyecto pueden luego ir siendo refinados e implementados gradualmente a lo largo del
resto de las iteraciones.
Aquellos CU de negocio que estn fuera del alcance deben derivar en mejoras a la Solucin o en adecuaciones
especficas realizadas dentro del marco del proyecto.
Por razones de estandarizacin, el PGI adopta un formato especfico de CU, cuyos detalles pueden ser consultados en
la descripcin del artefacto correspondiente. A continuacin se muestra un ejemplo de formato de CU:

Informe de Tesina

Proyecto Switch Transaccional Pgina 81 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

ID: CU-xxxx (numerar secuencialmente, ajustar a la derecha y rellenar con ceros a la


izquierda).
Objetivo: Objetivo en verbo activo y enunciado desde la perspectiva del actor principal.
Actor principal: Nombre o descripcin del actor principal (el inters del mismo est
representado por el objetivo del caso de uso).
Stakeholders e intereses: Nombre stakeholder + Inters del mismo sobre el caso de uso
(estos intereses constituyen objetivos secundarios del caso de uso).
Descripcin: Descripcin breve, simple y especfica del caso de uso. Debe servir como
ampliacin del objetivo, y como precalentamiento del desarrollo del escenario habitual y sus
extensiones. Puede aportar background o informacin que ponga en contexto al caso de uso.
No debe confundrselo con un escenario.
Garanta mnima: Indicacin del estado de mnima propuesto para el caso de uso en funcin
de las extensiones de falla.
En caso de xito garantiza: Indicar el estado final del caso de uso en caso de xito del
mismo.
Precondiciones: Requisitos del caso de uso para ser ejecutado.
Triggers: Eventos disparadores del caso de uso. Pueden ser otros casos de uso.
Escenario principal:
Paso 1. Paso 2 ........ Paso N
Extensiones:
1.1. (Paso 1 de la excepcin 1).
1.1.a (Excepcin al paso 1 de la excepcin 1).
1.2. (Paso 2 de la excepcin 1).

Una vez recopilados los CU del proyecto, los mismos se organizan dentro de grupos de casos de uso, los cuales
agrupan un conjunto de CU relacionados entre si (por ejemplo, por el hecho de pertenecer a un mismo rea del
negocio, o por tener un determinado conjunto de actores en comn).

ELEMENTOS DEL PROCESO ITERATIVO

HITOS
Constituyen los puntos en los que una iteracin finaliza formalmente, e implican (en la casi totalidad de los casos) un
release de la implementacin.

FASES
Desde el punto de vista de la Administracin del Proyecto, el proceso se descompone a lo largo del tiempo en varias
fases secuenciales, cada una de las cuales concluye en un hito principal. Esencialmente, una fase se puede definir
como el perodo de tiempo transcurrido entre dos hitos principales.

Informe de Tesina

Proyecto Switch Transaccional Pgina 82 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Al finalizar cada fase se realiza una evaluacin para determinar si se han alcanzado los objetivos de la misma. Si el
resultado de la evaluacin es satisfactorio, el proyecto avanza hacia la prxima fase.
Tal como puede apreciarse en el Diagrama de Visin General, las fases son dismiles entre si en cuanto a esfuerzo y
planificacin.

ITERACIONES
Una iteracin puede ser vista como un mini-proyecto dentro del proyecto general, dentro del cual se ejecutan (con un
nfasis que vara de acuerdo al grado de avance del proyecto) todas las tareas que componen el PGI, resultando en la
gran mayora de los casos en una implementacin completamente funcional (aunque parcial) de la Solucin General.
Cada iteracin comienza con una planificacin de las actividades, y culmina con un release de la implementacin, el
cual puede o no ser puesto en produccin.

ROLES
Un rol define el comportamiento y las responsabilidades de un individuo o un grupo de individuos que trabajan
conjuntamente dentro del contexto del equipo de trabajo que realiza la implementacin.
Cada rol tiene un conjunto cohesivo de actividades asignadas. Estas actividades se relacionan entre si, estn acopladas
funcionalmente, y se desarrollan ms eficientemente si son realizadas por un mismo individuo.
Asimismo, cada rol es responsable de la generacin de un determinado conjunto de artefactos.
Se debe notar que un rol no equivale a un individuo. La asignacin entre individuos y roles, se efecta durante el inicio
del proyecto, y puede implicar que un mismo individuo desempee varios roles simultneamente, y/o que un mismo
rol sea desempeado por varios individuos simultneamente.

ACTIVIDADES
Cada actividad representa una unidad de trabajo cuya realizacin le puede ser solicitada a cualquier individuo que
desempee el rol al cual est asignada la actividad. La actividad debe tener un propsito bien definido, usualmente
expresado en trminos de la creacin o la actualizacin de determinados artefactos. La granularidad de cada actividad
debe ser tal que permita que la misma sea utilizada como un elemento significativo de planificacin y evaluacin del
progreso del proyecto.
Los roles tienen asignadas actividades, las cuales definen el trabajo que deben desarrollar. Una actividad es algo que
realiza un rol, que tiene un resultado significativo dentro del contexto del proyecto.
Las actividades pueden ser repetidas varias veces a lo largo del proyecto, especialmente dentro de distintas
iteraciones, refinando y expandiendo progresivamente el alcance de los artefactos resultantes de la misma, siempre
bajo la responsabilidad del mismo rol (pero no necesariamente del mismo individuo).
Las actividades se descomponen en pasos, los cuales pueden pertenecer a tres categoras:
Pasos de elaboracin, en los cuales se comprende la naturaleza de la tarea, se recopilan y examinan los
artefactos a utilizar, y se formula el resultado.
Pasos de desarrollo, en los cuales se crea o actualiza el contenido de los artefactos implicados.
Pasos de revisin, en los cuales se compara el resultado obtenido contra un criterio determinado.
Se debe tener en cuenta que no todos los pasos son necesariamente desarrollados cada vez que se realiza la
actividad.

ARTEFACTOS
Los artefactos representan productos finales o intermedios resultantes del desarrollo de las actividades del proyecto.
Se utilizan para capturar y comunicar informacin entre todos los individuos que participan del mismo.

Informe de Tesina

Proyecto Switch Transaccional Pgina 83 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Los roles utilizan los artefactos para desarrollar las actividades previstas en el proceso, y producen o actualizan
artefactos como resultado del desarrollo de dichas actividades. Los artefactos son responsabilidad de un nico rol, de
manera de promover la idea de que cada elemento del proceso deba ser responsabilidad de una persona especfica. Si
bien una nica persona es la duea del artefacto, el mismo puede ser utilizado por muchas otras personas, incluso
produciendo actualizaciones al mismo.
Cada actividad tiene un conjunto de artefactos de entrada y otro de salida.
Los artefactos deben estar sujetos a la administracin de configuraciones, y por lo tanto, debe existir un mecanismo
de versiones de los mismos.
Cada artefacto tiene asociada una plantilla, la cual establece el modelo o prototipo del artefacto, y permite lograr una
estandarizacin del contenido del mismo a lo largo del proyecto, sin importar cules fueron las personas que
intervinieron en el desarrollo del artefacto.

TAREAS
La mera enumeracin de roles, actividades y artefactos no constituye en si un proceso. Para ello, es necesario adems
definir cmo se conjugan entre si todos estos elementos, especificando secuencias significativas de actividades que
produzcan un resultado evaluable, y definir cmo interactan entre si los distintos roles.
Las definiciones precedentes se agrupan dentro de tareas, segn un determinado criterio. De esta manera, una tarea
es una coleccin de actividades relacionadas entre si, que pertenecen a un mismo rea de inters dentro del
proyecto general.
Cada tarea es representada dentro de un diagrama que muestra una secuencia semi-ordenada de actividades que
deben ser realizadas para alcanzar cierto resultado. El trmino semi-ordenada enfatiza el hecho de que las tareas no
representan la planificacin del trabajo real a desarrollar, ya que no describen la opcionalidad de las actividades, ni la
naturaleza iterativa de los proyectos. Sin embargo, esta forma de organizar las actividades permite facilitar el
entendimiento del proceso, subdividindolo en partes ms pequeas que el todo.
A continuacin se muestra un ejemplo de diagrama de tarea:
Para cada tarea, el proceso incluye un diagrama de detalle de la misma, en el cual se muestra el conjunto concreto de
actividades a desarrollar dentro de la tarea, los roles responsables de cada una de dichas actividades, los artefactos
que se deben utilizar para el desarrollo de dichas actividades, y los artefactos resultado del desarrollo de dichas
actividades.

TAREA: GESTIN DE PROYECTO


(Solo Iteracin Inicial)

Lanzamiento del
Proyecto

(Iteraciones subsecuentes)

Evaluar alcance y
riesgos del Proyecto

Planificar Iteracin

Desarrollar Plan
Monitorear y Controlar
General del Proyecto
el Proyecto
Administrar Iteracin

(Cierre de Proyecto)

(Cierre de Fase)

(Cierre de Iteracin)
Cerrar Fase

Cerrar Proyecto

Evaluar alcance y
riesgos del Proyecto

Informe de Tesina

Proyecto Switch Transaccional Pgina 84 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

El sentido de los diagramas de detalle de las tareas es el de hacer evidente que las actividades de una tarea no se
realizan secuencialmente, ni se realizan todas simultneamente. El diagrama de detalle muestra en qu casos es
recomendable trabajar por medio de talleres o reuniones de equipo en el transcurso del desarrollo de una tarea.
Tpicamente se trabaja en paralelo en ms de una actividad, y al hacerlo se tiene en cuenta ms de un artefacto.

PROCESO GENERAL DE IMPLEMENTACIN - GENERALIDADES

ANLISIS DE ALCANCE PREVIO AL PROYECTO

El PGI presupone que como parte del proceso del estudio de factibilidad, se ha efectuado en forma conjunta con el
Cliente una fase durante la cual se realiza un diagnstico de la situacin y un relevamiento inicial del negocio
desarrollado por el Cliente.
Esta fase previa se denomina anlisis de alcance. El mismo se ejecuta en forma previa al inicio del proyecto, y no
forma parte del mismo.
El anlisis de alcance se realiza en base a un modelo de encuesta que permite evaluar la situacin del Cliente, y tiene
una importancia fundamental y un impacto directo sobre el proyecto, ya que como resultado del mismo se debe estar
en condiciones de efectuar las estimaciones iniciales sobre el volumen y la complejidad del proyecto.
Las estimaciones iniciales se efectan sobre el alcance marco enunciado como resultado del anlisis de alcance.
Como mnimo, el alcance marco debe constar de:
Una enumeracin de los componentes de la Solucin definidos por el Cliente, y el propsito con el cual han sido
incluidos en el proyecto.
Una matriz de objetivos macro o de nivel cero, la cual debe contener dentro de lo posible, la versin informal
de los casos de uso relacionados con dichos objetivos.
El resultado del diagnstico efectuado se debe tomar como un pre-anlisis de factibilidad, y debe garantizar que no
surjan imprevistos considerables una vez iniciado el proyecto.
Una vez efectuado el anlisis de alcance, nada de lo que se incluya posteriormente en el proyecto debe superar el
alcance marco inicial. El surgimiento de objetivos de negocio o casos de uso adicionales, no incluidos en forma
original, debe implicar una contratacin adicional por parte del Cliente, a travs de ampliaciones al proyecto primitivo.
Adicionalmente, el anlisis de alcance debe incluir tambin un detalle de los recursos que el Cliente se compromete a
aportar al proyecto, discriminados segn los roles previstos por el PGI, y detallando las capacidades de cada recurso
comprometido.

PLANIFICACIN
La Administracin del Proyecto se efecta basndose en dos artefactos fundamentales:
Plan General
Este artefacto se crea durante la Fase de Lanzamiento.

Rene toda la informacin necesaria para administrar el proyecto, y es actualizado constantemente a lo


largo del mismo.
Contiene el cronograma macro o de alto nivel de las iteraciones a ejecutar.

Detalla los hitos que determinan la finalizacin de cada una de las iteraciones.

Plan de Iteracin
Cada vez que se inicia una nueva iteracin se crea una nueva instancia de este artefacto.

Informe de Tesina

Proyecto Switch Transaccional Pgina 85 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Por lo tanto, existe un ejemplar del mismo por cada iteracin ejecutada.

Contiene el cronograma detallado de cada iteracin.

Debe estar alineado con el Plan General.

Tiene como objetivo la produccin de una nueva versin de la Solucin que est siendo implementada, y de
los artefactos producidos durante el proceso.
En general, todas las tareas del proyecto (ver Tareas del PGI), se ejecutan en todas las iteraciones (salvo mnimas
excepciones).
Los planes utilizados para la Administracin del Proyecto establecen las polticas a utilizar para las distintas actividades
del proyecto; son artefactos mayormente estticos, en el sentido que se formulan tempranamente y luego sufren
ajustes mnimos.
Importante:
La puesta en prctica de las polticas establecidas en los planes implica la generacin de artefactos que registren el
aspecto dinmico de dichas polticas, es decir, la instanciacin de ciertos aspectos establecidos en los planes.
Supongamos, por ejemplo, que el Plan de Aseguramiento de la Calidad establece que debern calcularse ciertas
mtricas, y utilizarse ciertos criterios para evaluar la satisfaccin del cliente. Estas polticas deben luego concretarse en
determinados artefactos, dentro de los cuales se registrarn los valores reales calculados para las mtricas en cada
hito del proyecto, as como tambin el resultado de la evaluacin de la satisfaccin del cliente, es decir, el grado de
satisfaccin expresado con respecto a los criterios preestablecidos en el plan.
El PGI2 contiene guas y plantillas para facilitar el desarrollo de todos los planes previstos en el proceso, pero salvo
algunas excepciones (Lista de Riesgos, Resultados de Prueba Formal, etc.), no contiene guas y plantillas exhaustivos
para cada uno de los artefactos dinmicos mencionados, quedando los mismos sujetos a lo que se establezca dentro
de cada proyecto.
En resumen: en este sentido, los planes establecen qu se debe hacer, las guas establecen cmo se debe hacer, y la
forma en que se registre el resultado y avance de las actividades se deja librada a la ejecucin de cada proyecto.

ITERACIONES
Acople entre iteraciones
Se debe prever un determinado nivel de interdependencia o acople entre el trabajo desarrollado en dos iteraciones
sucesivas.
Esta relacin se da fundamentalmente entre las tareas de Relevamiento de Negocio y Solucin, por un lado, y las
tareas de Implementacin, Prueba Formal y Puesta en Marcha, por otro.
Para comprender mejor esta situacin, se presenta el siguiente ejemplo:
Extracto del contenido de la Iteracin n:

Relevar y desarrollar nuevos CU y sus respectivas extensiones: escenarios.

Extracto del contenido de la Iteracin n+1:


Relevar y desarrollar nuevos CU.

Refinar los CU desarrollados durante la iteracin anterior.

Informe de Tesina

Proyecto Switch Transaccional Pgina 86 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Implementar los escenarios seleccionados en el Plan de la Iteracin, definidos en la iteracin anterior.

Prueba formal de los escenarios implementados.

Extracto del contenido de la Iteracin n+2:


Relevar y desarrollar nuevos CU y sus respectivas extensiones: escenarios.

Refinar los CU desarrollados durante la iteracin anterior.

Implementar los escenarios seleccionados en el Plan de la Iteracin, definidos en la iteracin anterior.

Prueba formal de los escenarios implementados.

Etc.
El ejemplo est basado en actividades relacionadas con los CU, pero el mecanismo general es aplicable al resto de los
artefactos del proceso.
Debido a que los roles responsables de las distintas tareas no son los mismos, este tipo de encadenamiento entre
iteraciones permite lograr cierto grado de paralelizacin del trabajo: una parte del equipo se dedica a generar
contenido para la prxima iteracin, mientras otra parte se concentra en el contenido propio de la iteracin en curso.
Por otra parte, el ejemplo presentado permite apreciar los desafos que plantea el mtodo iterativo a la Administracin
de Proyecto, a la Administracin del Cambio (coordinacin con el impacto del cambio en los procesos del Cliente), a la
Administracin del Riesgo, y a la Administracin de Configuraciones (existirn tantas versiones de la implementacin
como iteraciones se efecten).

Cierre de iteraciones
Al finalizar cada iteracin se efecta un cierre formal de la misma, durante el cual se evala el resultado de la
iteracin, determinando:
Si se alcanzaron los objetivos previstos en la planificacin inicial de la iteracin
Si el grado de calidad obtenido es satisfactorio
Si se redujeron o eliminaron los riesgos detectados.
Una vez efectuado el cierre de una iteracin, y como primer paso dentro de la siguiente, se procede a planificar la
nueva iteracin. El resultado de la evaluacin realizada al cierre de la iteracin anterior constituye uno de los
principales elementos utilizados como entrada de la planificacin de la iteracin que se inicia.
Adicionalmente, y de acuerdo al resultado de la evaluacin, puede surgir la necesidad de efectuar ajustes al Plan
General y a la Lista de Riesgos del proyecto.
Estas evaluaciones constituyen una de las ventajas principales del mtodo iterativo, ya que representan una
oportunidad de revisar frecuente y metdicamente el progreso y los riesgos del proyecto, y de tomar las decisiones
necesarias para mantener al mismo dentro de la direccin apropiada.

Duracin de las iteraciones


A fines de mantener acotada la duracin del proyecto, y de mantener el impulso del mismo en forma constante, se
debern planificar iteraciones relativamente breves. Lo ideal es que las mismas se extiendan por un lapso de entre 2 y

Informe de Tesina

Proyecto Switch Transaccional Pgina 87 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

3 semanas. En un proceso iterativo, esto significa que a lo largo del proyecto habr una nueva versin operable de la
Solucin cada 2 o 3 semanas, independientemente del porcentaje de los requerimientos que cada una de las mismas
cubra.

FASES E ITERACIONES DEL PGI


A continuacin se enumeran las fases e iteraciones sobre las que se estructura el PGI, las cuales definen el proceso
desde el punto de vista dinmico:

FASE DE LANZAMIENTO
La Fase de Lanzamiento representa el punto de despegue del proyecto, y tiene como meta fundamental lograr el
consenso de todas las partes interesadas en el proyecto con respecto a los siguientes aspectos:
Propsito y alcance del proyecto.
Riesgos preponderante, hechos relevantes y principales supuestos.
Formacin de comits de trabajo, y establecimientos de roles y responsabilidades.
Compromiso con respecto a las responsabilidades asumidas.
Arquitectura de la Solucin.
Mecanismos de control de calidad a implementar.
Estrategia y metodologa a utilizar.
Por lo general la Fase de Lanzamiento consta de una nica iteracin, la cual constituye la iteracin inicial del proyecto.
Con respecto a la tarea de Puesta en Marcha, independientemente del grado de avance que se logre con el
Relevamiento de Negocio, como resultado de esta primera iteracin se debe obtener mnimamente la instalacin de
todos las herramientas de infraestructura de la Solucin que se requieran usar para poder ejecutar y elaborar todos los
artefactos de la misma. Desde herramientas ofimticas hasta herramientas de anlisis y desarrollo.
Con respecto a la tarea de Administracin de Proyecto, el resultado de esta fase es la versin inicial del Plan General
del proyecto.
Durante el transcurso de esta fase se debe establecer la infraestructura general de soporte del proyecto, en cuanto a
la instalacin del hardware y software necesario para el funcionamiento de la Solucin, la generacin de ambientes de
implementacin, la creacin de instancias de base de datos, y la preparacin de la infraestructura edilicia y de
comunicaciones.
En caso de que se considere necesario, y especialmente si es la primera oportunidad en que el equipo de
implementacin utiliza el PGI, puede incluirse en la Fase de Lanzamiento una breve capacitacin al mismo acerca del
proceso, con el objetivo de que todos los recursos estn alineados desde el punto de vista de la metodologa de
implementacin a utilizar.

FASE DE ELABORACIN
La Fase de Elaboracin tiene como objetivo la recopilacin de la mayor parte de los Casos de Uso a implementar en el
proyecto, y el desarrollo de la mayor parte de la Arquitectura de la Solucin y de los Artefactos que describen la
Solucin. El objetivo en este punto es que durante la siguiente fase del proyecto (Fase de Refinamiento), las
actividades sobre los artefactos mencionados tiendan a concentrarse exclusivamente en el refinamiento de lo
elaborado durante esta fase.
Por lo general la Fase de Elaboracin consta de dos iteraciones, dentro de las que se efecta el desarrollo del 95% de
la Arquitectura de la Solucin y los Casos de Uso a implementar dentro del proyecto.

Informe de Tesina

Proyecto Switch Transaccional Pgina 88 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE DE REFINAMIENTO
Durante la Fase de Refinamiento se registra una reduccin significativa en las tareas de Relevamiento de Negocio y
Solucin; las actividades sobre estas reas del proceso se deben concentrar en la depuracin y refinacin de la
Arquitectura de la Solucin y los Casos de Uso recopilados durante la Fase de Elaboracin. El objetivo en este punto es
que durante la siguiente fase del proyecto (Fase de Cierre), la actividad sobre estas reas tienda a ser nula.
Asimismo, esta es la fase del proyecto en la que se efecta el mayor esfuerzo con respecto a las tareas de
Implementacin y Prueba Formal de la implementacin, procedindose a plasmar las soluciones enunciadas en el
Documento de Solucin.
Con respecto a la tarea de Migracin de datos e integracin de aplicaciones, como resultado de la ejecucin de esta
fase se debe finalizar el desarrollo de la migracin de datos. El objetivo en este punto es que finalizada la Fase de
Refinamiento, la nica actividad que quede pendiente en relacin a esta rea sea la ejecucin de la migracin de datos
definitiva (la cual debe realizarse en la ltima iteracin del proyecto, dentro de la Fase de Cierre).
Por lo general la Fase de Refinamiento consta de tres o ocho iteraciones, segn el volumen del proyecto, cada una de
las cuales aporta sucesivamente un mayor grado de refinamiento a la implementacin.

FASE DE CIERRE
Los principales objetivos de la Fase de Cierre son los siguientes:
Cierre de la Arquitectura de la Solucin y del Documento de Solucin.
Migracin de datos definitiva.
Puesta en marcha global.
Desconexin de sistemas legados, si existen.
Es decir que durante el transcurso de esta fase se debe lograr que la implementacin de la Solucin est
completamente disponible para su utilizacin efectiva por parte de los usuarios finales (tanto desde el punto de vista
de la implementacin de la totalidad de los CU recopilados, como desde el punto de vista de la completitud de la
implementacin de cada uno de dichos CU), de manera que se pueda proceder a la desconexin definitiva de los
sistemas legados.
Con respecto a las tareas verticales, al iniciarse esta fase las tareas de Relevamiento de Negocio, Solucin e
Implementacin deben haberse completado casi totalmente, previendo nicamente:
La realizacin de ajustes finales mnimos a la Arquitectura de la Solucin, Casos de Uso y Documento de
Solucin.
La implementacin de los CU definidos durante la iteracin anterior.
La ejecucin de la migracin definitiva de datos (en caso de que la misma sea necesaria).
Por lo tanto, el esfuerzo aplicado dentro de esta fase debe concentrarse mayormente en las tareas de Prueba Formal
(incluyendo una prueba formal global de la implementacin) y Puesta en Marcha.
Al finalizar la Fase de Cierre se deben haber cumplido los objetivos previstos, y el proyecto tiene que estar en
condiciones de ser cerrado.
Por lo general la Fase de Cierre consta de una nica iteracin, la cual constituye la iteracin final del proyecto.

ROLES DEL PGI


A continuacin se incluye una descripcin resumida de todos los roles previstos en el PGI:

Informe de Tesina

Proyecto Switch Transaccional Pgina 89 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Rol Comit de Direccin Abreviatura CDI

El Comit de Direccin resuelve los conflictos que pudiesen surgir entre las partes
intervinientes en el proyecto, toma las decisiones de alto nivel y es responsable de la
solucin final de implementacin.
Es el responsable de la toma decisiones con respecto a los cambios de alcance que
pudieran surgir a lo largo del proyecto.
Descripcin
Es responsable de la economa global y de garantizar los recursos necesarios para el
correcto desarrollo del proyecto.
El CDI est conformado por Directores y Gerentes de Proyecto, asistidos por los Lderes de
Proyecto. En su integracin participan representantes de todas las organizaciones y reas
que participan del proyecto.

Rol Comit de Ejecucin Abreviatura CEJ

El Comit de Ejecucin organiza y controla las actividades, asigna prioridades, administra y


analiza los riesgos.
Administra, prioriza y selecciona los escenarios a implementar en cada iteracin del
Descripcin proyecto.
El Comit de Ejecucin est conformado por Lderes de Proyecto, asistidos por Consultores
Funcionales, y por Usuarios Clave. En su integracin participan representantes de todas las
organizaciones y reas que participan del proyecto.

Rol Comit de Control de Cambios Abreviatura CCC

El Comit de Control de Cambios es el responsable de establecer las polticas y de


administrar el Control de Cambios sobre la solucin que est siendo implementada.
Est compuesto por integrantes pertenecientes a todas las organizaciones y reas que
Descripcin
participan del proyecto.
Dependiendo de la envergadura del proyecto, este rol puede estar cubierto por el Comit
de Ejecucin.

Rol Comit de Control de Calidad Abreviatura CCA

El Comit de Control de Calidad es el responsable de establecer las polticas y de


administrar el Control de Calidad del proyecto.
Est compuesto por integrantes pertenecientes a todas las organizaciones y reas que
Descripcin
participan del proyecto.
Dependiendo de la envergadura del proyecto, este rol puede estar cubierto por el Comit
de Ejecucin.

Informe de Tesina

Proyecto Switch Transaccional Pgina 90 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Rol Gerente de Proyecto Abreviatura GP

El Gerente de Proyecto es el responsable de dirigir el proyecto, y de patrocinarlo desde los


aspectos polticos, econmicos y ejecutivos, garantizando la disponibilidad de los recursos
comprometidos.
Descripcin

Rol Lder de Proyecto Abreviatura LP

El Lder de Proyecto establece la estrategia y la planificacin del proyecto, monitorea el


Descripcin estado del mismo, administra los riesgos y contingencias, dirige al equipo de trabajo, y
gestiona la infraestructura edilicia y de comunicaciones.

Rol Consultor Funcional Abreviatura CF

El Consultor Funcional releva y analiza las caractersticas del negocio, desarrolla los casos
Descripcin de uso de negocio, y define cmo se implementar la Solucin para resolver dichos casos
de uso.

Rol Consultor Tcnico Abreviatura CT

El Consultor Tcnico administra la infraestructura tecnolgica y los ambientes de


implementacin, implementa las soluciones que requieran del desarrollo de software,
Descripcin
desarrolla migraciones e integraciones entre aplicaciones, y efecta el Control de
Configuracin.

Rol Testeador Abreviatura TE

Descripcin El Testeador ejecuta las pruebas formales de las soluciones implementadas.

Rol Administrador de Sistema Abreviatura ASIS

El Administrador de Sistema es responsable de la infraestructura del proyecto con respecto


Descripcin
al software y al hardware.

Rol Administrador de Base de Datos Abreviatura ABD

El Administrador de Base de Datos es responsable de la infraestructura del proyecto con


Descripcin
respecto a las bases de datos requeridas por la implementacin.

Informe de Tesina

Proyecto Switch Transaccional Pgina 91 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Rol Usuario Clave Abreviatura UC

El Usuario Clave proporciona los objetivos de negocio que el proyecto debe alcanzar,
describe el funcionamiento del negocio a travs de casos de uso, configura la Solucin,
Descripcin
valida los resultados intermedios del proyecto, y es el responsable de la aprobacin final de
la implementacin.

Rol Usuario Final Abreviatura UF

El Usuario Final es el responsable de la operacin de la Solucin, una vez que la misma ha


Descripcin
sido puesta en marcha.

ACTIVIDADES, RESPONSABLES Y ENTREGABLES DEL PGI

TAREAS VERTICALES DEL PROCESO

Tarea Relevamiento de Negocio

Subtarea Requerimientos

Relevar, analizar y compilar los requerimientos de implementacin.


Objetivo

La tarea de Solucin utiliza los artefactos producidos por esta tarea como base
para el desarrollo del Documento de Solucin.
Relacin con otras La tarea de Prueba Formal utiliza los Casos de Uso producidos por esta tarea para
tareas el desarrollo de los Casos de Test.
La tarea de Administracin de Proyecto utiliza los artefactos producidos por esta
tarea como base para la planificacin de las iteraciones.

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Desarrollar Arquitectura de la Solucin CF LP

Validar Arquitectura de la Solucin UC CF CEJ

Desarrollar y Priorizar Casos de Uso CF UC

Administrar cambios a los requerimientos LP CCC

Artefactos relacionados

Entrada Salida

Informe de Tesina

Proyecto Switch Transaccional Pgina 92 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Plan de la Iteracin Arquitectura de la Solucin


Modelo de Procesos de Negocio Caso de Uso
Diagrama de Secuencia
Diagrama de Clases
Diagrama de actividades.

Tarea Solucin / Diseo

Analizar y disear cmo se implementar la Solucin para cumplir con los


Objetivo requerimientos del Cliente.
La tarea de Relevamiento de Negocio recopila los requerimientos a los cuales tiene
Relacin con otras que dar solucin esta tarea.
tareas La tarea de Implementacin utiliza los artefactos producidos por esta tarea como
base para la realizacin de las actividades de construccin de la Solucin.

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Analizar soluciones CF

Desarrollar Documento de Solucin CF UC LP

Validar Documento de Solucin UC CF CEJ

Artefactos relacionados

Entrada Salida
Plan de la Iteracin Documento de Diseo
Caso de Uso Diagrama de clases
Arquitectura de la Solucin Diagrama de secuencia
Diagrama de actividades
Diagrama de estados
Diagrama de Componentes
Diagrama de distribucin

Tarea Construccin

Implementar la Solucin de acuerdo a lo indicado en los artefactos de Solucin.


Objetivo

La tarea de Solucin especifica las soluciones que deben ser efectivizadas por esta
Relacin con otras tarea.
tareas El resultado del desarrollo de esta tarea se valida y verifica dentro de la tarea de
Prueba Formal.

Matriz de actividades y roles

Informe de Tesina

Proyecto Switch Transaccional Pgina 93 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Actividad Responsable Participa Aprueba

Desarrollar Gua de Implementacin CT LP

Efectuar configuraciones UC CT

Desarrollar Componentes CT

Desarrollar DB CT

Desarrollar UI CT

Artefactos relacionados

Entrada Salida
Plan de la Iteracin Gua de Implementacin
Documento de Solucin Manual de usuario
Componentes
Interfaces
DB

Tarea Prueba Formal

Verificar el correcto funcionamiento de las soluciones implementadas.


Objetivo Capacitar a Usuarios Clave.
La tarea de Relevamiento de Negocio genera como resultado los Casos de Uso
sobre los cuales se basa el diseo de las pruebas a ejecutar dentro de esta tarea.
Las tareas de Construccin implementan las soluciones que son validadas por esta
Relacin con otras tarea.
tareas La tarea de Administracin de Proyecto utiliza las evaluaciones de los resultados de
las pruebas ejecutadas en esta tarea como uno de los elementos a tener en cuenta
al efectuar la planificacin de cada iteracin.

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Planificar Prueba Formal LP CEJ

Disear Prueba Formal CF UC

Capacitar a Usuarios Clave CF UC / TE

Ejecutar Prueba Formal TE UC

Evaluar Prueba Formal UC CF CEJ

Informe de Tesina

Proyecto Switch Transaccional Pgina 94 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Artefactos relacionados

Entrada Salida
Plan de la Iteracin Plan de Prueba Formal
Caso de Uso Casos de Test
Arquitectura de la Solucin Resultados de Prueba Formal

Tarea Puesta en Marcha

Ejecutar la Solucin en un entorno de produccin real.


Objetivo Obtener la aceptacin formal de la Solucin por parte del Cliente.
La tarea de Implementacin implementa las soluciones que son puestas en marcha
en esta tarea.
Relacin con otras La tarea de Administracin de Proyecto utiliza la evaluacin de la ejecucin en
tareas paralelo como uno de los elementos a tener en cuenta al efectuar la planificacin
de cada iteracin.

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Planificar Puesta en Marcha LP CEJ

Capacitar a Usuarios Finales UC UF

Ejecutar paralelo UC / UF CF

Evaluar ejecucin en paralelo UC / UF CEJ

Artefactos relacionados

Entrada Salida
Plan de la Iteracin Documento de evaluacin de ejecucin en paralelo
Manual del Usuario

TAREAS TRANSVERSALES DEL PROCESO

Tarea Administracin de Proyecto

Definir la organizacin del proyecto.


Objetivo
Planificar el proyecto y monitorearlo.
Administrar los riesgos y contingencias.
Administrar los recursos del proyecto, maximizando su uso y minimizando las

Informe de Tesina

Proyecto Switch Transaccional Pgina 95 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

desviaciones y costos ocultos.


Esta tarea establece la estructura general dentro de la que se enmarcan todas las
Relacin con otras
dems tareas del proyecto.
tareas

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Lanzamiento de proyecto GP CDI/CEJ

Definir alcance y riesgos del proyecto LP UC CEJ

Desarrollar Plan General del Proyecto LP GP CDI

Desarrollar Plan de Iteracin LP GP CDI

Administrar iteracin LP GP

Cerrar Iteracin LP CEJ CDI

Cerrar Proyecto LP CEJ CDI

Artefactos relacionados

Entrada Salida
Caso de Uso Plan General
Arquitectura de la Solucin Plan de Iteracin
Mapa de Integracin Lista de Riesgos
Documento de Aceptacin y Cierre

Tarea Control de Configuracin

Controlar y efectuar el seguimiento y versionado del contenido de los ambientes de


Objetivo implementacin.
Controlar y efectuar el seguimiento y versionado de los artefactos desarrollados.
El Control de Configuraciones es una de las tareas de soporte del proceso, y por lo
Relacin con otras
tanto se relaciona con todas las dems tareas del mismo.
tareas

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Desarrollar Plan de Control de Configuracin LP CT CCC

Administrar lnea base y actualizaciones CT LP

Informe de Tesina

Proyecto Switch Transaccional Pgina 96 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Administrar Control de Cambios CT LP

Monitorear y reportar estado de configuracin CT LP CCC

Artefactos relacionados

Entrada Salida
Plan de la Iteracin Plan de Administracin de Configuracin. CVS

Tarea Aseguramiento de Calidad

Establecer los estndares de calidad para el proyecto.


Objetivo Establecer las estrategias y mecanismos de control de calidad.
Controlar la calidad del proceso de implementacin y de los diversos entregables.
Aseguramiento de Calidad es una de las tareas de soporte del proceso, y por lo
Relacin con otras
tanto se relaciona con todas las dems tareas del mismo.
tareas

Matriz de actividades y roles

Actividad Responsable Participa Aprueba

Desarrollar Plan de Aseguramiento de Calidad LP CCA

Monitorear calidad de la implementacin LP CCA

Monitorear calidad del proceso de implementacin LP CCA

Monitorear calidad de artefactos LP CCA

Artefactos relacionados

Entrada Salida
Plan de la Iteracin Plan de Aseguramiento de calidad
Evaluaciones
Mtricas e Indicadores

Informe de Tesina

Proyecto Switch Transaccional Pgina 97 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Anexo C: Detalle del Sistema Operativo


Linux version 2.6.20-1.2952.fc6 (brewbuilder@ls20-bc2- ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0])
14.build.redhat.com) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23
SMP Wed May 16 18:18:22 EDT 2007 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl)
Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level)
BIOS-provided physical RAM map: ACPI: IRQ0 used by override.
BIOS-e820: 0000000000000000 - 000000000009f000 (usable) ACPI: IRQ2 used by override.
BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) Setting APIC routing to physical flat
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) Using ACPI (MADT) for SMP configuration information
BIOS-e820: 0000000000100000 - 000000003dee0000 (usable) Nosave address range: 000000000009f000 - 00000000000a0000
BIOS-e820: 000000003dee0000 - 000000003dee3000 (ACPI NVS) Nosave address range: 00000000000a0000 - 00000000000f0000
BIOS-e820: 000000003dee3000 - 000000003def0000 (ACPI data) Nosave address range: 00000000000f0000 - 0000000000100000
BIOS-e820: 000000003def0000 - 000000003df00000 (reserved) Allocating PCI resources starting at 40000000 (gap: 3df00000:a2100000)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) SMP: Allowing 2 CPUs, 0 hotplug CPUs
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) PERCPU: Allocating 43264 bytes of per cpu data
Entering add_active_range(0, 0, 159) 0 entries of 3200 used Built 1 zonelists. Total pages: 248267
Entering add_active_range(0, 256, 253664) 1 entries of 3200 used Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet
end_pfn_map = 1048576 Initializing CPU#0
DMI 2.3 present. PID hash table entries: 4096 (order: 12, 32768 bytes)
ACPI: RSDP (v000 RS485 )@ Console: colour VGA+ 80x25
0x00000000000f8080 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes)
ACPI: RSDT (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes)
@ 0x000000003dee3040 Checking aperture...
ACPI: FADT (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) CPU 0: aperture @ d3b4000000 size 32 MB
@ 0x000000003dee30c0 Aperture too small (32 MB)
ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) No AGP bridge found
@ 0x000000003dee7740 Memory: 988476k/1014656k available (2454k kernel code, 25792k
ACPI: MCFG (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) reserved, 1458k data, 312k init)
@ 0x000000003dee7980 Calibrating delay using timer specific routine.. 4001.98 BogoMIPS
ACPI: MADT (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) (lpj=2000993)
@ 0x000000003dee7680 Security Framework v1.0.0 initialized
ACPI: DSDT (v001 RS485 AWRDACPI 0x00001000 MSFT 0x0100000e) @ SELinux: Initializing.
0x0000000000000000 SELinux: Starting in permissive mode
Scanning NUMA topology in Northbridge 24 selinux_register_security: Registering secondary module capability
Number of nodes 1 Capability LSM initialized as secondary
Node 0 MemBase 0000000000000000 Limit 000000003dee0000 Mount-cache hash table entries: 256
Entering add_active_range(0, 0, 159) 0 entries of 3200 used CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
Entering add_active_range(0, 256, 253664) 1 entries of 3200 used CPU: L2 Cache: 256K (64 bytes/line)
NUMA: Using 63 for the hash shift. CPU 0/0 -> Node 0
Using node hash shift of 63 CPU: Physical Processor ID: 0
Bootmem setup node 0 0000000000000000-000000003dee0000 CPU: Processor Core ID: 0
Zone PFN ranges: SMP alternatives: switching to UP code
DMA 0 -> 4096 ACPI: Core revision 20060707
DMA32 4096 -> 1048576 Using local APIC timer interrupts.
Normal 1048576 -> 1048576 result 12499179
early_node_map[2] active PFN ranges Detected 12.499 MHz APIC timer.
0: 0 -> 159 SMP alternatives: switching to SMP code
0: 256 -> 253664 Booting processor 1/2 APIC 0x1
On node 0 totalpages: 253567 Initializing CPU#1
DMA zone: 64 pages used for memmap Calibrating delay using timer specific routine.. 3998.94 BogoMIPS
DMA zone: 1337 pages reserved (lpj=1999474)
DMA zone: 2598 pages, LIFO batch:0 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line)
DMA32 zone: 3899 pages used for memmap CPU: L2 Cache: 256K (64 bytes/line)
DMA32 zone: 245669 pages, LIFO batch:31 CPU 1/1 -> Node 0
Normal zone: 0 pages used for memmap CPU: Physical Processor ID: 0
ATI board detected. Disabling timer routing over 8254. CPU: Processor Core ID: 1
ACPI: PM-Timer IO Port: 0x4008 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ stepping 02
ACPI: Local APIC address 0xfee00000 CPU 1: Syncing TSC to CPU 0.
ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) CPU 1: synchronized TSC with CPU 0 (last diff -2 cycles, maxerr 505
Processor #0 (Bootup-CPU) cycles)
ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Brought up 2 CPUs
Processor #1 Disabling vsyscall due to use of PM timer
ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) time.c: Using 3.579545 MHz WALL PM GTOD PM timer.
ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1]) time.c: Detected 1999.866 MHz processor.

Informe de Tesina

Proyecto Switch Transaccional Pgina 98 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

sizeof(vma)=176 bytes audit(1181402237.442:1): initialized


sizeof(page)=64 bytes Total HugeTLB memory allocated, 0
sizeof(inode)=720 bytes VFS: Disk quotas dquot_6.5.1
sizeof(dentry)=224 bytes Dquot-cache hash table entries: 512 (order 0, 4096 bytes)
sizeof(ext3inode)=968 bytes SELinux: Registering netfilter hooks
sizeof(buffer_head)=104 bytes ksign: Installing public key data
sizeof(skbuff)=248 bytes Loading keyring
sizeof(task_struct)=1920 bytes - Added public key A2C7955D82CFA151
migration_cost=117 - User ID: Red Hat, Inc. (Kernel Module GPG key)
NET: Registered protocol family 16 io scheduler noop registered
ACPI: bus type pci registered io scheduler anticipatory registered
PCI: Using configuration type 1 io scheduler deadline registered
ACPI: Interpreter enabled io scheduler cfq registered (default)
ACPI: Using IOAPIC for interrupt routing 0000:00:13.2 EHCI: BIOS handoff failed (BIOS bug ?) 01010001
ACPI: PCI Root Bridge [PCI0] (0000:00) pci_hotplug: PCI Hot Plug PCI Core version: 0.5
PCI: Probing PCI hardware (bus 00) ACPI: Fan [FAN] (on)
ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 ACPI: Thermal Zone [THRM] (29 C)
Boot video device is 0000:01:05.0 Real Time Clock Driver v1.12ac
PCI: Transparent bridge - 0000:00:14.4 Non-volatile memory driver v1.2
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] Linux agpgart interface v0.101 (c) Dave Jones
ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 11) *0, disabled. Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled
ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11) *0, disabled. serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11) *0, disabled. 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A
ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11) *0, disabled. RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize
ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11) *0, disabled. input: Macintosh mouse button emulation as /class/input/input0
ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11) *0, disabled. Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2
ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 *10 11) ide: Assuming 33MHz system bus speed for PIO modes; override with
ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 *11) idebus=xx
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P_._PRT] ATIIXP: IDE controller at PCI slot 0000:00:14.1
ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16
Linux Plug and Play Support v0.97 (c) Adam Belay ATIIXP: chipset revision 128
pnp: PnP ACPI init ATIIXP: not 100% native mode: will probe irqs later
pnp: PnP ACPI: found 14 devices ide0: BM-DMA at 0xf300-0xf307, BIOS settings: hda:DMA, hdb:pio
usbcore: registered new interface driver usbfs ide1: BM-DMA at 0xf308-0xf30f, BIOS settings: hdc:pio, hdd:pio
usbcore: registered new interface driver hub Probing IDE interface ide0...
usbcore: registered new device driver usb hda: HL-DT-STDVD-RAM GSA-H20N, ATAPI CD/DVD-ROM drive
PCI: Using ACPI for IRQ routing ide0 at 0x1f0-0x1f7,0x3f6 on irq 14
PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report Probing IDE interface ide1...
NetLabel: Initializing Probing IDE interface ide1...
NetLabel: domain hash size = 128 ide-floppy driver 0.99.newide
NetLabel: protocols = UNLABELED CIPSOv4 usbcore: registered new interface driver libusual
NetLabel: unlabeled traffic allowed by default usbcore: registered new interface driver hiddev
pnp: 00:01: ioport range 0x140-0x15f has been reserved usbcore: registered new interface driver usbhid
pnp: 00:01: ioport range 0x228-0x22f has been reserved drivers/usb/input/hid-core.c: v2.6:USB HID core driver
pnp: 00:01: ioport range 0x40b-0x40b has been reserved PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq
pnp: 00:01: ioport range 0x4d6-0x4d6 has been reserved 1,12
pnp: 00:01: ioport range 0xc00-0xc01 has been reserved serio: i8042 KBD port at 0x60,0x64 irq 1
pnp: 00:01: ioport range 0xc14-0xc14 has been reserved serio: i8042 AUX port at 0x60,0x64 irq 12
pnp: 00:01: ioport range 0xc50-0xc52 has been reserved mice: PS/2 mouse device common for all mice
pnp: 00:01: ioport range 0xc6c-0xc6d has been reserved input: AT Translated Set 2 keyboard as /class/input/input1
PCI: Bridge: 0000:00:01.0 TCP bic registered
IO window: e000-efff Initializing XFRM netlink socket
MEM window: fde00000-fdefffff NET: Registered protocol family 1
PREFETCH window: f8000000-fbffffff NET: Registered protocol family 17
PCI: Bridge: 0000:00:14.4 powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor
IO window: d000-dfff 3600+ processors (version 2.00.00)
MEM window: fdd00000-fddfffff powernow-k8: 0 : fid 0xc (2000 MHz), vid 0xe
PREFETCH window: fdc00000-fdcfffff powernow-k8: 1 : fid 0xa (1800 MHz), vid 0x10
NET: Registered protocol family 2 powernow-k8: 2 : fid 0x2 (1000 MHz), vid 0x12
IP route cache hash table entries: 32768 (order: 6, 262144 bytes) ACPI: (supports S0 S3 S4 S5)
TCP established hash table entries: 131072 (order: 10, 4194304 bytes) Freeing unused kernel memory: 312k freed
TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) Write protecting the kernel read-only data: 1042k
TCP: Hash tables configured (established 131072 bind 65536) firmware_class: attempt to set timeout to 10
TCP reno registered USB Universal Host Controller Interface driver v3.0
checking if image is initramfs... it is ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver
Freeing initrd memory: 2323k freed (PCI)
audit: initializing netlink socket (disabled) ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 19

Informe de Tesina

Proyecto Switch Transaccional Pgina 99 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

ohci_hcd 0000:00:13.0: OHCI Host Controller SELinux: Unregistering netfilter hooks


ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 audit(1181402247.960:2): selinux=0 auid=4294967295
ohci_hcd 0000:00:13.0: irq 19, io mem 0xfe02d000 input: PC Speaker as /class/input/input3
usb usb1: configuration #1 chosen from 1 choice EDAC MC: Ver: 2.0.1 May 16 2007
hub 1-0:1.0: USB hub found parport: PnPBIOS parport detected.
hub 1-0:1.0: 4 ports detected parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE]
ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 19 Floppy drive(s): fd0 is 1.44M
ohci_hcd 0000:00:13.1: OHCI Host Controller FDC 0 is a post-1991 82077
ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 2 EDAC MC0: Giving out device to k8_edac Athlon64/Opteron: DEV
ohci_hcd 0000:00:13.1: irq 19, io mem 0xfe02c000 0000:00:18.2
usb usb2: configuration #1 chosen from 1 choice 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004)
hub 2-0:1.0: USB hub found 8139cp 0000:02:05.0: This (id 10ec:8139 rev 10) is not an 8139C+
hub 2-0:1.0: 4 ports detected compatible chip
ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 19 8139cp 0000:02:05.0: Try the "8139too" driver instead.
ehci_hcd 0000:00:13.2: EHCI Host Controller 8139too Fast Ethernet driver 0.9.28
ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 3 ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 22 (level, low) -> IRQ 22
ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe02b000 eth0: RealTek RTL8139 at 0xffffc20000020000, 00:16:ec:99:25:88, IRQ
ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 22
usb usb3: configuration #1 chosen from 1 choice eth0: Identified 8139 chip type 'RTL-8100B/8139D'
hub 3-0:1.0: USB hub found hda: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache,
hub 3-0:1.0: 8 ports detected UDMA(33)
SCSI subsystem initialized Uniform CD-ROM driver Revision: 3.20
libata version 2.00 loaded. shpchp: Standard Hot Plug PCI Controller Driver version: 0.4
sata_sil 0000:00:11.0: version 2.0 sd 2:0:0:0: Attached scsi generic sg0 type 0
ACPI: PCI Interrupt 0000:00:11.0[A] -> GSI 23 (level, low) -> IRQ 23 ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 17
ata1: SATA max UDMA/100 cmd 0xFFFFC2000001C080 ctl lp0: using parport0 (interrupt-driven).
0xFFFFC2000001C08A bmdma 0xFFFFC2000001C000 irq 23 lp0: console ready
ata2: SATA max UDMA/100 cmd 0xFFFFC2000001C0C0 ctl NET: Registered protocol family 10
0xFFFFC2000001C0CA bmdma 0xFFFFC2000001C008 irq 23 lo: Disabled Privacy Extensions
scsi0 : sata_sil Mobile IPv6
input: ImPS/2 Generic Wheel Mouse as /class/input/input2 input: Power Button (FF) as /class/input/input4
ata1: SATA link down (SStatus 0 SControl 310) ACPI: Power Button (FF) [PWRF]
scsi1 : sata_sil input: Power Button (CM) as /class/input/input5
ata2: SATA link down (SStatus 0 SControl 310) ACPI: Power Button (CM) [PWRB]
ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 22 No dock devices found.
ata3: SATA max UDMA/100 cmd 0xFFFFC2000001E080 ctl ibm_acpi: ec object not found
0xFFFFC2000001E08A bmdma 0xFFFFC2000001E000 irq 22 md: Autodetecting RAID arrays.
ata4: SATA max UDMA/100 cmd 0xFFFFC2000001E0C0 ctl md: autorun ...
0xFFFFC2000001E0CA bmdma 0xFFFFC2000001E008 irq 22 md: ... autorun DONE.
scsi2 : sata_sil device-mapper: multipath: version 1.0.5 loaded
ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) EXT3 FS on dm-0, internal journal
ata3.00: ATA-7, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth kjournald starting. Commit interval 5 seconds
0/32) EXT3 FS on sda1, internal journal
ata3.00: ata3: dev 0 multi count 16 EXT3-fs: mounted filesystem with ordered data mode.
ata3.00: configured for UDMA/100 Adding 1998840k swap on /dev/VolGroup00/LogVol01. Priority:-1
scsi3 : sata_sil extents:1 across:1998840k
ata4: SATA link down (SStatus 0 SControl 310) ip6_tables: (C) 2000-2006 Netfilter Core Team
scsi 2:0:0:0: Direct-Access ATA WDC WD1600JS-22N 10.0 PQ: 0 ip_tables: (C) 2000-2006 Netfilter Core Team
ANSI: 5 Netfilter messages via NETLINK v0.30.
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) nf_conntrack version 0.5.0 (3963 buckets, 31704 max)
sda: Write Protect is off eth0: link up, 100Mbps, full-duplex, lpa 0x41E1
sda: Mode Sense: 00 3a 00 00 Bluetooth: Core ver 2.11
SCSI device sda: write cache: enabled, read cache: enabled, doesn't NET: Registered protocol family 31
support DPO or FUA Bluetooth: HCI device and connection manager initialized
SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) Bluetooth: HCI socket layer initialized
sda: Write Protect is off Bluetooth: L2CAP ver 2.8
sda: Mode Sense: 00 3a 00 00 Bluetooth: L2CAP socket layer initialized
SCSI device sda: write cache: enabled, read cache: enabled, doesn't Bluetooth: RFCOMM socket layer initialized
support DPO or FUA Bluetooth: RFCOMM TTY layer initialized
sda: sda1 sda2 Bluetooth: RFCOMM ver 1.8
sd 2:0:0:0: Attached scsi disk sda Bluetooth: HIDP (Human Interface Emulation) ver 1.1
device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: dm- eth0: no IPv6 routers present
devel@redhat.com ISO 9660 Extensions: Microsoft Joliet Level 3
kjournald starting. Commit interval 5 seconds ISOFS: changing to secondary root
EXT3-fs: mounted filesystem with ordered data mode.
SELinux: Disabled at runtime.

Informe de Tesina

Proyecto Switch Transaccional Pgina 100 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Anexo D: Detalle Servidor de Base de Datos

Informe de Tesina

Proyecto Switch Transaccional Pgina 101 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Anexo E: Detalle del Servidor de Aplicaciones

Informe de Tesina

Proyecto Switch Transaccional Pgina 102 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 103 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Informe de Tesina

Proyecto Switch Transaccional Pgina 104 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

Anexo F: Detalle de las etapas de implementacin

DETALLE DE ITERACIONES

FASE LANZAMIENTO - ITERACIN 1

Informe de Tesina

Proyecto Switch Transaccional Pgina 105 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE ELABORACIN - ITERACIN 2

Informe de Tesina

Proyecto Switch Transaccional Pgina 106 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE ELABORACIN - ITERACIN 3

Informe de Tesina

Proyecto Switch Transaccional Pgina 107 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 4

Informe de Tesina

Proyecto Switch Transaccional Pgina 108 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 5

Informe de Tesina

Proyecto Switch Transaccional Pgina 109 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 6

Informe de Tesina

Proyecto Switch Transaccional Pgina 110 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 7

Informe de Tesina

Proyecto Switch Transaccional Pgina 111 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 8

Informe de Tesina

Proyecto Switch Transaccional Pgina 112 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 9

Informe de Tesina

Proyecto Switch Transaccional Pgina 113 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 10

Informe de Tesina

Proyecto Switch Transaccional Pgina 114 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 11

Informe de Tesina

Proyecto Switch Transaccional Pgina 115 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 12

Informe de Tesina

Proyecto Switch Transaccional Pgina 116 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 13

Informe de Tesina

Proyecto Switch Transaccional Pgina 117 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 14

Informe de Tesina

Proyecto Switch Transaccional Pgina 118 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 15

Informe de Tesina

Proyecto Switch Transaccional Pgina 119 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 16

Informe de Tesina

Proyecto Switch Transaccional Pgina 120 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIN 17

Informe de Tesina

Proyecto Switch Transaccional Pgina 121 de 122


Universidad Nacional de la Patagonia San Juan Bosco

Facultad de Ingeniera Sede Puerto Madryn

FASE CIERRE - ITERACIN 18

Informe de Tesina

Proyecto Switch Transaccional Pgina 122 de 122

You might also like