Informe de Tesis - Switch Transaccional

LICENCIATURA UNIVERSIDAD NACIONAL

EN

DE LA

TESINA

DE

INFORMÁTICA

PATAGONIA SAN JUAN BOSCO

LICENCIATURA

SOCIEDAD DE LA INFORMACIÓN “SWITCH TRANSACCIONAL”

INFORME DE TESIS PUERTO MADRYN, DICIEMBRE 2007 Autor: Damián Barry Tutor de Tesis: Magíster Gustavo Cajaraville

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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

Página 2 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Agradecimientos Necesariamente a la familia ya que sin Nora, Matías y Manuel seria impensable haber alcanzado este logro y el soporte y apoyo necesario para que a los 40 años haya toma la decisión de terminar esta carrera que tanto amo.

A mi viejo el “Peke” (deformación ñ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 compañero que da el sustento filosófico y social a esta tesis.

Al Magíster 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 técnico en que se encontraba la tesis.

En toda formación universitaria deben existir necesariamente esos impulsores que provocan que uno está seguro de la carrera elegida, sin duda en ese aspecto debo mi formación profesional y agradecimiento al Licenciado Ricardo Bustelo y al Ingeniero Ernesto Mayorga (los duros) por haber compartido y transferido conocimientos y pasión por la profesión y al Contador Ricardo Barrera por la formación particularmente lúcida en sistemas y en lo sistémico, 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 alegrías en todos estos años.

Informe de Tesina Proyecto Switch Transaccional

Página 3 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Contenido Agradecimientos...................................................................................................3 Capítulo 1 – Introducción......................................................................................6 Encuadre del Proyecto.................................................................................................6 Resumen............................................................................................................................................................ 6 Introducción......................................................................................................................... .............................6

Descripción del Proyecto..............................................................................................7 Propósito, Alcances y Objetivos.......................................................................................................... ................7 Justificación.................................................................................................................................. .....................8 Principales características........................................................................................................................ ...........9 Resumen de Actividades.................................................................................................................................... .9 Arquitectura............................................................................................................................................ ...........9

Capitulo 2 – Fundamentación Teórica..................................................................11 Resumen..................................................................................................................11 Cambio de Paradigma: Globalización y Sociedad de la Información................................11 La (in)evolución de los sistemas de información...........................................................12 Democratizar la Información.......................................................................................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

Tecnologías necesarias..............................................................................................18 SOA........................................................................................................................................... ......................18 Web Services........................................................................................................................... ........................21 BPM - Orquestación de Servicios....................................................................................................................... 23 Estándares SOA.................................................................................................................. .............................28

Capítulo 3 – Proyecto: Switch Transaccional.........................................................39 Proceso de Implementación.......................................................................................39 Entallamiento del proceso de implementación.............................................................................................. .....39

Cronograma Original del Proyecto...............................................................................40 Plan de infraestructura y Configuraciones....................................................................41 Introducción.................................................................................................................................................. ...41 Arquitectura..................................................................................................................................... ................42 Definición de Ambientes..................................................................................................................... ..............43 Ambiente de Desarrollo.................................................................................................................. ..................44 Informe de Tesina Proyecto Switch Transaccional

Página 4 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Ambientes de Testing................................................................................................................................ .......46 Ambiente de producción.......................................................................................................................... .........46 Control de configuraciones........................................................................................................... ....................47 Plan de Contingencia............................................................................................................................... .........48

Administración del proyecto.......................................................................................49 Detalle de Horas por Historias del usuario (User Story) Ejecutadas en el Proyecto.............................................49 Resumen de iteraciones......................................................................................................... ..........................51

Solución...................................................................................................................53 Principales Casos de Uso................................................................................................................. .................53 Diseño del Switch Transaccional........................................................................................................ ...............56 Modelo de Datos........................................................................................................................... ...................59 Componentes........................................................................................................................................ ...........62 Implementación y Pruebas Formales....................................................................................... .........................68

Capítulo 4 – Conclusiones...................................................................................70 Bibliografía y referencias.....................................................................................71 Anexos..............................................................................................................72 Anexo A - XML Tags usados para definir un mensaje SOAP...........................................72 Anexo B – Proceso General de Implementación............................................................73 Introducción.................................................................................................................................................. ...73 Elementos del proceso iterativo......................................................................................................... ...............78 Proceso General de Implementación - 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 implementación......................................................101 Detalle de iteraciones..................................................................................................................... ................101

Informe de Tesina Proyecto Switch Transaccional

Página 5 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Capítulo 1 – Introducción Encuadre del Proyecto Esta investigación se realiza como tesina de finalización de la carrera de Licenciatura en Informática dictada por la Facultad de Ingeniería de la Universidad Nacional de la Patagonia San Juan Bosco Sede Puerto Madryn. Integrantes: Damián Pablo Barry Tutor propuesto: Magíster Gustavo Cajaraville.

RESUMEN El objeto del presente trabajo es analizar cómo la sociedad de la información tiene un rol primordial para resolver la problemática actual en la integración de aplicaciones, que no es solo económica sino conceptual y estructural, para ello intentaré por un lado una aproximación sumaria a la teoría del pensamiento complejo y por el otro las capacidades actuales del estado de la tecnología como una herramienta de integración de aplicaciones, basándose para ello en los distintos consorcios y comités encargados de la definición de estándares de integración y conectividad. Acompañando a la base teórica de integración de aplicaciones se desarrolla un Software denominado Switch Transaccional que permite gestionar la integración de distintas aplicaciones agregando una capa de procesos y validación de circuitos entre partes, en definitiva el Switch transaccional deberá actuar como regulador y controlador del contrato de intercambio de información entre partes. Palabras claves: Sociedad de la Información, Entropía, Neguentropía, Estándares, Comunicación, Tecnología, XML, A2A, B2B, OASIS, W3 Consortium, SOA, Web Services, SOAP, BPM, BPEL, WS-Security.

INTRODUCCIÓN A modo de introducción utilizaré algunos textos que ilustrarán la concepción base que fundamenta este trabajo. “Así, desorden y orden a la vez se confunden, se llaman, se necesitan, se combaten, se contradicen. Esta Dialógica se pone en marcha en el gran juego fenoménico 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 sería 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 política, las ideas, a menudo más 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 teoría del sistema se anima allí donde hay juego activo de interacciones, retroacciones, emergencias, constreñimientos, allí donde los antagonismos entre partes, entre las partes y el todo, entre lo emergente y lo sumergido, lo estructural y lo fenoménico se ponen en movimiento. La teoría del sistema toma vida allí donde hay vida y su interés teórico mas grande, se despliega a nivel de las sociedades humanas....” “La idea de cibernética–arte-ciencia del gobierno puede integrarse y transformarse en co-cibernética – arte-ciencia de

Informe de Tesina Proyecto Switch Transaccional

Página 6 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

pilotear conjuntamente, donde la comunicación ya no es útil del mando, sino una forma simbólica compleja de organización.” “La información generativa y la información circulante pueden transformarse la una en la otra, pero la transformación de una información circulante o de señales de información generativa no es posible más que si se encuentra un aparato capaz de registrarla y tratarla.” “Así la información solo puede nacer a partir de una interacción entre una organización generativa y una perturbación aleatoria al ruido. Ergo la información no puede desarrollarse más que a partir del ruido. Y desde luego, en el nacimiento de una información, siempre se necesita una actitud organizacional de carácter negentrópico que se supere a si misma transformando el evento en novedad, el error en verdad” “La información es inseparable de la actividad de la totalidad en tanto que totalidad, no obstante, no se diluye en una confusión holística. Por el contrario, se convierte en uno de los conceptos cuajados en la idea de organización negentrópica – geno - fenoménica de naturaleza informacional / comunicacional.” Edgar Morin, Cátedra Itinerante UNESCO para el Pensamiento Complejo. “Así como es indebido anteponer los problemas a las necesidades, la explicación a la comprensión y la acción 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 Función Función sin Órgano Órgano sin Finalidad Esta cascada conceptual posee un valor nuclear, pues corrige las representaciones políticas preestablecidas por el deseo, que indican cómo deben ser o dejar de ser las respectivas construcciones, pero no cómo son y cómo funcionan en realidad. Esta Función coordina procesos integrados que cruzan y resignifican las funciones tradicionales. De la correcta aplicación de esta ecuación, depende la eficiencia y la equidad del sistema. La crisis desdibuja su perfil cuando se la generaliza, pues se la vacía de contenido y se diluye la responsabilidad de sus componentes. Se impone por lo tanto centrarnos en los objetivos y en los aspectos técnicos y así contener el desaliento que enturbia la visión del escenario y deforma a los protagonistas. O revisamos las modalidades políticas que nos condujeron al fracaso, ó profundizaremos la crisis, que a su vez acentúa la incapacidad de resolverla”. Ignacio Katz, Doctor en Medicina (UBA). A partir de las experiencias en sistemas de información para la administración y control de gestión y ante el creciente uso de tecnología para la interconexión de aplicaciones y dentro de la problemática político-social planteada en la introducción, intentaré expresar cómo interactúan todos los factores de la sociedad y cómo la Sociedad de la Información contribuye al cambio del paradigma social. Para ello será clave el desarrollo de un Switch Transaccional que mediante la aplicación de arquitectura SOA (Service Oriented Architecture) garantice un medio flexible para la aplicación de estándares y procesos de negocio.

Descripción del Proyecto PROPÓSITO, ALCANCES Y OBJETIVOS. Debido a la alta interoperabilidad y los múltiples actores que intervienen en los distintos sistemas y a la creciente administración de información y transacciones en todo tipo de sistema comunitario (distribuido) (Salud, gobierno, educación, justicia, etc.) es necesario disponer de soluciones que permitan integrar a todas las partes, proveyendo Informe de Tesina Proyecto Switch Transaccional

Página 7 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

métodos y mecanismos seguros para el transporte de dicha información. 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 integración de las distintas aplicaciones entre clientes de un servicio y los oferentes del mismo, soportando mecanismos de seguridad de información transportada, flujo de procesos, aplicación de reglas de negocio y la recuperación, seguimiento y continuidad de los servicios de transacciones ofrecidos. EL Switch Transaccional debe ser considerado más que un servicio de conectividad un Portal transaccional donde se obtendrán los siguientes beneficios: ✔

Publicación de contenidos mediante Web Services a través del portal del switch, permitiendo la personalización de los mismos a cada usuario.

✔

Tecnología. ✔ ✔ ✔ ✔

✔ ✔

Web Enable. Administración y distribución de mensajes y componentes. Metamodelos para la definición dinámica de servicios y procesos transaccionales. Estándares del mercado: SOA, XML, BPEL, OASIS y W3C.

Posibilidad de conectar múltiples dispositivos de conexión front-end: IVR, POS, Aplicación cliente PC, Internet. Conectividad con todos los actores de los distintos sistemas a integrar. Permite mediante protocolos de comunicación estándar, conectar las distintas organizaciones y actores, facilitando la interoperabilidad entre los mismos.

✔

Integra información entre las distintas aplicaciones back office del sistema: Construye información, permite publicar mediante servicios información de interés 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. Descomposición de servicios en sub-servicios dependiendo de pasos y reglas configurables para cada servicio.

JUSTIFICACIÓN. Cada día es mayor la incidencia de las tecnologías de información dentro de la sociedad, generando nuevos paradigmas y enfrentando distintos intereses de la sociedad. Por ello es necesario generar mecanismos que permitan democratizar la información 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 imposición de mecanismos garanticen mayor justicia, ecuanimidad y que permitan el acceso a información de interés de los particulares y de las distinats organizaciones. Por lo tanto es necesaria la construcción de herramientas de infraestructura tecnológica que faciliten la integración de las partes. Por ello el presente proyecto además de basarse en estándares de integración de aplicaciones y servicios promoverá el uso de los mismo y la promoción 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 además de usar exclusivamente herramientas Open Source el producto resultante queda registrado dentro del esquema de Copy Left, pasando a formar parte del dominio público, para ello se ha registrado dentro del portal de Google para registración de Software Open Source utilizando una licencia GLP v2. (http://switchtransaccional.googlecode.com)

Informe de Tesina Proyecto Switch Transaccional

Página 8 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

PRINCIPALES

CARACTERÍSTICAS.

Con el Switch Transaccional se intentará: ✔

Promover una estandarización de mensajes, transacciones, procesos y conectividad para distintos mercados verticales, basados en estándares mundiales como SOA, XML, BPEL, OASIS y W3C. Se tomará como base de investigación 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 integración de servicios transaccionales.

✔

Unificar y concentrar el tráfico de solicitudes de servicios y transacciones de los distintos sistemas entre las Organizaciones Privadas y estatales, Empresas, Ciudadanos, Entidades Bancarias o Crediticias, Etc.

✔

Comunicación y re-envío de mensajes de servicios y transacciones entre redes transaccionales y de servicios.

✔

✔

Proveer configuración entre una transacción y los controles a ejecutar en la misma según la Organización servidora y el demandante, identificando el tipo de control a ejecutar y donde dependiendo de la transacción y las partes. Construcción de servicios Back-End en función de un conjunto de servicios provistos por los Backoffice. Procesamiento de servicios orientado al contenido. Registración de las transacciones ejecutadas y comunicación de las mismas al Back Office de la Organización dueña del servicio prestado, incluyendo un servicio de billing (facturación) de las transacciones y servicios. Mapa de integración. Sponsorización de los servicios.

RESUMEN ➢ ➢ ➢ ➢ ➢ ➢

➢

➢ ➢

DE

ACTIVIDADES

Investigación sobre los estándares a utilizar: SOA, XML, BPEL, OASIS y W3C. Investigación de casos de éxito de implementaciones concretas en la integración de aplicaciones y servicios a nivel e-Gobierno y comunidad. Elaboración de un Paper resumiendo las investigaciones realizadas. Relevamiento de requerimientos necesarios para el diseño del Switch Transaccional. Escritura de StoryBoard que representen la funcionalidad operativa requerida por el Switch Transaccional. Definición y administración de la Arquitectura tecnológica en la cual se soportará el Switch transaccional. Arquitectura y Diseño del Switch Transaccional, utilizando UML. ➢ Casos de Uso. ➢ Diagrama de Actividades. ➢ Diagrama de Datos y Clases. ➢ Diagrama de Secuencia. ➢ Diagrama de estados. Construcción ➢ Construcción de los parsers dinámicos mediante el uso de metamodelos para la validación de los mensajes y servicios. ➢ Construcción del flujo de procesos dinámico mediante el uso de metamodelos para la composición y construcción de superservicios. Administración de respuestas a los clientes. ➢ Construcción del router de mensajes y servicios hacia los back-office. ➢ Construcción del modulo de administración del portal. Usuarios, Servicios, Back-office, Front-End. ➢ Construcción del módulo de logging. Pruebas Formales. Puesta en marcha.

ARQUITECTURA. La Arquitectura del Switch Transaccional prevé como primer medida el ruteo y sincronización de servicios entre Informe de Tesina Proyecto Switch Transaccional

Página 9 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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

Página 10 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Capitulo 2 – Fundamentación Teórica Sociedad de la Información – Switch transaccional Uso de Tecnología, Estándares y Conectividad

Resumen El objeto del presente trabajo es analizar cómo la sociedad de la información tiene un rol primordial para resolver la problemática actual en la integración de aplicaciones, que no es solo económica sino conceptual y estructural, para ello intentaré por un lado una aproximación sumaria a la teoría del pensamiento complejo en relación al concepto de organización sistemas y sub-sistemas interdependientes y la comunicación transformada en información como elemento complejo, que acelera los procesos de negentropía de los sistemas-organizaciones evitando de esta manera la entropía de los mismos y por el otro las capacidades actuales del estado de la tecnología como elemento clave en la sociedad de la información y en particular asociado a los estándares de integración de aplicaciones promovidos por OASIS.

Cambio de Paradigma: Globalización y Sociedad de la Información. Estamos participando de un cambio de paradigma, de una transformación de los criterios básicos con los que comprendemos la realidad: Durante muchos siglos se conocieron discursos (religiosos, culturales, políticos y científicos) que la pretendieron unificar; siempre se propuso una explicación que redujera lo que sucede a un solo principio: lo que Derrida llamó “logocentrismo” y, en palabras de Gilles Deleuze, se podría denominar “mono lógica”. La lógica virtual, la lógica informática, la presencia de Internet, ya se está instalando como aquel criterio en el que se disuelve toda idea de centro. ¿Cuáles son las características que podemos avistar del nuevo mundo? Por de pronto el debilitamiento de la idea de verdad. De diversos modos, según la disciplina que se trate, la suposición de que existen verdades inamovibles, cede paso a la admisión 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 suponía verdades absolutas ha cedido paso a una más abierta, más difusa, que sólo reconoce valores dentro de los campos en los que funciona. Puede decirse que el mundo occidental actual está viviendo no sólo profundos cambios sino que se está instalando la inestabilidad (aunque suene una paradoja) Cada vez más 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 idéntico y estable a un acontecer que se muestra como fluir. De este modo, nada de lo que es, está obligado a ser sino que sólo es una posibilidad. Esto abre el mundo a un tipo de actitud. Ahora sabemos que nada es fijo (y no porque mañana 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 ideológico 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 organización” mayor que podría llamarse Organización “Socio Política” que no es más que un todo de las partes, abriendo paso al concepto holístico de sistema. A su vez estas “partes sistemas” Informe de Tesina Proyecto Switch Transaccional

Página 11 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

conforman distintas organizaciones que interactúan e interaccionan entre si y con la Organización Global. Así en el sistema, cada interacción, cada contrato, cada acción 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, organización a su vez biológica-cultural que integra los sistemas y sub-sistemas sociales, económicos, políticos, culturales etc. y que es también permanentemente, interactuado por fenómenos directos, indirectos y emergentes o sumergentes de los mismos. Por ejemplo su salud como su calidad de vida, estarán íntimamente ligados a su sistema biológico, cultural, social, político, económico, ecológico, medio ambiente etc. y las interacciones de cada uno de estos, más 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 visión del problema y su resolución será diferente porque de acuerdo a su ubicación y su situación sus determinaciones serán distintas. Conectividad (Internet), intercambio de información, interacción de las partes e interoperabilidad, tableros de comando, monitoreo y seguimiento de políticas, serán el desafío tecnológico del futuro que garantizará una mejor calidad de vida al hombre asegurando una mejor utilización de los recursos económicos, profesionales, logísticos, culturales y sociales disponibles dentro de cualquier tipo de organización política y garantizando el equilibrio entre todas las partes tanto públicas como privadas, equilibrando sus contradicciones y potenciando sus cualidades. Obligando al uso racional de la información y a reducir la brecha sobre el conocimiento que existe actualmente. La información 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 información 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, garantías jurídicas y viabilidad de aplicación, económica, cultural, social etc. el sistema tenderá a la fortificación y cada una de las partes se beneficiará, pero de continuar por el camino en que están hoy los sistemas de información, la entropía es inevitable y la consecuente disolución o dispersión de cada uno de los sub-sistemas también. Este es el gran desafío de la tecnología y el único camino que tienen por seguir aquellos que están solo interesados en mejorar la calidad de vida del hombre y sus organizaciones y sistemas.

La (in)evolución de los sistemas de información. La problemática en la generación y obtención de información de los sistemas de informáticos y organizacionales, no es nueva. De hecho el empeño puesto en los procedimientos y procesos orientados a garantizar el correcto funcionamiento tanto administrativo, económico y de procedimientos administrativos ha sido indispensable para garantizar el funcionamiento de las organizaciones. Esta problemática inclusive es anterior a la implementación de estos procesos en medios electrónicos. Justamente la evolución tecnológica y el afán de ordenamiento en la administración de la información son en parte los causantes de las deficiencias actuales en la administración de la información. En un afán de las empresas de tecnología de insertarlas en los distintos ámbitos de las organizaciones, han derivado en el des-concepto que era más importante la tecnología que el procedimiento y la información, perdiendo de vista para qué se desarrollaban esas nuevas tecnologías, 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 común. La evolución en los sistemas de información ha ido de lo operacional administrativo-económico a la utilización de técnicas más avanzadas de sistematización centrando la problemática en las interacciones y flujos de información que sucedían en el ámbito de las organizaciones. Consecuencia de este desorden ha producido los siguientes inconvenientes: ✗ Múltiples repositorios de datos. ✗ Circuitos y procedimientos administrativos orientados y alineados con los sistemas informáticos. Las organizaciones alineadas al servicio de los sistemas de información y no al revés. Informe de Tesina Proyecto Switch Transaccional

Página 12 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

✗ Inexistencia de centros codificadores (vocabularios, glosarios e identificadores). ✗ Falta de patrones de diseño de sistemas informáticos transaccionales. Modelos de datos y atributos comunes: Lenguaje común. ✗ Integración de aplicaciones punto a punto, propietarias y específicas para dicha integración. ✗ Falta de estándares y de políticas de administración e intercambio de información. La falta de interpretación de los requerimientos y de las reglas de negocio por parte de las áreas de tecnología ha desembocado en una puja con viso de soberbia entre los generadores de las políticas y los responsables de implementarlas tecnológicamente. Por otra parte el crecimiento en la producción de información ha desembocado en la postura de los mismos organismos a no compartir la información producida. Muchas veces la actitud ha sido provocada por la falta de controles y normas de seguridad en el intercambio de información y otras lisa y llanamente por el poder que da contar con cierta información mientras no sea pública. 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 evolución en la producción de información neguentrópica clave para evolucionar hacia la sociedad de la información.

Democratizar la Información. Las comunicaciones favorecen el intercambio y la interacción democrática de la información, 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 información permite auditar y controlar las actividades de los distintos actores de los sistemas y organizaciones. La tecnología y las comunicaciones son el factor impulsor de este intercambio. La capacidad de los distintos sistemas que procesen dicha información, permitirá implementar procedimientos cualitativamente superiores, debido al acceso a dicha información y a la posibilidad de interactuar en línea sobre los diversos sucesos de los sistemas interactuantes. Los sistemas y los actores deben alimentarse del flujo de información para trabajar con ella en todos los niveles. Cada parte tomará de la información circulante lo que necesita para aprender y crecer. Este crecimiento y la interacción de los actores mantendrán en equilibrio el sistema de información 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 más económicas y accesibles, permiten suponer que lograr sinergia de información entre los sistemas y sus subsistemas posibilitando la neguentropía será una realidad posible. En este sentido, es clave, la integración geográfica de todos los actores y sus sistemas de información, logrando transformar un modelo físico de lejanía geográfica, en un modelo de información virtualmente sin distancias ni brechas temporales. De todas formas no se debe descuidar la gran debilidad que puede significar la utilización de tecnología en países en vías de desarrollo como lo son los países que integramos Latinoamérica. Ya que si hablamos de democratizar la información, bajo ningún concepto debemos ni podemos hacer que la utilización de tecnología no sea un recurso sustentable. Para ello es importante la participación del estado en la regulación y en la administración de un crecimiento homogéneo y democrático en la utilización de tecnología y más aún en las políticas de acceso y distribución de información.

Informe de Tesina Proyecto Switch Transaccional

Página 13 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Sistemas organizacionales e interacciones. ACTORES,

ROLES Y NECESIDADES

Dentro de los distintos sistemas organizacionales, ya sean privados, públicos o de gobierno, nos encontramos con una gran cantidad de actores que necesitan intercambiar servicios e información. Estas operaciones están sumamente atomizadas, requiriendo la intervención simultanea de los actores mencionados. A dichas operaciones se agregan además intereses contrapuestos y necesidades de control y contralor que lo hacen mas complejo aún. Esta complejidad genera una gran cantidad de dialectos de comunicación entre las partes, provocando el clásico “teléfono descompuesto”. Debido esto, normalmente, a reglas de interpretación poco claras. Donde el principal damnificado es el hombre, donde normalmente es sometido a largas esperas y en algunos casos re-hacer los trámites y operaciones por dicha falta de interpretación. Es por ello que la alta interoperabilidad de dichos servicios e información requiere de una interpretación precisa de lo que se solicita como servicio y de lo que se pretende informar o recibir como información. De aquí que la mayor necesidad de las organizaciones y actores intervinientes sea la definición de estándares de servicios y comunicaciones que garanticen o por lo menos minimicen la posibilidad de confusiones y malas interpretaciones en el intercambio de información. Esta situación 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 identificación de una persona como paciente en un hospital y el acceso a su historia clínica centralizada. Fallar en esta situación podría en algunos casos provocar la muerte del paciente por falta o mala interpretación de la información requerida.

SISTEMAS

E INTEROPERABILIDAD

La sociedad y su sistema de organización social, requiere que sus organizaciones, ya sean privadas, semi públicas o públicas interaccionen tanto con los ciudadanos (en cualquiera de sus roles) como con otras organizaciones.

Contexto Social de interacciones

Informe de Tesina Proyecto Switch Transaccional

Página 14 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

➢ Los ciudadanos están ligados a distintos organismos y organizaciones por diversos motivos dentro de sus obligaciones y derechos. También están 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 educación. Un paciente, está ligado al sistema de salud: hospitales, centros de atención Obra social o pre-paga. Un ciudadano está vinculado a los gobiernos municipales, provinciales y nacionales debido a sus obligaciones. ➢ El nexo común es la sociedad en si misma. ➢ El factor impulsor es la organización de dicha sociedad con sus actividades, sociales, económicas 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 continuación se puede apreciar un ejemplo solamente para el área de salud

Claramente se puede observar el nivel de interoperabilidad, dependencia y atomización que nos llevan a concluir el siguiente diagnóstico: ➢ Sistema atomizado con muchos intermediarios. ➢ Industria de información intensiva. ➢ Gastos transaccionales y operacionales elevados con tendencia a la ineficiencia. ➢ Situación económico / financiera comprometida. ➢ Falta de políticas integrales y estándares. ➢ Escasa inversión en tecnología. Es importante destacar el rol central que tienen los factores económicos dentro de esta interoperabilidad y el papel preponderante que juegan las organizaciones financiadoras y el gobierno como factores de equilibrio entre calidad y distribución de las prestaciones. Informe de Tesina Proyecto Switch Transaccional

Página 15 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

La evolución de los sistemas sociales hace pensar que estamos frente a una problemática de demanda infinita y recursos limitados y es aquí donde estas organizaciones tienen la responsabilidad de administrar y distribuir en toda la población el derecho y acceso a la información y un equilibrio entre las actividades desarrolladas en una sociedad.

Organizaciones dedicadas a la interoperabilidad OASIS OASIS, acrónimo de (Organization for the Advancement of Structured Information Standards) es un consorcio internacional sin fines de lucro que se orienta al desarrollo, consenso y adopción de estándares para el intercambio de información entre aplicaciones (e-Business, e-Government). Los miembros del consorcio deciden cómo y qué trabajos se deben emprender a través de un proceso abierto y democrático. Los trabajos técnicos abarcan las siguientes categorías: 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 asociación comercial, denominada “SGML Open”, para promover la adopción del estándar SGML. Principalmente mediante el desarrollo de actividades educativas, incluyendo también actividades técnicas 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 interés del consorcio abarca desde promociones de adopción de estándares hasta el desarrollo de especificaciones técnicas de los mismos. En julio del 2000 se creo un nuevo comité técnico. En la actualidad hay cerca de 70 comités. Durante 1999 OASIS se reunió con la UN/CEFACT, el comité de las Naciones Unidas para negociar los estándares de negocios, para que conjuntamente se desarrollen nuevas normas y estándares para el intercambio de información electrónica. La junta inicial se la llamo “ebXML” y se reunieron por primera vez en Noviembre de 1999, fue establecida por un periodo de 3 años. En la reunión final bajo los primeros estatutos, en Viena, UN/CEFACT y OASIS coincidieron en dividir el trabajo en las dos organizaciones y coordinar la finalización de los trabajos en comités específicos. En 2004 OASIS propuso la especificación de ebXML a la ISO TC154 donde fue aprobada como la ISO 15000. Algunos de los estándares desarrollados por OASIS: ➢ DITA (OASIS Darwin Information Typing Architecture) es un modulo portable y extensible basado en el lenguaje XML para temas básicos como ayuda on-line, documentación de proyectos, asesoramientos y capacitación. ➢ 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 cálculo, presentaciones, memos, y gráficos. ➢ SAML (Security Assertion Markup Language) es un estándar basado en XML para la seguridad en el intercambio, autenticación y autorización de información. ➢ XRI (eXtensible Resource Identifier) es un esquema compatible con URI y un protocolo de resoluciones usado por identificadores abstractos para la identificación y intercambio de recursos a través de dominios y aplicaciones. ➢ XDI (XRI Data Interchange) es un estándar para el intercambio, interconexión y sincronización de datos (“dataweb”) mediante el uso de múltiples dominios y aplicaciones usando documentos XML (XRIs, eXtensible Resource Identifiers) y nuevos métodos distribuidos de control de datos llamados “linkContract”.

Informe de Tesina Proyecto Switch Transaccional

Página 16 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

➢ LegalXML es un estándar para el intercambio de información legal y jurídica entre todas las partes del sistema judicial. EL consorcio es de carácter internacional y por lo tanto crea las normas para un mercado internacional. Con la oficina principal en Estado Unidos de América, el consorcio tiene la representación corporativa en Europa y Asia, y participación 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 superposición de normas y reducir el riesgo de la nueva tecnología. 3. Los proveedores de software impulsando la cooperación de la industria a través de normas y estándares. Además 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 Comités Técnicos de OASIS, documentos y los correos electrónicos son públicamente accesibles incluso para los no-miembros y pueden ser supervisados y mejorados abiertamente. OASIS se caracteriza por su gobierno y su forma de operación. Los mismos miembros fijan la agenda técnica, usando un proceso sencillo diseñado 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 Técnica son escogidos por elección democrática para servir por el término de dos años. La Dirección del consorcio esta basada en el mérito individual y no en su contribución financiera, situación corporativa o cita especial. OASIS mantiene participación 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 organización sin fines de lucro que desarrolla estándares para minimizar las incompatibilidades entre sistemas de información en salud, permitiendo la interacción y el intercambio productivo de datos entre aplicaciones heterogéneas, independientemente de su plataforma tecnológica 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 discusión y en el desarrollo de estándares por consenso, en un entorno abierto. Estos estándares ofrecen un marco que permite a los diferentes sistemas de información, comunicarse a través 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 múltiples sistemas heterogéneos de información, y rápidamente se convirtió en el estándar de facto para el intercambio electrónico de datos clínicos y administrativos en los servicios de salud de los Estados Unidos. La amplia difusión de los estándares desarrollados, dio origen en los últimos años a filiales internacionales (Canadá, Informe de Tesina Proyecto Switch Transaccional

Página 17 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Australia, China, Finlandia, Alemania, India, Japón, Corea, Holanda, Nueva Zelanda, Sudáfrica, Reino Unido, Argentina, Brasil, para mencionar solo algunos), y a un comité internacional, que permite armonizar y discutir las necesidades locales de adaptar los estándares en distintas partes del mundo. La estructura internacional de la organización, el procedimiento de votación balanceado, y las políticas abiertas de asociación, aseguran que todos los requerimientos sean tenidos en cuenta uniformemente y equitativamente con calidad y consistencia. Además todas las organizaciones HL7 y sus desarrollos, están reconocidas en Estados Unidos por el instituto ANSI (American National Standards Institute) y por la SDO (Standards Developing Organization).

Tecnologías necesarias. La tecnología por si misma no podría modificar absolutamente nada dentro de la sociedad de la información. 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 están dando ejemplo que la construcción cooperativa de sistemas es posible. Claramente el ejemplo más contundente lo ha dado la misma comunidad que desarrolla y promueve los estándares mencionados anteriormente. Otro ejemplo contundente y además basado en el concepto de componentes distribuidos lo ha dado la comunidad Java a través de la especificación JEE (Java Enterprise Edition) y sin duda el esfuerzo mayor lo han dado las mismas empresas de tecnología mediante la voluntad de crear en Internet estándares que permitan la integración de cualquier sistema independientemente de su plataforma mediante la utilización de XML y Web Services.

SOA DEFINICIÓN. SOA es la sigla que en ingles representa a “Service Oriented Arquitectura” (Arquitectura Orientada a los servicios). Básicamente la arquitectura propuesta es un nuevo paradigma dentro de las ciencias informáticas 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á más adelante. Hasta ahora, la mayoría de las discusiones sobre SOA, giraban en torno a temas sobre la integración de sistemas dispares, el aprovechamiento de las Bases de Datos existentes en una organización o la creación de una arquitectura robusta. Si bien todos estos temas son relevantes para SOA, existen otros temas significativos e interesantes relacionados con SOA que merecen atención. Para lograr su objetivo de conectar sistemas heterogéneos y autónomos, SOA se adhiere a varios principios de diseño esenciales. Uno de los principios mantiene que la existencia de servicios independientes implica la presencia de partes de código y datos interconectados mediante mensajería. Es más, los servicios están íntimamente vinculados a la mensajería ya que el único camino de entrada y salida de un servicio es a través de mensajes. No obstante, los servicios seguirán funcionando de forma independiente de los demás. Por lo tanto SOA proporciona una metodología y un entorno de trabajo para documentar capacidades de negocio y puede dar soporte a las actividades de integración y consolidación 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 mayoría de las definiciones SOA identifican la utilización de Servicios Web (empleando SOAP y WSDL) en su implementación, no obstante se puede implementar SOA utilizando cualquier tecnología basada en servicios.

Informe de Tesina Proyecto Switch Transaccional

Página 18 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Nube se Servicios

Al contrario de las arquitecturas orientadas a objetos, SOAs está formada por servicios de aplicación débilmente acoplados y altamente interoperables. Para comunicarse entre sí, estos servicios se basan en una definición formal independiente de la plataforma subyacente y del lenguaje de programación (por ejemplo WSDL. Ver Web Services más adelante). La definición de la interfaz encapsula (oculta) las particularidades de una implementación, lo que la hace independiente del fabricante, del lenguaje de programación o de la tecnología de desarrollo (como Java o .NET). Con esta arquitectura, se pretende que los componentes de software desarrollados sean muy reusables, ya que la interfaz se define siguiendo un estándar; así, un servicio C Sharp podría ser usado por una aplicación Java. Dos ejemplos de soluciones comerciales SOA serían "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 métodos de definición 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 código y datos, y en los servicios de interconexión de mensajes. Cada servicio es una colección única de código y datos que es autónoma e independiente de los demás servicios. No obstante, cada servicio está interconectado con otros servicios a través de la mensajería. La mensajería tiene una importancia enorme en SOA. Los mensajes se envían entre servicios y flotan entre ellos. definición de esquema para cada mensaje y el contrato que define el flujo de los mensajes especifican comportamiento de "caja negra" del servicio. Los servicios están vinculados a la mensajería ya que el único camino entrada y salida de un servicio es a través de mensajes. Un servicio asociado sólo está pendiente de la secuencia los mensajes que fluyen de un lado a otro.

La el de de

A veces, se envían muchos mensajes relacionados entre dos servicios distintos. Estos dos servicios pueden intercambiar mensajes durante un período de semanas o meses.

Informe de Tesina Proyecto Switch Transaccional

Página 19 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Transmisión de Servicios (Mensajes) encadenados y dependientes

Los servicios son el centro de atención del proceso evolutivo. Los servicios proporcionan una manera de establecer una división granular de mayor tamaño y con más independencia entre los fragmentos de código que las funciones y los componentes. En primer lugar, los servicios siempre interactúan 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 implementación opacos en los que desde el exterior sólo 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 definición: Los componentes pueden no ser conjuntos. La definición sólo considera los componentes y no la práctica o el arte de construir la arquitectura. Por lo tanto presenta la siguiente definición: “Estilo resultante de políticas, prácticas y frameworks que permiten que la funcionalidad de una aplicación se pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor. Los servicios pueden invocarse, publicarse y descubrirse y están abstraídos de su implementación utilizando una sola forma estándar de interfaz”. Informe de Tesina Proyecto Switch Transaccional

Página 20 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

➢ “Infraestructura de alto nivel basada en best practices y patrones para crear soluciones basadas en servicios, de alta cohesión y bajo acoplamiento” (Geniant®). ➢ “Estilo arquitectónico 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 aplicación 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 aplicación SOA es una colección de servicios ✔ Un servicio es la unidad atómica de una SOA ✔ Los servicios encapsulan procesos de negocios ✔ Los proveedores de servicios se registran solos ✔ Un servicio involucra: Find, Bind, Execute ✔ Las instancias más conocidas son los Web services

➢ Gartner: “SOA es una arquitectura de software que comienza con una definición de interfaz y construye toda la topología de la aplicación como una topología de interfaces, implementaciones y llamados a interfaces. Sería mejor llamada “arquitectura orientada a interfaces”. SOA es una relación de servicios y consumidores de servicios, ambos suficientemente amplios para representar una función de negocios completa”.

Comportamiento SOA

WEB SERVICES Un servicio Web es una colección de protocolos y estándares que sirve para intercambiar datos entre aplicaciones. Distintas aplicaciones de software desarrolladas en lenguajes de programación diferente y ejecutada sobre cualquier

Informe de Tesina Proyecto Switch Transaccional

Página 21 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

plataforma pueden utilizar Web Services para intercambiar mensajes (servicios) en redes como Internet. La interoperabilidad se consigue mediante la adopción de estándares abiertos. OASIS y W3C son los comités responsables de la arquitectura y reglamentación de los Web Services. Los Web Services, garantizando el uso de estándares en la tecnología 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 programación a ser utilizados. Los Web Services, no son por lo tanto aplicaciones con una interfaz gráfica 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 tecnologías Internet) por otras aplicaciones. De esta forma podemos desarrollar aplicaciones que hagan uso de otras aplicaciones que estén disponibles en Internet. Un típico ejemplo podría ser un Web Service al que se le pudiese preguntar por una empresa y que nos retornase en tiempo real el valor al que están cotizando las acciones de dicha compañía. De esta forma cualquier aplicación (ya sea Web o de escritorio) que quiera mostrar esta información sólo tendría que solicitarla a través de Internet al Web Service cuando la necesitase. Otro ejemplo podría ser uno que al pasarle el nombre de una ciudad, nos devolviese la temperatura, humedad, y otras condiciones de clima.

ESTÁNDARES

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 estándar 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 también pueden enviarse de una aplicación a otra mediante protocolos normales como HTTP, FTP, o SMTP. 5. WSDL (Web Service Definition Language ): Es el lenguaje de la interfaz pública para los servicios Web. Es una descripción basada en XML de los requisitos funcionales necesarios para establecer una comunicación con los servicios Web. 6. UDDI (Universal Description, Discovery, and Integration): Protocolo para publicar la información de los servicios Web. Permite a las aplicaciones comprobar qué servicios web están disponibles. 7. WS-Security: Protocolo de seguridad aceptado como estándar por OASIS. Garantiza la autenticación de los actores y la confidencialidad de los mensajes enviados.

Funcionamiento Básico de un Web Service

Informe de Tesina Proyecto Switch Transaccional

Página 22 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Tecnologías usadas en la Arquitectura de Web Services

BPM - ORQUESTACIÓN

DE

SERVICIOS

Otro punto importante a tener en cuenta dentro de la mensajería 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 podríamos comunicar una aplicación 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 interacción entre partes. Ya que muchas veces cuando hablamos de Web services no nos limitamos solamente al uso de un servicio sencillo sino a la ejecución distribuida de aplicaciones complejas. Como solución y componente fundamental veremos que los lenguajes de Proceso o como se denominan normalmente BPM (Business Process Modeling) permiten estandarizar y orquestar una relación 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 distribución de mensajes y aplicación de procesos y reglas de negocio. También a estos intermediarios se los suele denomina HUB o Switch de integración de aplicaciones. Un ejemplo de ello es lo implementado por el HIPPA (Health Insurance Portability & Accountability Act) que ha regulado la implementación de lo que ha denominado como “Clearing Houses” que tienen la responsabilidad de administrar mensajes, solicitudes y reclamaciones entre asegurados, aseguradoras y hospitales y clínicas dentro de USA.

Informe de Tesina Proyecto Switch Transaccional

Página 23 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Elementos para la Orquestación de servicios

Para tener una mayor comprensión del significado de la mencionada coordinación, veremos distintas topologías de coordinación (orquestación) para transacciones y mensajes entre servicios: 1. Relación Binaria: El contexto y la actividad están implícitas en cada servicio, logrando de esta forma un criterio de auto-coordinación.

Coordinación Binaria

Informe de Tesina Proyecto Switch Transaccional

Página 24 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

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

Coordinación 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 explícitas pero dependientes de cada servicio. Este esquema es una solución mixta entre el esquema concentrador y el distribuido punto a punto.

Coordinación Multigrupo

Informe de Tesina Proyecto Switch Transaccional

Página 25 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Arquitectura de un Coordinador

Actualmente se encuentran disponibles varios lenguajes estándar de orquestación y especificación 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 estándares que esta organización administra. Este impulso inicial además ha sido reforzado fuertemente por compañías como Oracle, BEA, OpenStorm y Microsoft.

Informe de Tesina Proyecto Switch Transaccional

Página 26 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

BPEL además 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 gráfico podemos ver la arquitectura completa para realizar una correcta integración de aplicaciones y procesos distribuidos.

Informe de Tesina Proyecto Switch Transaccional

Página 27 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Resumen de Arquitectura SOA

ESTÁNDARES SOA XML XML (Extensible Markup Language) es un lenguaje extensible de etiquetas, desarrollado por el World Wide Web Consortium (W3C). Se propone como un estándar para el intercambio de información estructurada entre diferentes plataformas. Permite compartir la información de una manera segura, fiable y sencilla. Es un subconjunto de SGML (Standard Generalized Markup Language, lenguaje de marcado generalizado estándar), 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 características más utilizadas. Fue diseñado para que fuera fácil 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 publicación de documentos electrónicos. 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 gramática de lenguajes específicos para diferentes necesidades. Los objetivos al diseñar 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 características optativas fuera mínima, en lo posible cero.

Informe de Tesina Proyecto Switch Transaccional

Página 28 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

6. Los documentos XML debían ser legibles a nivel humano y razonablemente claro. 7. El diseño de XML debía prepararse rápidamente, ser formal y conciso. 8. Los documentos XML debían ser fáciles de crear. 9. Lograr etiquetas concisas sería lo menos importante. Ventajas del XML: 1. Comunicación de datos. Permite la transferencia de información en texto plano, con formato XML, entre aplicaciones diferentes. 2. Migración de datos. Facilita un lenguaje intermedio para escribir los datos de una aplicación a otra diferente, por ejemplo para intercambio entre diferentes sistemas de bases de datos. 3. Aplicaciones Web. Una sola aplicación maneja los datos y cada navegador aplica el estilo adecuado para mostrarlos. HTML fue pensado como un lenguaje de publicación e intercambio de documentos técnicos y científicos. Resolvía el problema de la complejidad de SGML especificando un pequeño conjunto de etiquetas para edición de documentos relativamente simples. Además de simplificar la estructura de los documentos, HTML agregó soporte para hipertexto. Más tarde se agregarían capacidades multimedia. En un breve lapso de tiempo, HTML se hizo muy popular, y rápidamente superó su propósito original. Desde su creación, se han agregado nuevos elementos para incluir en el estándar, y así adaptarlo a mercados más 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 diseñada para acomodar esas extensiones por medio de módulos XHTML y técnicas para desarrollar nuevos módulos compatibles con XHTML. Tales módulos permitirán la combinación de nuevas características junto con las existentes. Constantemente se introducen nuevas formas de acceso a Internet. La familia XHTML fue diseñada 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 podrán 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 versión más estricta y limpia de HTML. Surge con el objetivo de remplazar a HTML ante su limitación de uso con las cada vez más abundantes herramientas basadas en XML. XHTML extiende HTML 4.0, combinando la sintaxis de HTML, diseñado para mostrar datos, con la de XML, diseñado para describir los datos. XHTML surge como el lenguaje cuyo etiquetado, más estricto que HTML, va a permitir una correcta interpretación de la información, 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 estándares 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 podrán operar en y entre varios entornos XHTML.

Informe de Tesina Proyecto Switch Transaccional

Página 29 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

SOAP El protocolo SOAP (del inglés Single Object Access Protocol) define una estructura que permite el intercambio de mensajes, como aquellos necesarios en un Servicio Web, a través de una red, como por ejemplo Internet. SOAP permite el intercambio de información en ambientes distribuidos y descentralizados. Esta basado en XML, y define un framework de mensajería extensible, proveyendo un formato de mensajes que puede ser utilizado en una amplia variedad de escenarios. Está diseñado para ser independiente de cualquier modelo particular de programación. La especificación original fue diseñada 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 raíz de un mensaje SOAP. Mediante este, un proceso que reconoce mensajes SOAP puede identificarlos. La cabecera cuenta con información destinada a los posibles intermediarios que se encuentren durante el viaje del mensaje hacia su destinatario final, y es una sección opcional que puede estar vacía. La función que cumple es la de contener información de ruteo que le permita desplazarse por los diferentes intermediarios hasta llegar a su destino final. Mediante agregados a esta sección, se puede expandir la funcionalidad de SOAP, por ejemplo agregando información para identificación, transacciones, etc. El cuerpo aloja el contenido primario, o sea, la información relevante a la aplicación o sistema, de interés para el emisor y el receptor final. Puede también no contener información. Un mensaje SOAP puede contener, además, un attachment, que no necesariamente tiene que ser un documento XML: una imagen, un documento de texto, etc. Informe de Tesina Proyecto Switch Transaccional

Página 30 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Medios de Transporte SOAP puede ser utilizado sobre varios medios de transporte, como HTTP o SMTP. Actualmente el medio más utilizado es HTTP, por su mayor aceptación y mejor adaptación 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 método de intercambio a utilizar (GET o POST). El uso de SMTP nos permite incluir el mensaje SOAP en un correo electrónico. La elección de XML como lenguaje para definir el mensaje se debe a la amplia aceptación de este, y por su característica multiplataforma, la que se extiende así al protocolo SOAP. También ofrece la ventaja de ofrecer una sintaxis y estructura compresible para humanos.

Escenarios El intercambio más simple que puede ser representado es el patrón request–response, 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 información basada en XML, a través de mensajes SOAP. De esta forma se conforma una “conversación” entre aplicaciones o sistemas. La semántica es definida a nivel de aplicación, 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 envía, a través de HTTP, un mensaje que es recibido y procesado por el servidor SOAP.

Debilidades Debido al uso de mensajes XML largos, una solución SOAP puede ser más lenta que otra usando CORBA. También se ha nombrando como una limitación 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 estandarización de los protocolos de comunicación se extiende, la posibilidad de encarar exitosamente una organización estructurada de las comunicaciones se convierte en una realidad. WSDL (del inglés Web Services Description Language) es un estándar que permite encarar este objetivo ofreciendo descripciones de servicios. WSDL permite describir la interfaz de un Servicio Web, y cómo debe ser ligado con una dirección de red. Generalmente se utiliza en combinación con SOAP para proveer servicios a través de Internet. Cualquier programa cliente que se conecte al Servicio Web puede determinar que funcionalidad esta disponible a partir del documento WSDL asociado. El estándar WSDL esta siendo desarrollado por el W3C.

Descripción de un Servicio Web La descripción de la interfaz del servicio por parte de WSDL se puede dividir en: Informe de Tesina Proyecto Switch Transaccional

Página 31 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 algún tipo de definición estándar, 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 vía (one-way): mensajes que no necesitan una respuesta. 2. Pedido/Respuesta (request-response): el emisor envía un mensaje, y el receptor responde al recibirlo. 3. Solicitud de respuesta (solicit response): un pedido de respuesta (la definición especifica aún esta pendiente) 4. Notificación (notificación): envío de un mensaje a varios destinatarios (la definición especifica aún esta pendiente) De esta forma las operaciones indican un patrón de intercambio de uno o más 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 definición de funcionalidad en un sentido abstracto, sin referirnos a ningún tipo de formato de transporte o plataforma subyacente. WSDL separa las anteriores definiciones de los detalles concretos de su implementación permitiendo la portabilidad y la reutilización de estas especificaciones. El Service binding específica la forma de conectar una interfase con un puerto o endpoint, definiendo una asociación con una dirección de red (por ejemplo, una URL) con dicha interfase. Describe cómo y donde acceder al Servicio Web, por lo que se trata de una definición a un nivel concreto. El servicio queda definido entonces a partir de una colección 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 descripción de un servicio Una descripción de un Servicio Web utilizando WSDL indica como se espera que potenciales clientes interactúen con el servicio descrito. Es una declaración de que el servicio Web implementa y adhiere a lo descrito el documento WSDL. La interfaz definida, entonces, describe interacciones potenciales, no requeridas: la interacción descripta no es necesario que ocurra en absoluto, pero de llegar a ser iniciada, las operaciones describen como debe ocurrir.

UDDI UDDI, acrónimo 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 información 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 estándares mantenidos por OASIS. UDDI permite confeccionar un catalogo de negocios, permitiendo publicar listados de servicios y descubrir otros. También permite definir cómo los servicios o aplicaciones deben interactuar a través de Internet. De esta manera los proveedores de servicios Web pueden darse a conocer, y los potenciales clientes realizar búsquedas por servicios que satisfagan sus necesidades. La versión actual de UDDI es la V2.0 aprobada como un Estándar OASIS, y ya existen numerosos productos y servicios Informe de Tesina Proyecto Switch Transaccional

Página 32 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

que la implementan. La versión 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 información que guarda un registro UDDI se puede dividir en un conjunto de categorías de datos simples: 1. ¿Quién? (Who?) – Información sobre el negocio o institución. Nombre, identificación, dirección de contacto, etc. 2. ¿Qué? (What?) – Información de categorización (por ejemplo, códigos industriales o clasificaciones de productos) e información descriptiva de los servicios disponibles. 3. ¿Dónde? (Where?) – Información de registro sobre la URL, dirección de correo electrónico u otro medio a través de la cual se accede al servicio. 4. ¿Cómo? (How?) – Información de cómo funciona una interfase en particular del Servicio Web registrado. Generalmente se agrupa a estas categorías bajo el nombre de Páginas blancas (¿Quién?), Páginas amarillas (¿Qué?) y Páginas verdes (¿Dónde? y ¿Cómo?).

UDDI esta diseñada para interactuar con SOAP y WSDL. Por medio de un mensaje SOAP se puede interrogar a un servidor UDDI para que este responda con información de acceso a un Servicio Web particular, por medio de un documento WSDL.

Uso de UDDI Un negocio u organización puede implementar uno o más registros UDDI privados o públicos. Un registro privado permitirá acceso sólo a usuarios autorizados, mientras que uno público no impone restricciones de acceso. Una combinación de registros públicos y privados permite realizar una división entre los servicios de información internos y externos. El beneficio de tener, y ofrecer, acceso a esta información es el de proveer medios para que terceros puedan descubrir las interfaces disponibles para interactuar con un servicio, aumentando la eficacia de la organización que lo implemente.

Informe de Tesina Proyecto Switch Transaccional

Página 33 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

UDDI Business Registry El UDDI Bussines Registry (o UBR) es un registro público y gratuito actualmente operado conjuntamente por IBM, Microsoft, NTT Communitations y SAP. Cualquier entidad tiene la libertad de registrarse y publicar información en cualquiera de los nodos de UBR, así como de realizar búsquedas sobre ellos.

WS-SECURITY Muchos problemas se asocian con el envío de mensajes en una ruta más compleja que la de solicitud/respuesta o a través de un sistema de transmisión 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 cruzarán. HTTP y sus mecanismos de seguridad únicamente hacen frente a la seguridad punto a punto. Es necesario que las soluciones más completas incorporen un concepto de seguridad de extremo a extremo. WS-Security trata el modo de mantener un contexto seguro a través de una ruta de mensajes de varios puntos. WS-Security aborda el tema de la seguridad haciendo uso de las especificaciones y los estándares existentes. Con ello se evita la necesidad de definir una solución de seguridad completa en WS-Security. La industria ha resuelto muchos de estos problemas. Kerberos y X.509 se ocupan del tema de la autenticación. Asimismo, X.509 emplea la infraestructura de clave pública (PKI) existente en la administración 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 especificación para un contenedor de metadatos de seguridad basado en XML. En el encabezado, los mensajes pueden almacenar información sobre el autor de la llamada y el modo en que se ha firmado y cifrado el mensaje. WS-Security presenta una solución extremo a extremo para la seguridad del servicio Web conservando toda la información de seguridad en la parte SOAP del mensaje. Los tres puntos siguientes son los principales aspectos presentes en el ámbito de la seguridad: 1. Autenticación 2. Firmas 3. Cifrado

Autenticación WS-Security proporciona un gran número de formas de validar a un usuario. En la especificación se abordan tres métodos de entre todos los demás: 1. Nombre de usuario y contraseña. 2. Infraestructura de clave pública (PKI) a través de certificados X.509. 3. Kerberos.

Informe de Tesina Proyecto Switch Transaccional

Página 34 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

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

Nombre de usuario y contraseña Una de las formas más comunes de transmitir las credenciales del remitente consiste en la combinación del nombre de usuario y contraseña. Esta técnica se utiliza en la autenticación implícita y básica HTTP.

Validación de un token de seguridad por un servicio

Informe de Tesina Proyecto Switch Transaccional

Página 35 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Certificados X.509 El simple envío de un certificado X.509 es otra opción en el proceso de autenticación 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 aplicación. El uso del certificado por sí mismo podría suponer el riesgo de sufrir ataques repetitivos con bastante facilidad. Por lo tanto, es una buena alternativa hacer que el remitente también firme el mensaje empleando su clave privada. De este modo, cuando se descifra el mensaje, se sabrá que se trata realmente del usuario.

Traducción 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 contraseña o un certificado X.509. Una vez realizada la comprobación 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 especificación interesante, ya que contiene un mecanismo para que el cliente pueda demostrar su identidad en un servicio y viceversa. El vale de servicio sólo 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 cómo se obtiene un vale o un vale de servicio.

Firma Cuando se firma un mensaje, es muy difícil 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 envío. Siempre que se pueda, se debe utilizar XML Signature, debido a que Informe de Tesina Proyecto Switch Transaccional

Página 36 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

ya administra una serie de elementos dificultosos que se pueden averiguar. WS-Security simplemente explica cómo 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 información 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 envía un número de tarjeta de crédito o de cuenta bancaria en texto sin formato y firmado, un intruso puede llegar a comprobar que ningún otro intruso haya modificado el contenido del mensaje. Por lo tanto, el intruso tendrá una gran seguridad de que los datos son válidos. Esto no beneficia al usuario en absoluto. Resultaría mucho más recomendable que los datos se cifraran de tal modo que sólo la persona a la que va destinado el mensaje pudiera consultarlos. Cualquier persona que observe el intercambio de conexión permanecería ajena respecto al contenido del mensaje. Tal y como sucede con la firma de mensajes, la especificación WS-Security toma las medidas adecuadas, adopta un estándar 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 simétrico o asimétrico. 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 simétrico resulta conveniente si se controlan ambos puntos finales y si las personas y aplicaciones que utilicen las claves son de confianza.

Emisión de un SecurityContextToken desde un servicio de tokens de seguridad

Si los datos se deben enviar utilizando claves fácilmente distribuidas, se debe considerar el uso del cifrado asimétrico. Los certificados X.509 lo permiten. El punto final que recibe los datos puede enviar públicamente su certificado y permitir a cualquier usuario o a todos ellos cifrar la información con la clave pública. 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

Página 37 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 innovación necesaria para transmitir de forma segura un mensaje SOAP. Debido a que toda la información se transmite en el propio mensaje, existirá una neutralidad de transporte. El mensaje puede estar seguro si se transmitiera mediante HTTP, correo electrónico o CD-ROM.

Informe de Tesina Proyecto Switch Transaccional

Página 38 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Capítulo 3 – Proyecto: Switch Transaccional Proceso de Implementación Para ejecutar el presente proyecto se definió un proceso general de desarrollo que actuó como marco de referencia y guía 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í también el conjunto de artefactos de resultado del mismo. Para un detalle completo ver: Anexo B – Proceso General de Implementación

ENTALLAMIENTO

DEL PROCESO DE IMPLEMENTACIÓN

El proceso general de implementación describe en forma general el proceso para implementar cualquier tipo de proyecto de tecnología. Pero el mismo debe ser adecuado a las realidades de cada proyecto. Por ello en esta sección 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 investigación en si. El cual se encuentra en el Capitulo 2 – Fundamentación Teórica la segunda particularidad es el aspecto solitario de implementación del presente proyecto, provocando esto que se haya tomado la decisión de utilizar metodologías, que si bien respetan al PGI, se adaptan mejor a este tipo de situación.

METODOLOGÍA

DE ADMINISTRACIÓN DE PROYECTO

Como se mencionó, para agilizar la gestión del proyecto, se ha decidido realizar la misma bajo la consigna de las metodologías Agile. Donde para garantizar su correcto uso se ha utilizado la herramienta XPlanner que se ha adaptado perfectamente a la tipología descripta, utilizando en particular la metodología eXtreme Programming (XP). A continuación se describe brevemente (según Wikipedia) en que consiste dicho paradigma: La programación extrema o eXtreme Programming (XP) es un enfoque de la ingeniería de software formulado por Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es la más destacada de los procesos ágiles de desarrollo de software. Al igual que éstos, la programación extrema se diferencia de las metodologías tradicionales principalmente en que pone más é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 aproximación mejor y más realista que intentar definir todos los requisitos al comienzo del proyecto e invertir esfuerzos después en controlar los cambios en los requisitos.Se puede considerar la programación extrema como la adopción de las mejores metodologías de desarrollo de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinámica durante el ciclo de vida del software.

Informe de Tesina Proyecto Switch Transaccional

Página 39 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Las características fundamentales del método son: ✔ Desarrollo iterativo e incremental: pequeñas mejoras, unas tras otras. ✔ Programación 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 código escrito de esta manera -el código es revisado y discutido mientras se escribe- es más importante que la posible pérdida de productividad inmediata. ✔ Frecuente interacción del equipo de programación con el cliente o usuario. Se recomienda que un

representante del cliente trabaje junto al equipo de desarrollo. ✔ Corrección de todos los errores antes de añadir nueva funcionalidad. Hacer entregas frecuentes. ✔ Refactorización del código, es decir, reescribir ciertas partes del código para aumentar su legibilidad y

mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorización no se ha introducido ningún fallo. ✔ Propiedad del código compartida: en vez de dividir la responsabilidad en el desarrollo de cada módulo en

grupos de trabajo distintos, este método promueve el que todo el personal pueda corregir y extender cualquier parte del proyecto. Las frecuentes pruebas de regresión garantizan que los posibles errores serán detectados. ✔ Simplicidad en el código: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podrá

añadir funcionalidad si es necesario. La programación extrema apuesta que es más sencillo hacer algo simple y tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizás nunca utilizarlo. La simplicidad y la comunicación son extraordinariamente complementarias. Con más comunicación resulta más fácil identificar qué se debe y qué no se debe hacer. Mientras más simple es el sistema, menos tendrá que comunicar sobre este, lo que lleva a una comunicación más completa, especialmente si se puede reducir el equipo de programadores.

Cronograma Original del Proyecto El proyecto original se había planteado en 8 iteraciones, ejecutando un total de 576 horas en 128 días.

FASES

DEL

PROYECTO

Informe de Tesina Proyecto Switch Transaccional

Página 40 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

TAREAS TRANSVERSALES (ADMINISTRACIÓN)

TAREAS VERTICALES (DESARROLLO)

Plan de infraestructura y Configuraciones INTRODUCCIÓN El presente documento tiene por objetivo describir la infraestructura (equipos informáticos, software y comunicaciones) requerida para el proceso de desarrollo e implementación de producto Switch Transaccional que será desarrollado dentro del marco de la Tesis de Licenciatura en informática de la Universidad de la Patagonia San Juan Bosco.

Informe de Tesina Proyecto Switch Transaccional

Página 41 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 sincronización 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 backend 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 implementación de Web-Services y el uso de BPEL.

Informe de Tesina Proyecto Switch Transaccional

Página 42 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Por otra parte existe un módulo de configuración del portal que estará desarrollado en JAVA en una arquitectura en capas utilizando para ello J2EE y el patrón Model-View-Controller.

DEFINICIÓN

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 configuración 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 aplicación a desarrollar que también deberán ser controlados por cada ambiente para mantener la integridad de la aplicación, su desarrollo y las pruebas que se deban realizar sobre la misma.

DESARROLLO Formalmente se utilizará la denominación DESA para referirnos a este ambiente. Es el ambiente donde se desarrolla todo el proceso implementación (Análisis, diseño y Construcción). Por proceso de implementación se entiende: ✔ Desarrollo de casos de usos: Requerimientos funcionales de la aplicación. ✔ Definición de los requerimientos no funcionales. ✔ Desarrollo de la Arquitectura y diseño. ✔ Construcción de la aplicación. ✔ Parametrización y definición de datos de los meta-modelos derivados de la Arquitectura.

Informe de Tesina Proyecto Switch Transaccional

Página 43 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

✔ Construcción de scripts para realizar las distintas pruebas de la aplicación y ajustes a las configuraciones

existentes. ✔ Construcción de componentes de ingeniería de sistemas y soporte.

TESTING Formalmente se utilizará la denominación 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 implementación), y donde además se realizan pruebas de carga. Especialmente en el desarrollo de la presente aplicación donde su característica de backend se basa fundamentalmente en la actividad transaccional de servicios Este ambiente también se utiliza en los procesos de capacitación. 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á también para el testeo de los paquetes de Deploy, garantizando que la aplicación de los mismos mantendrá la integridad en el ambiente PROD. En la sección Control de Configuraciones se detallan los procedimientos asociados al clonado de ambientes.

PRODUCCIÓN Formalmente se utilizará la denominación PROD para referirnos a este ambiente Es el ambiente de producción que se utilizará para uso de la Solución durante y luego de la finalización del proceso de implementación. El contenido de datos y funcionalidad de este ambiente va aumentando a medida que se avanza en el proceso de implementación 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 implementación 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 utilización por parte de los usuarios.

AMBIENTE

DE

DESARROLLO

Dada la génesis del proyecto donde la utilización y la producción de software de código abierto (Open Source) es un factor impulsor de la Sociedad de la Información. El ambiente de desarrollo del producto “Switch Transaccional” debe cumplir con las características mencionadas. Se debe mencionar que por las características del producto a construir se ha decidido la utilización de Java como lenguaje debido a la gran integración que posee el mismo con las tecnologías 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 utilización de Java como lenguaje. Dicho ambiente debía soportar además la utilización de PlugIns (componentes enchufables o lo que se conoce como tecnología de cartuchos). Dichos PlugIns debían permitir la incorporación de diversas herramientas para la realización del proyecto, no solo desde el punto de vista de desarrollo sino también para la Ingeniería de Requerimientos, Arquitectura, Diseño, Construcción, Testing y Documentación. En el proceso se investigaron y probaron varias herramientas de las cuales solo dos cumplían con los requisitos buscados: ✔ Eclipse de “Eclipse Foundation”

– ver http://www.eclipse.org/org/ ✔ NetBeans

Informe de Tesina Proyecto Switch Transaccional

Página 44 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 mayoría de los plugins requeridos eran desarrollados por la misma organización NetBeans. Lo que garantiza una mejor integración 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. También dentro de la selección 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 diseño BPEL muy importante para la realización del proyecto. En todos los casos si las condiciones del proyecto lo habilitan se realizarán las actualizaciones (o aplicación de parches) de los productos mencionados en el presente documento. Cuando esto sucede se notificaran los cambios realizados a las plataformas. Para el detalle técnico de cada producto se provee el link respectivo al web site del producto con la información técnica del mismo.

SOFTWARE

BASE

DE

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 ([email protected]) (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

GESTIÓN

– XPlanner Version 0.7b7 --> Herramienta de planificación, control y seguimiento de proyectos utilizando metodologías Agile (eXtreme Programming: XP) http://www.xplanner.org/ – OpenOffice.org 2.0.4 --> Herramienta de oficina que permiten gestionar documentos, planillas de cálculo 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

Página 45 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

– Controlador IDE: ATI 4379 Serial ATA Controller – Disco Rígido: 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 utilizarán un esquema de base de datos diferencial al igual que un deploy diferente en el servidor de aplicaciones.

AMBIENTE

DE PRODUCCIÓN

Para el ambiente de producción también se utilizará el mismo hardware, Soft de base y herramientas que para el ambiente de desarrollo. También aquí con el esquema de ambiente diferenciado para la Base de datos y servidor de aplicaciones. Pero dada la génesis de integración 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 ejecución

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 ([email protected]) (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 – GlassFish V2

DE APLICACIONES

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 Rígido: 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

Página 46 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

CONTROL

DE CONFIGURACIONES

METODOLOGÍA

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 instalación (PI) de cada versión integral deberá permitir actualizar la versión anterior, incrementando al misma un release. Así mismo se preve la generación de mini actualizaciones o parches que permitirán corregir problemas o defectos intermedios sin necesidad de esperar a la finalización de la iteración. Igualmente se deberá garantizar que todos los parches estén incluidos en el PI (paquete de Instalación) del release siguiente y el PI siguiente no deberá afectar ninguna instalación intermedia.

Definiciones PI --> Paquete de Instalación. El mismo contiene las siguientes secciones: DB: Actualización e instalación de tablas, vistas, triggers y procedimientos de la Base de datos. El script deberá prever e ir solicitando información así corresponda. Usuario de conexión y esquema a instalar. Será responsabilidad del instalador conocer el ambiente donde instalar y garantizar que se está instalando el script en dicho ambiente. También este proceso debe garantizar la actualización de datos cuando corresponda, salvo que se requiera intervención de los usuario en cuyo caso deberá quedar aclarado en la documentación general del PI XML --> Conjunto de XML, XSLT, DTS o XSD de la aplicación. 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 configuración de uso de la aplicación, como de definiciones de usuario como puede ser un proceso BPEL y una parser o transformación requerida. JAR --> Conjunto de paquetes Java con la aplicación 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 aplicación. 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 documentación de la aplicación. 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 cálculo, presentaciones y además todo el material UML desarrollado y mantenido en el análisis y diseño de la aplicación. Esto permitirá garantizar una trazabilidad entre los objetos de la aplicación y su documentación. AI --> Actualización Intermedia. Este paquete puede contener las mismas secciones anteriores salvo la sección DB. De esta forma se garantizará que los AI no contienen cambios estructurales a la aplicación. 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 aplicación mediante una arquitectura de meta información de la misma. Deberá quedar claro por lo tanto que no se podrá incluir ningún nuevo objeto de la aplicación que requiera de dichos cambios de Base de datos. Quedando las actualizaciones limitadas a solucionar problemas existentes en la aplicación que impiden realizar, por ejemplo, el plan de pruebas trazado.

Informe de Tesina Proyecto Switch Transaccional

Página 47 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

HERRAMIENTAS

PARA LA

ADMINISTRACIÓN

DEL

CONTROL

DE CONFIGURACIONES.

Como herramienta de administración y control de configuraciones se diseñará una pequeña base de datos que permita registrar las actualizaciones y la registración de parches instalados en cada ambiente, permitiendo de esta forma controlar los componentes y las revisiones de instalación de cada ambiente. Será muy importante la clara documentación de los PI y de los AI que permitirá realizar la trazabilidad de los componentes que contiene cada ambiente y su respectiva versión.

PLAN

DE

CONTINGENCIA

Debido a la génesis del proyecto no implica un mayor riesgo la administración 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 económicos afectados a la misma. Por lo tanto no se describirán posibles escenarios de amenaza ni impactos consecuentes de dichas amenazas. Sí se establecerá un esquema de resguardo del proyecto y una indicación de restauración del mismo y los tiempos incurridos para la restauración del mismo.

ESQUEMA

DE RESGUARDO Y RECUPERACIÓN DE AMBIENTES.

Toda la gestión y desarrollo del proyecto se administra desde un sólo equipo, por lo tanto el procedimiento que a continuación se describe afecta a dicho equipo utilizado en el ambiente DESA y TEST. No se preve respaldo del ambiente de producción ya que el mismo es reinstalable y recuperable desde los parches de actualización e instalación en producción.

HERRAMIENTA UTILIZADA

PARA LA GESTIÓN DE

BACKUP

Se ha decidido utilizar la herramienta Open Source Yakup (yet another backup script) que simplifica mediante el uso del comando tar la realización y gestión de copias de seguridad. Entre las principales características se puede mencionar: – Backup completo (full), incrementales y diferenciales. – Resguardo y recuperación desde disco rígido y medios removibles como CD o DVD. – Administración avanzada de medios. – Configuración de copias de seguridad mediante el uso de archivos de configuración. – Uso de tar. tar compatible. – Compresión de datos mediante uso de gzip o bzip2.

CONFIGURACIÓN 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

Página 48 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Administración del proyecto A continuación se realizará un resumen de la bitácora del proyecto según lo registrado en XPlanner. Para ello se utilizaran las facilidades de gestión 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 prevían iteraciones de 5 semanas cada una y se pasó a un módulo de 2 semanas cada una, esto debido al cambio de la metodología 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 módulo diario de trabajo de 4,5 horas a 3 o 4 horas, generando un desplazamiento en las fechas prevista de finalización. Comparativamente según el cronograma original se emplearían 576 horas en 128 días y como resultado final se emplearon 680 horas en 177 días. Lo cual representa un desvío del 18% en el total de horas y un desvío del 38.3% en el total de días (hábiles de ejecución).

DETALLE

DE

HORAS

POR

HISTORIAS

DEL USUARIO

(USER STORY) EJECUTADAS

EN EL

PROYECTO

Informe de Tesina Proyecto Switch Transaccional

Página 49 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 50 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 implementación a continuación se realiza un resumen de los principales hitos y/o entregables de cada iteración:

FASE LANZAMIENTO - ITERACIÓN 1 ✔ Se instalaron las herramientas iniciales de la infraestructura del proyecto.

FASE ELABORACIÓN - ITERACIÓN 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 ELABORACIÓN - ITERACIÓN 3 ✔ Se investigó y se escribió el trabajo sobre sociedad de la información y las herramientas tecnológicas

que fundamentan el presente trabajo.

FASE REFINAMIENTO - ITERACIÓN 4 ✔ Se establecieron los objetivos del Switch Transaccional. ✔ Se definieron los principales casos de uso y se priorizaron para su implementación.

FASE REFINAMIENTO - ITERACIÓN 5 ✔ Capacitación sobre las herramientas tecnológicas propuestas primera parte: XML, XSLT, XSD. ✔ Se definieron y especificaron las clases Java y las JSP correspondientes a la aplicación de administración

del Switch Transaccional.

FASE REFINAMIENTO - ITERACIÓN 6 ✔ Se desarrollaron todos las plantillas JSP que dan origen al estándar de visualización de la aplicación de

administración del Switch Transaccional. ✔ Se definió y construyó toda la ingeniería de base para la aplicación.

FASE REFINAMIENTO - ITERACIÓN 7, 8, 9

Y

10

✔ Etapa de construcción de software, donde Se implementaron las aplicaciones base, meta modelos y sus

pantallas para la configuración genérica del Switch Transaccional, Módulo de administración y comportamiento genérico.

FASE REFINAMIENTO - ITERACIÓN 11 ✔ Capacitación sobre las herramientas tecnológicas 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

Página 51 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 12 ✔ Testing del módulo de administración. ✔ Capacitación sobre las herramientas tecnológicas propuestas tercera parte: SOA y BPEL.

FASE REFINAMIENTO - ITERACIÓN 13, 14

Y

15

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

FASE REFINAMIENTO - ITERACIÓN 16

Y

17

✔ Construcción del motor BPEL del Switch Transaccional. ✔ Integración de los componentes desarrollados. ✔ Pruebas formales de integración de la solución. ✔ Desarrollo de ejemplo prototipo.

FASE CIERRE - ITERACIÓN 18 ✔ Elaboración del informe de tesina. ✔ Elaboración de la presentación para la defensa del proyecto.

Informe de Tesina Proyecto Switch Transaccional

Página 52 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Solución La solución 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 información de: http://switchtransaccional.googlecode.com donde en la pestaña “source” se puede obtener el código y documentación completa del proyecto. A fin de realizar el presente informe se realiza una síntesis 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 versión final.

ADMINISTRACIÓN

DEL

META-MODELO

DEL

SWITCH TRANSACCIONAL

Informe de Tesina Proyecto Switch Transaccional

Página 53 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

CONSUMIDORES (CLIENTES)

DEL

SWITCH TRANSACCIONAL

Informe de Tesina Proyecto Switch Transaccional

Página 54 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

PROVEEDORES

DEL

SWITCH TRANSACCIONAL

SWITCHTRANSACCIONAL

Informe de Tesina Proyecto Switch Transaccional

Página 55 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

DISEÑO

DEL

PROCESO

SWITCH TRANSACCIONAL DE

ATENCIÓN

DEL

SWITCH TRANSACCIONAL

Informe de Tesina Proyecto Switch Transaccional

Página 56 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

DIAGRAMAS

DE

SECUENCIA

Mensaje Sincrónico

Informe de Tesina Proyecto Switch Transaccional

Página 57 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Mensaje Asincrónico

Informe de Tesina Proyecto Switch Transaccional

Página 58 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

MODELO

DE

DATOS

A continuación 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

CONFIGURACIÓN GENÉRICO

Informe de Tesina Proyecto Switch Transaccional

Página 59 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

ENTIDADES EXTERNAS

Informe de Tesina Proyecto Switch Transaccional

Página 60 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

SERVICIOS

DEL

SWITCH TRANSACCIONAL

Informe de Tesina Proyecto Switch Transaccional

Página 61 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

COMPONENTES Las clases del Switch Transaccional se dividen en dos grupos, por un lado todas las clases necesarias para implementar el patrón 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 aplicación 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

Página 62 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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.

Páginas JSP Todas las páginas JSP se construyeron usando tags extendidos del Framework SOFIA. ➢ Aplicación Infraestructura ✔ AbmcAccesoMenu.jsp --> Implementa las altas, bajas, modificaciones y consultas de la configuración de

acceso a los menús 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 definición para

implementar atributos genéricos que puedan ser utilizados tanto por entidades externas como por cualquier tabla declarada en el diccionario de la aplicación. Utiliza el modelo infraestructura.models.AtributosRolModel y el controlador infraestructura.controllers.BaseController. ✔ AbmcClaseAtributoRol.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definición para

implementar clases de atributos genéricos o sea grupo de atributos que permitan clasificar y armar las pestañas genéricas en las pantallas de administración 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 definición

de valores asociados a un atributo genérico, permitiendo armar listas de validación dinámica 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 definición de

configuraciones genéricas en función de valores alcanzados por atributos genérico, permitiendo implementar comportamientos dinámicos 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 definición de

objetos de la aplicación 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 aplicación, pudiendo estos tomar uno o varios roles definido para la aplicación. También administra todos los atributos genéricos definidos para la entidad agrupándolos según 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 definición

de los posibles esquemas de configuración genérica que utilizará la aplicación. Utiliza el modelo infraestructura.models.EsquemaConfiguracionModel y el controlador infraestructura.controllers.AbmcEsquemaConfiguracionController. ✔ AbmcMenues.jsp --> Implementa las altas, bajas, modificaciones y consultas de los menús de la aplicación,

Informe de Tesina Proyecto Switch Transaccional

Página 63 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

permitiendo de esta forma configurar cualquier estructura de menú genérica. Utiliza el modelo infraestructura.models.MenuModel y el controlador infraestructura.controllers.BaseController. ✔ AbmcRolEntidad.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definición de los

posibles roles de entidades externas que se usarán en la aplicación. También permite asociar que atributos genéricos 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 definición de los roles de

usuario para implementar el acceso a la aplicación. 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

aplicación y los roles de acceso. Utiliza los modelos infraestructura.models.WebsiteUserModel e infraestructura.models.UsuarioRolesModel y el controlador infraestructura.controllers.WebSiteUserController. ➢ Aplicación SwitchTransaccional ✔ AbmcConfiguracionServicio.jsp --> Implementa las altas, bajas, modificaciones y consultas del

comportamiento específico 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 cómo 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 genéricos del mismo que darán 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 sección Páginas JSP y tiene como misión capturar las interacciones de los usuarios de las páginas web y la de aplicar las reglas de negocio respectivas para el correcto funcionamiento de las páginas. Todos los controladores derivan de infraestructura.controllers.BaseController que es el responsable de controlar el aspecto general de las páginas, como por ejemplo el menú y de la seguridad de acceso a la aplicación.

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 atención de servicios. Para un ejemplo ver .Diseño 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

Página 64 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

RecuperaAtributosServicio

AdministraLogSwitch

Informe de Tesina Proyecto Switch Transaccional

Página 65 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 66 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 67 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

DeterminaConfiguracionServicio

RESUMEN

DE

BPEL'S

Los BPEL de la solución son el corazón del Switch Transaccional ya que permiten acoplar y orquestar todas las actividades requeridas para recibir la solicitud de un servicio, interpretar según su contenido como se descompone el mismo, re-enviar todos las solicitudes que se requieran y re-ensamblar una respuesta. También en los BPEL se pueden implementar capas que permita realizar actividades de Parser y transformación de mensajes aplicando normalizaciones a los mismos

IMPLEMENTACIÓN

Y

PRUEBAS FORMALES

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

Informe de Tesina Proyecto Switch Transaccional

Página 68 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

PRESENTACIÓN

DE LOS CASOS

Caso: Solicitud de libre deuda municipal de un automotor Historia del usuario (Story Board) 1. Un dueño 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 función de los datos de la solicitud: código postal, y la zona determina que proceso de negocio (circuito) debe ejecutarse, pasándole 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 según 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 cuestión. 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

Página 69 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Definición XSD del mensaje propuesto

Informe de Tesina Proyecto Switch Transaccional

Página 70 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Casos testeados Caso 1 – Zona A

Caso 2 – Zona B

Caso 3 – Datos no concordantes

00002 Barry Demián DNI 18348567 Charcas 54 9120 Puerto Madryn Chubut Argentina A DSJ638

00002 Bail Nora DNI 18741168 Charcas 54 9120 Puerto Madryn Chubut Argentina B DSJ638

00002 Perez Pepito DNI 123456789 Roca 32 9000 Puerto Madryn Chubut Argentina C DSJ638

Informe de Tesina Proyecto Switch Transaccional

Página 71 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Configuración requerida

Informe de Tesina Proyecto Switch Transaccional

Página 72 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 73 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 74 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Capítulo 4 – Conclusiones La humanidad se encuentra hoy atravesando situaciones graves y complejas que están impactando en todos los sistemas: sociales, políticos, educativos, económicos, ambientales, tecnológicos, comunicacionales, etc. La discusión no puede ni debe reducirse a los sistemas ideológicos que en el pasado obraron como grandes impulsores de sistemas cerrados y estructurados, los análisis centrados entre los roles predominantes de lo público y/o lo privado, lo económico o lo social, la libertad o la planificación. Deberán dejar lugar al concepto de racionalidad, eficiencia y urgencia que la realidad demanda, pero en este análisis el hombre y su calidad de vida deberán ser el imperativo y centro de toda acción e indiscutible objeto final de cualquier sistema. La sociedad de la información y especialmente la democratización de la comunicación-información tendrán un rol protagónico en los objetivos de lograr la negentropía de los sistemas y evitar caos de los mismos. La calidad de vida se verán altamente impactadas por los sistemas comunicacionales, transaccionales e informáticos. En el futuro deberá decidirse con muy buena información proveniente de indicadores adecuados y monitoreo en línea y en tiempo real, cada situación de arbitraje entre los distintos sistemas y sub-sistemas de las organizaciones políticas, sociales y económicas. Con información adecuada se podrá, por ejemplo, dimensionar daños por impactos industriales en el medio ambiente, su impacto en la salud de la población involucrada, en el empleo, en la organización social, etc., etc. Podrán interactuar los sistemas y equilibrarse, pudiendo resolver en forma mas adecuada que la actual, en donde determinadas decisiones emanan de razones económicas o políticas sin medir su impacto en las consecuencias terribles en la calidad de vida y el costo asociado que de la misma deriva. Con la información en el momento que se necesita e interactiva se podrá analizar cada variable y los sistemas interactuarán mas equitativa y racionalmente. Más aún si entendemos que en el caso planteado, por lo menos en los países desarrollados y en vías de desarrollo, la brecha digital no es significativa debido a que no estamos hablando del acceso de la tecnología a las personas sino a las organizaciones. Más aún si consideramos que las tecnologías descriptas en su mayoría son de código abierto y por lo tanto de acceso público para su utilización, donde el aporte realizado por el Switch Transaccional engrosa sólo un poco más las herramientas de conocimiento y tecnología ya existentes, permitiendo como gran avance el procesamiento de las transacciones orientados al contenido, utilizando para ello reglas definidas en forma genérica. Por lo tanto el inconveniente económico 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 decisión política y social de cada país, donde lamentablemente en muchísimas ocasiones todos los recursos existen menos la voluntad de ponerlos en marcha. El futuro es hoy, porque si dilapidamos los recursos, habremos comprometido la razón de ser de las organizaciones humanas que es precisamente la sociedad en si misma.

Informe de Tesina Proyecto Switch Transaccional

Página 75 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Bibliografía Y Referencias 1. Katz, Ignacio. Retornar al pensamiento lógico. Revista Médicos Número, NEWSLETTER 82 / 24 de Marzo del 2003. 2. Jalfen, Luis J. Globalización y Lógica Virtual. Primera Edición, Ediciones Corregidor, 1998. 3. Morin, Edgar. El Método. Quinta Edición, Ediciones Cátedra, 1999. 4.

Barry, Jorge y Barry, Damián. La Salud en la Sociedad de la Información. 32º JAIIO (Jornadas Argentinas de Informática e Investigación Operativa – SIS 2003 (Simposio de Informática 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. Díaz Toledano, Moisés Daniel. Web Services -Introducción y Escenarios para su Uso. 8. OASIS. Organization for the Advancement of Structured Information Standards: http://www.oasisopen.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. Magíster 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

Página 76 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Anexos Anexo A - XML Tags usados para definir un mensaje SOAP DIS Ejemplo: El cliente necesita saber que producto corresponde con el código ID 827635 827635 El Servicio Web responde con el siguiente mensaje: Toptimate 3-Piece Set 827635 3-Piece luggage set. Black Polyester. 96.50 true

Informe de Tesina Proyecto Switch Transaccional

Página 77 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Anexo B – Proceso General de Implementación INTRODUCCIÓN El Proceso General de Implementación (PGI) provee un método disciplinado de asignación de tareas y responsabilidades aplicable al desarrollo de proyectos de tecnología de la información. El principal objetivo del PGI es el de asegurar la calidad de la implementación, 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 - Visión General Fases Lanzamiento

Tareas

Elaboración

Refinamiento

Cierre

Administración de Proyecto Relevamiento de Negocio Reingeniería de Procesos Requerimientos

Solución Implementación Migración e Integración Prueba Formal Puesta en Marcha Infraestructura Control de Configuración 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 cronológicamente. ➢ El eje vertical representa las tareas centrales del proceso, los cuales agrupan aquellas actividades que se relacionan entre si en forma natural. La primera dimensión representa el aspecto dinámico del proceso, y está expresado en términos de fases, iteraciones, e hitos. La segunda dimensión representa el aspecto estático del proceso, y está expresado en términos de tareas, actividades, roles, artefactos. Informe de Tesina Proyecto Switch Transaccional

Página 78 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Las tareas se clasifican en: ➢ Verticales: tareas directamente relacionadas con el objetivo de efectuar la implementación de la Solución; por ejemplo: Relevamiento de Negocio, Análisis y Diseño, Construcción, etc.. ➢ Transversales: tareas que se relacionan solo indirectamente con el objetivo de efectuar la implementación, y están orientadas a dar soporte o servicios a las tareas verticales. Pueden ser vistas como “ciclos” o “rutinas” que se repiten con mínimas variantes a lo largo del proyecto. El ejemplo típico de este tipo de tareas es la Administración del Proyecto. El diagrama anterior muestra cómo varía el énfasis a lo largo del tiempo (los recuadros con relleno sólido indican mayor énfasis que los recuadros con relleno punteado). Por ejemplo, en las primeras iteraciones se pone más énfasis en las actividades relacionadas con el relevamiento de las necesidades del Cliente y el análisis de las soluciones a las mismas, mientras que en las últimas iteraciones el énfasis está puesto en las actividades relacionadas con la implementación, migración de datos, prueba formal y puesta en marcha de la implementación. La base teórica del PGI se sustenta en dos principios fundamentales: ➢ La utilización de un método iterativo e incremental de implementación. ➢ El empleo de casos de uso para la administración de los requerimientos.

IMPLEMENTACIÓN

ITERATIVA

El método iterativo plantea una aproximación progresiva al resultado final en la concreción del proyecto, la cual se va desarrollando por medio de la ejecución 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 dinámico del proceso). Dentro de cada iteración 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 porción de la Solución (aspecto estático del proceso). Para permitir este avance gradual, el método prevé como cierre de cada iteración la entrega al Cliente de una versión “utilizable” de la Solución, y fomenta el uso de prototipos a lo largo de la implementación. El Cliente comprueba periódicamente la validez de las soluciones planteadas no solo por medio de la revisión de la documentación generada, sino también a través de de la utilización de las porciones de la Solución que van siendo implementadas. Las principales características del método son las siguientes: ➢ La Solución se construye en forma incremental, implementando los requerimientos gradualmente. ➢ Se dispone periódicamente de una versión utilizable de la Solución. ➢ 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 mecánica del proceso iterativo:

Informe de Tesina Proyecto Switch Transaccional

Página 79 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Tareas Verticales

I nicio de Fase

Tareas Transversales

Fase 1

Fin de Fase

Avance del P royecto

Varias it eraciones en cada Fase

I nicio de Fase

Fase n

Fin de Fase

CASOS

DE

USO

Los Casos de Uso (CU) constituyen una metodología de análisis de sistemas utilizada para identificar, clarificar y organizar requerimientos. Cada CU está compuesto por un conjunto de interacciones entre actores (personas físicas, personas jurídicas, aplicaciones, máquinas, etc.) dentro de un entorno específico, y en relación 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 colección de escenarios. La vista de escenarios de CU es esencial para la administración de los requerimientos, especialmente desde el punto de vista de su priorización e implementación 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 características: ➢ 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 propósitos: desarrollar los requerimientos de un proyecto de desarrollo o implementación de software, validar diseños, efectuar pruebas formales, etc. Una de las ventajas principales de su utilización 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 organización y por ende capturan los objetivos organizacionales. Informe de Tesina Proyecto Switch Transaccional

Página 80 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Las principales características 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 automatización de tareas o procesos. ➢ Un CU captura el contrato entre los actores internos de una organización acerca de sus responsabilidades en ella con respecto a dicha meta en particular. ➢ Un CU describe las responsabilidades de la Solución 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 propósitos 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 organización completa, de un sistema

funcionando dentro de dicha organización, o de un componente dentro de un sistema. ✔ Tener distintos niveles de objetivo: nivel estratégico, nivel de tareas, nivel de sub-función. ✔ Tener distintos niveles de definición: informal, descripción del escenario principal, descripción 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. Evalúa un escenario principal y sus excepciones. ✔ CU de Negocio: Describe los objetivos del negocio y las necesidades de automatización y control. Identifica a

los responsables del negocio, su visión 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 garantías mínimas 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 efectúan las estimaciones y la planificación 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 más relevantes del negocio, ya que los mismos constituyen el principal factor que guía y dirige los esfuerzos de implementación. 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 estén fuera del alcance deben derivar en mejoras a la Solución o en adecuaciones específicas realizadas dentro del marco del proyecto. Por razones de estandarización, el PGI adopta un formato específico de CU, cuyos detalles pueden ser consultados en la descripción del artefacto correspondiente. A continuación se muestra un ejemplo de formato de CU:

Informe de Tesina Proyecto Switch Transaccional

Página 81 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 descripción del actor principal (el interés del mismo está representado por el objetivo del caso de uso). Stakeholders e intereses: Nombre stakeholder + Interés del mismo sobre el caso de uso (estos intereses constituyen objetivos secundarios del caso de uso). Descripción: Descripción breve, simple y específica del caso de uso. Debe servir como ampliación del objetivo, y como “precalentamiento” del desarrollo del escenario habitual y sus extensiones. Puede aportar “background” o información que ponga en contexto al caso de uso. No debe confundírselo con un escenario. Garantía mínima: Indicación del estado de mínima propuesto para el caso de uso en función 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 excepción 1). 1.1.a

(Excepción al paso 1 de la excepción 1).

1.2. (Paso 2 de la excepción 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 común).

ELEMENTOS

DEL PROCESO ITERATIVO

HITOS Constituyen los puntos en los que una iteración finaliza formalmente, e implican (en la casi totalidad de los casos) un “release” de la implementación.

FASES Desde el punto de vista de la Administración 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 período de tiempo transcurrido entre dos hitos principales.

Informe de Tesina Proyecto Switch Transaccional

Página 82 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Al finalizar cada fase se realiza una evaluación para determinar si se han alcanzado los objetivos de la misma. Si el resultado de la evaluación es satisfactorio, el proyecto avanza hacia la próxima fase. Tal como puede apreciarse en el Diagrama de Visión General, las fases son disímiles entre si en cuanto a esfuerzo y planificación.

ITERACIONES Una iteración puede ser vista como un mini-proyecto dentro del proyecto general, dentro del cual se ejecutan (con un énfasis que varía de acuerdo al grado de avance del proyecto) todas las tareas que componen el PGI, resultando en la gran mayoría de los casos en una implementación completamente funcional (aunque parcial) de la Solución General. Cada iteración comienza con una planificación de las actividades, y culmina con un “release” de la implementación, el cual puede o no ser “puesto en producción”.

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 implementación. Cada rol tiene un conjunto cohesivo de actividades asignadas. Estas actividades se relacionan entre si, están acopladas funcionalmente, y se desarrollan más eficientemente si son realizadas por un mismo individuo. Asimismo, cada rol es responsable de la generación de un determinado conjunto de artefactos. Se debe notar que un rol no equivale a un individuo. La asignación entre individuos y roles, se efectúa durante el inicio del proyecto, y puede implicar que un mismo individuo desempeñe varios roles simultáneamente, y/o que un mismo rol sea desempeñado por varios individuos simultáneamente.

ACTIVIDADES Cada actividad representa una unidad de trabajo cuya realización le puede ser solicitada a cualquier individuo que desempeñe el rol al cual está asignada la actividad. La actividad debe tener un propósito bien definido, usualmente expresado en términos de la creación o la actualización de determinados artefactos. La granularidad de cada actividad debe ser tal que permita que la misma sea utilizada como un elemento significativo de planificación y evaluación 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 categorías: ➢ Pasos de elaboración, 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 revisión, 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 información entre todos los individuos que participan del mismo. Informe de Tesina Proyecto Switch Transaccional

Página 83 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 específica. Si bien una única persona es la “dueña” 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 administración 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 estandarización del contenido del mismo a lo largo del proyecto, sin importar cuáles fueron las personas que intervinieron en el desarrollo del artefacto.

TAREAS La mera enumeración de roles, actividades y artefactos no constituye en si un proceso. Para ello, es necesario además definir cómo se conjugan entre si todos estos elementos, especificando secuencias significativas de actividades que produzcan un resultado evaluable, y definir cómo interactúan entre si los distintos roles. Las definiciones precedentes se agrupan dentro de “tareas”, según un determinado criterio. De esta manera, una tarea es una colección de actividades relacionadas entre si, que pertenecen a un mismo “área de interés” 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 término “semi-ordenada” enfatiza el hecho de que las tareas no representan la planificación 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, subdividiéndolo en partes más pequeñas que el todo. A continuación 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: GESTIÓN DE PROYECTO (Solo Iteración Inicial)

Lanzamiento del Proyecto (Iteraciones subsecuentes)

Evaluar alcance y riesgos del Proyecto Planificar Iteración Desarrollar Plan General del Proyecto

Monitorear y Controlar el Proyecto Administrar Iteración

(Cierre de Proyecto) (Cierre de Fase) (Cierre de Iteración)

Cerrar Fase Cerrar Proyecto Evaluar alcance y riesgos del Proyecto

Informe de Tesina Proyecto Switch Transaccional

Página 84 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – 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 simultáneamente. 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. Típicamente se trabaja “en paralelo” en más de una actividad, y al hacerlo se tiene en cuenta más de un artefacto.

PROCESO GENERAL ANÁLISIS

DE

IMPLEMENTACIÓN - GENERALIDADES

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 diagnóstico de la situación y un relevamiento inicial del negocio desarrollado por el Cliente. Esta fase previa se denomina análisis de alcance. El mismo se ejecuta en forma previa al inicio del proyecto, y no forma parte del mismo. El análisis de alcance se realiza en base a un modelo de encuesta que permite evaluar la situación 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 efectúan sobre el “alcance marco” enunciado como resultado del análisis de alcance. Como mínimo, el alcance marco debe constar de: ➢ Una enumeración de los componentes de la Solución definidos por el Cliente, y el propósito 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 versión informal de los casos de uso relacionados con dichos objetivos. El resultado del diagnóstico efectuado se debe tomar como un pre-análisis de factibilidad, y debe garantizar que no surjan imprevistos considerables una vez iniciado el proyecto. Una vez efectuado el análisis 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 contratación adicional por parte del Cliente, a través de ampliaciones al proyecto primitivo. Adicionalmente, el análisis de alcance debe incluir también un detalle de los recursos que el Cliente se compromete a aportar al proyecto, discriminados según los roles previstos por el PGI, y detallando las capacidades de cada recurso comprometido.

PLANIFICACIÓN La Administración del Proyecto se efectúa basándose en dos artefactos fundamentales: ➢ Plan General ✔ Este artefacto se crea durante la Fase de Lanzamiento. ✔ Reúne toda la información 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 finalización de cada una de las iteraciones.

➢ Plan de Iteración ✔ Cada vez que se inicia una nueva iteración se crea una nueva instancia de este artefacto.

Informe de Tesina Proyecto Switch Transaccional

Página 85 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

✔ Por lo tanto, existe un ejemplar del mismo por cada iteración ejecutada. ✔ Contiene el cronograma detallado de cada iteración. ✔ Debe estar alineado con el Plan General. ✔ Tiene como objetivo la producción de una nueva versión de la Solución 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 mínimas excepciones). Los planes utilizados para la Administración del Proyecto establecen las políticas a utilizar para las distintas actividades del proyecto; son artefactos mayormente “estáticos”, en el sentido que se formulan tempranamente y luego sufren ajustes mínimos. Importante: La puesta en práctica de las políticas establecidas en los planes implica la generación de artefactos que registren el aspecto “dinámico” de dichas políticas, es decir, la “instanciación” de ciertos aspectos establecidos en los planes. Supongamos, por ejemplo, que el Plan de Aseguramiento de la Calidad establece que deberán calcularse ciertas métricas, y utilizarse ciertos criterios para evaluar la satisfacción del cliente. Estas políticas deben luego concretarse en determinados artefactos, dentro de los cuales se registrarán los valores reales calculados para las métricas en cada hito del proyecto, así como también el resultado de la evaluación de la satisfacción del cliente, es decir, el grado de satisfacción expresado con respecto a los criterios preestablecidos en el plan. El PGI2 contiene guías 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 guías y plantillas exhaustivos para cada uno de los artefactos “dinámicos” 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 guías establecen cómo se debe hacer, y la forma en que se registre el resultado y avance de las actividades se deja librada a la ejecución 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 relación se da fundamentalmente entre las tareas de Relevamiento de Negocio y Solución, por un lado, y las tareas de Implementación, Prueba Formal y Puesta en Marcha, por otro. Para comprender mejor esta situación, se presenta el siguiente ejemplo: ➢ Extracto del contenido de la Iteración n: ✔ … ✔ Relevar y desarrollar nuevos CU y sus respectivas extensiones: escenarios. ✔ …

➢ Extracto del contenido de la Iteración n+1: ✔ … ✔ Relevar y desarrollar nuevos CU. ✔ Refinar los CU desarrollados durante la iteración anterior. ✔ …

Informe de Tesina Proyecto Switch Transaccional

Página 86 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

✔ Implementar los escenarios seleccionados en el Plan de la Iteración, definidos en la iteración anterior. ✔ … ✔ Prueba formal de los escenarios implementados. ✔ …

➢ Extracto del contenido de la Iteración n+2: ✔ … ✔ Relevar y desarrollar nuevos CU y sus respectivas extensiones: escenarios. ✔ Refinar los CU desarrollados durante la iteración anterior. ✔ … ✔ Implementar los escenarios seleccionados en el Plan de la Iteración, definidos en la iteración 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 paralelización del trabajo: una parte del equipo se dedica a generar contenido para la próxima iteración, mientras otra parte se concentra en el contenido propio de la iteración en curso. Por otra parte, el ejemplo presentado permite apreciar los desafíos que plantea el método iterativo a la Administración de Proyecto, a la Administración del Cambio (coordinación con el impacto del cambio en los procesos del Cliente), a la Administración del Riesgo, y a la Administración de Configuraciones (existirán tantas versiones de la implementación como iteraciones se efectúen).

Cierre de iteraciones Al finalizar cada iteración se efectúa un cierre formal de la misma, durante el cual se evalúa el resultado de la iteración, determinando: ➢ Si se alcanzaron los objetivos previstos en la planificación inicial de la iteración ➢ Si el grado de calidad obtenido es satisfactorio ➢ Si se redujeron o eliminaron los riesgos detectados. Una vez efectuado el cierre de una iteración, y como primer paso dentro de la siguiente, se procede a planificar la nueva iteración. El resultado de la evaluación realizada al cierre de la iteración anterior constituye uno de los principales elementos utilizados como “entrada” de la planificación de la iteración que se inicia. Adicionalmente, y de acuerdo al resultado de la evaluación, 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 método iterativo, ya que representan una oportunidad de revisar frecuente y metódicamente el progreso y los riesgos del proyecto, y de tomar las decisiones necesarias para mantener al mismo dentro de la dirección apropiada.

Duración de las iteraciones A fines de mantener acotada la duración del proyecto, y de mantener el impulso del mismo en forma constante, se deberán 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

Página 87 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

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

FASES

E ITERACIONES DEL

PGI

A continuación se enumeran las fases e iteraciones sobre las que se estructura el PGI, las cuales definen el proceso desde el punto de vista dinámico:

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: ➢ Propósito y alcance del proyecto. ➢ Riesgos preponderante, hechos relevantes y principales supuestos. ➢ Formación de comités de trabajo, y establecimientos de roles y responsabilidades. ➢ Compromiso con respecto a las responsabilidades asumidas. ➢ Arquitectura de la Solución. ➢ Mecanismos de control de calidad a implementar. ➢ Estrategia y metodología a utilizar. Por lo general la Fase de Lanzamiento consta de una única iteración, la cual constituye la iteración 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 iteración se debe obtener mínimamente la instalación de todos las herramientas de infraestructura de la Solución que se requieran usar para poder ejecutar y elaborar todos los artefactos de la misma. Desde herramientas ofimáticas hasta herramientas de análisis y desarrollo. Con respecto a la tarea de Administración de Proyecto, el resultado de esta fase es la versión 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 instalación del hardware y software necesario para el funcionamiento de la Solución, la generación de ambientes de implementación, la creación de instancias de base de datos, y la preparación 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 implementación utiliza el PGI, puede incluirse en la Fase de Lanzamiento una breve capacitación al mismo acerca del proceso, con el objetivo de que todos los recursos estén alineados desde el punto de vista de la metodología de implementación a utilizar.

FASE

DE

ELABORACIÓN

La Fase de Elaboración tiene como objetivo la recopilación 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 Solución y de los Artefactos que describen la Solución. 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 Elaboración consta de dos iteraciones, dentro de las que se efectúa el desarrollo del 95% de la Arquitectura de la Solución y los Casos de Uso a implementar dentro del proyecto.

Informe de Tesina Proyecto Switch Transaccional

Página 88 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE

DE

REFINAMIENTO

Durante la Fase de Refinamiento se registra una reducción significativa en las tareas de Relevamiento de Negocio y Solución; las actividades sobre estas áreas del proceso se deben concentrar en la depuración y refinación de la Arquitectura de la Solución y los Casos de Uso recopilados durante la Fase de Elaboración. 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 efectúa el mayor esfuerzo con respecto a las tareas de Implementación y Prueba Formal de la implementación, procediéndose a plasmar las soluciones enunciadas en el Documento de Solución. Con respecto a la tarea de Migración de datos e integración de aplicaciones, como resultado de la ejecución de esta fase se debe finalizar el desarrollo de la migración de datos. El objetivo en este punto es que finalizada la Fase de Refinamiento, la única actividad que quede pendiente en relación a esta área sea la ejecución de la migración de datos definitiva (la cual debe realizarse en la última iteración del proyecto, dentro de la Fase de Cierre). Por lo general la Fase de Refinamiento consta de tres o ocho iteraciones, según el volumen del proyecto, cada una de las cuales aporta sucesivamente un mayor grado de refinamiento a la implementación.

FASE

DE

CIERRE

Los principales objetivos de la Fase de Cierre son los siguientes: ➢ Cierre de la Arquitectura de la Solución y del Documento de Solución. ➢ Migración de datos definitiva. ➢ Puesta en marcha global. ➢ Desconexión de sistemas legados, si existen. Es decir que durante el transcurso de esta fase se debe lograr que la implementación de la Solución esté completamente disponible para su utilización efectiva por parte de los usuarios finales (tanto desde el punto de vista de la implementación de la totalidad de los CU recopilados, como desde el punto de vista de la completitud de la implementación de cada uno de dichos CU), de manera que se pueda proceder a la desconexión definitiva de los sistemas legados. Con respecto a las tareas verticales, al iniciarse esta fase las tareas de Relevamiento de Negocio, Solución e Implementación deben haberse completado casi totalmente, previendo únicamente: ➢ La realización de ajustes finales mínimos a la Arquitectura de la Solución, Casos de Uso y Documento de Solución. ➢ La implementación de los CU definidos durante la iteración anterior. ➢ La ejecución de la migración 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 implementación) 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 iteración, la cual constituye la iteración final del proyecto.

ROLES

DEL

PGI

A continuación se incluye una descripción resumida de todos los roles previstos en el PGI:

Informe de Tesina Proyecto Switch Transaccional

Página 89 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Rol

Comité de Dirección

Abreviatura

CDI

El Comité de Dirección resuelve los conflictos que pudiesen surgir entre las partes intervinientes en el proyecto, toma las decisiones de alto nivel y es responsable de la solución final de implementación.

Descripción

Es el responsable de la toma decisiones con respecto a los cambios de alcance que pudieran surgir a lo largo del proyecto. Es responsable de la economía 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 Líderes de Proyecto. En su integración participan representantes de todas las organizaciones y áreas que participan del proyecto.

Rol

Comité de Ejecución

Abreviatura

CEJ

El Comité de Ejecución organiza y controla las actividades, asigna prioridades, administra y analiza los riesgos. Descripción

Administra, prioriza y selecciona los escenarios a implementar en cada iteración del proyecto. El Comité de Ejecución está conformado por Líderes de Proyecto, asistidos por Consultores Funcionales, y por Usuarios Clave. En su integración 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 políticas y de administrar el Control de Cambios sobre la solución que está siendo implementada. Descripción

Está compuesto por integrantes pertenecientes a todas las organizaciones y áreas que participan del proyecto. Dependiendo de la envergadura del proyecto, este rol puede estar cubierto por el Comité de Ejecución.

Rol

Comité de Control de Calidad

Abreviatura

CCA

El Comité de Control de Calidad es el responsable de establecer las políticas y de administrar el Control de Calidad del proyecto. Descripción

Está compuesto por integrantes pertenecientes a todas las organizaciones y áreas que participan del proyecto. Dependiendo de la envergadura del proyecto, este rol puede estar cubierto por el Comité de Ejecución.

Informe de Tesina Proyecto Switch Transaccional

Página 90 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Rol

Descripción

Gerente de Proyecto

Abreviatura

GP

El Gerente de Proyecto es el responsable de dirigir el proyecto, y de patrocinarlo desde los aspectos políticos, económicos y ejecutivos, garantizando la disponibilidad de los recursos comprometidos.

Rol

Líder de Proyecto

Descripción

El Líder de Proyecto establece la estrategia y la planificación del proyecto, monitorea el estado del mismo, administra los riesgos y contingencias, dirige al equipo de trabajo, y gestiona la infraestructura edilicia y de comunicaciones.

Rol

Consultor Funcional

Descripción

El Consultor Funcional releva y analiza las características del negocio, desarrolla los casos de uso de negocio, y define cómo se implementará la Solución para resolver dichos casos de uso.

Rol

Consultor Técnico

Descripción

El Consultor Técnico administra la infraestructura tecnológica y los ambientes de implementación, implementa las soluciones que requieran del desarrollo de software, desarrolla migraciones e integraciones entre aplicaciones, y efectúa el Control de Configuración.

Rol

Testeador

Descripción

El Testeador ejecuta las pruebas formales de las soluciones implementadas.

Rol

Administrador de Sistema

Descripción

El Administrador de Sistema es responsable de la infraestructura del proyecto con respecto al software y al hardware.

Rol

Administrador de Base de Datos

Descripción

El Administrador de Base de Datos es responsable de la infraestructura del proyecto con respecto a las bases de datos requeridas por la implementación.

Abreviatura

Abreviatura

Abreviatura

Abreviatura

Abreviatura

Abreviatura

LP

CF

CT

TE

ASIS

ABD

Informe de Tesina Proyecto Switch Transaccional

Página 91 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Rol

Usuario Clave

Descripción

El Usuario Clave proporciona los objetivos de negocio que el proyecto debe alcanzar, describe el funcionamiento del negocio a través de casos de uso, configura la Solución, valida los resultados intermedios del proyecto, y es el responsable de la aprobación final de la implementación.

Rol

Usuario Final

Descripción

El Usuario Final es el responsable de la operación de la Solución, una vez que la misma ha sido puesta en marcha.

ACTIVIDADES, RESPONSABLES TAREAS

VERTICALES DEL

Abreviatura

Abreviatura

Y

ENTREGABLES

DEL

UC

UF

PGI

PROCESO

Tarea

Relevamiento de Negocio

Subtarea

Requerimientos

Objetivo



Relevar, analizar y compilar los requerimientos de implementación.



La tarea de Solución utiliza los artefactos producidos por esta tarea como base para el desarrollo del Documento de Solución. La tarea de Prueba Formal utiliza los Casos de Uso producidos por esta tarea para el desarrollo de los Casos de Test. La tarea de Administración de Proyecto utiliza los artefactos producidos por esta tarea como base para la planificación de las iteraciones.

Relación con otras tareas

 

Matriz de actividades y roles Actividad

Responsable

Participa

Desarrollar Arquitectura de la Solución

CF

Validar Arquitectura de la Solución

UC

CF

Desarrollar y Priorizar Casos de Uso

CF

UC

Administrar cambios a los requerimientos

LP

Aprueba LP CEJ

CCC

Artefactos relacionados Entrada

Salida Informe de Tesina

Proyecto Switch Transaccional

Página 92 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Plan de la Iteración Modelo de Procesos de Negocio

Arquitectura de la Solución Caso de Uso Diagrama de Secuencia Diagrama de Clases Diagrama de actividades.

Tarea

Solución / Diseño

Objetivo



Analizar y diseñar cómo se implementará la Solución para cumplir con los requerimientos del Cliente.



La tarea de Relevamiento de Negocio recopila los requerimientos a los cuales tiene que dar solución esta tarea. La tarea de Implementación utiliza los artefactos producidos por esta tarea como base para la realización de las actividades de construcción de la Solución.

Relación con otras tareas



Matriz de actividades y roles Actividad

Responsable

Participa

Aprueba

Analizar soluciones

CF

Desarrollar Documento de Solución

CF

UC

LP

Validar Documento de Solución

UC

CF

CEJ

Artefactos relacionados Entrada

Salida

Plan de la Iteración Caso de Uso Arquitectura de la Solución

Documento de Diseño Diagrama de clases Diagrama de secuencia Diagrama de actividades Diagrama de estados Diagrama de Componentes Diagrama de distribución

Tarea

Construcción

Objetivo



Implementar la Solución de acuerdo a lo indicado en los artefactos de Solución.



La tarea de Solución especifica las soluciones que deben ser efectivizadas por esta tarea. El resultado del desarrollo de esta tarea se valida y verifica dentro de la tarea de Prueba Formal.

Relación con otras tareas



Matriz de actividades y roles Informe de Tesina Proyecto Switch Transaccional

Página 93 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Actividad

Responsable

Desarrollar Guía de Implementación

CT

Efectuar configuraciones

UC

Desarrollar Componentes

CT

Desarrollar DB

CT

Desarrollar UI

CT

Participa

Aprueba LP

CT

Artefactos relacionados Entrada

Salida

Plan de la Iteración Documento de Solución

Guía de Implementación Manual de usuario Componentes Interfaces DB

Tarea

Prueba Formal

Objetivo

 

Verificar el correcto funcionamiento de las soluciones implementadas. Capacitar a Usuarios Clave.



La tarea de Relevamiento de Negocio genera como resultado los Casos de Uso sobre los cuales se basa el diseño de las pruebas a ejecutar dentro de esta tarea. Las tareas de Construcción implementan las soluciones que son validadas por esta tarea. La tarea de Administración 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 planificación de cada iteración.

Relación con otras tareas

 

Matriz de actividades y roles Actividad

Responsable

Participa

Planificar Prueba Formal

LP

Diseñar Prueba Formal

CF

UC

Capacitar a Usuarios Clave

CF

UC / TE

Ejecutar Prueba Formal

TE

UC

Evaluar Prueba Formal

UC

CF

Aprueba CEJ

CEJ

Informe de Tesina Proyecto Switch Transaccional

Página 94 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Artefactos relacionados

Entrada

Salida

Plan de la Iteración Caso de Uso Arquitectura de la Solución

Plan de Prueba Formal Casos de Test Resultados de Prueba Formal

Tarea

Puesta en Marcha

Objetivo

 

Ejecutar la Solución en un entorno de producción real. Obtener la aceptación formal de la Solución por parte del Cliente.



La tarea de Implementación implementa las soluciones que son puestas en marcha en esta tarea. La tarea de Administración de Proyecto utiliza la evaluación de la ejecución en paralelo como uno de los elementos a tener en cuenta al efectuar la planificación de cada iteración.

Relación con otras tareas



Matriz de actividades y roles Actividad

Responsable

Participa

Planificar Puesta en Marcha

LP

Capacitar a Usuarios Finales

UC

UF

Ejecutar paralelo

UC / UF

CF

Evaluar ejecución en paralelo

UC / UF

Aprueba CEJ

CEJ

Artefactos relacionados Entrada

Salida

Plan de la Iteración Manual del Usuario

TAREAS

Documento de evaluación de ejecución en paralelo

TRANSVERSALES DEL

PROCESO

Tarea

Administración de Proyecto

Objetivo

   

Definir la organización del proyecto. 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

Página 95 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

desviaciones y costos ocultos. 

Relación con otras tareas

Esta tarea establece la estructura general dentro de la que se enmarcan todas las demás tareas del proyecto. 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 Iteración

LP

GP

CDI

Administrar iteración

LP

GP

Cerrar Iteración

LP

CEJ

CDI

Cerrar Proyecto

LP

CEJ

CDI

Artefactos relacionados Entrada

Salida

Caso de Uso Arquitectura de la Solución Mapa de Integración

Tarea

Control de Configuración 

Objetivo  Relación con otras tareas

Plan General Plan de Iteración Lista de Riesgos Documento de Aceptación y Cierre



Controlar y efectuar el seguimiento y versionado del contenido de los ambientes de implementación. 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 tanto se relaciona con todas las demás tareas del mismo. Matriz de actividades y roles

Actividad

Responsable

Participa

Aprueba

Desarrollar Plan de Control de Configuración

LP

CT

CCC

Administrar línea base y actualizaciones

CT

LP

Informe de Tesina Proyecto Switch Transaccional

Página 96 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Administrar Control de Cambios

CT

LP

Monitorear y reportar estado de configuración

CT

LP

CCC

Artefactos relacionados Entrada

Salida

Plan de la Iteración

Plan de Administración de Configuración. CVS

Tarea

Aseguramiento de Calidad

Objetivo

  

Establecer los estándares de calidad para el proyecto. Establecer las estrategias y mecanismos de control de calidad. Controlar la calidad del proceso de implementación y de los diversos entregables.



Aseguramiento de Calidad es una de las tareas de soporte del proceso, y por lo tanto se relaciona con todas las demás tareas del mismo.

Relación con otras tareas

Matriz de actividades y roles Actividad

Responsable

Participa

Aprueba

Desarrollar Plan de Aseguramiento de Calidad

LP

CCA

Monitorear calidad de la implementación

LP

CCA

Monitorear calidad del proceso de implementación

LP

CCA

Monitorear calidad de artefactos

LP

CCA

Artefactos relacionados Entrada Plan de la Iteración

Salida Plan de Aseguramiento de calidad Evaluaciones Métricas e Indicadores

Informe de Tesina Proyecto Switch Transaccional

Página 97 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Anexo C: Detalle del Sistema Operativo Linux version 2.6.20-1.2952.fc6 ([email protected]) (gcc version 4.1.1 20070105 (Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007 Command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f000 (usable) BIOS-e820: 000000000009f000 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003dee0000 (usable) BIOS-e820: 000000003dee0000 - 000000003dee3000 (ACPI NVS) BIOS-e820: 000000003dee3000 - 000000003def0000 (ACPI data) BIOS-e820: 000000003def0000 - 000000003df00000 (reserved) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 253664) 1 entries of 3200 used end_pfn_map = 1048576 DMI 2.3 present. ACPI: RSDP (v000 RS485 )@ 0x00000000000f8080 ACPI: RSDT (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003dee3040 ACPI: FADT (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003dee30c0 ACPI: SSDT (v001 PTLTD POWERNOW 0x00000001 LTP 0x00000001) @ 0x000000003dee7740 ACPI: MCFG (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003dee7980 ACPI: MADT (v001 RS485 AWRDACPI 0x42302e31 AWRD 0x00000000) @ 0x000000003dee7680 ACPI: DSDT (v001 RS485 AWRDACPI 0x00001000 MSFT 0x0100000e) @ 0x0000000000000000 Scanning NUMA topology in Northbridge 24 Number of nodes 1 Node 0 MemBase 0000000000000000 Limit 000000003dee0000 Entering add_active_range(0, 0, 159) 0 entries of 3200 used Entering add_active_range(0, 256, 253664) 1 entries of 3200 used NUMA: Using 63 for the hash shift. Using node hash shift of 63 Bootmem setup node 0 0000000000000000-000000003dee0000 Zone PFN ranges: DMA 0 -> 4096 DMA32 4096 -> 1048576 Normal 1048576 -> 1048576 early_node_map[2] active PFN ranges 0: 0 -> 159 0: 256 -> 253664 On node 0 totalpages: 253567 DMA zone: 64 pages used for memmap DMA zone: 1337 pages reserved DMA zone: 2598 pages, LIFO batch:0 DMA32 zone: 3899 pages used for memmap DMA32 zone: 245669 pages, LIFO batch:31 Normal zone: 0 pages used for memmap ATI board detected. Disabling timer routing over 8254. ACPI: PM-Timer IO Port: 0x4008 ACPI: Local APIC address 0xfee00000 ACPI: LAPIC (acpi_id[0x00] lapic_id[0x00] enabled) Processor #0 (Bootup-CPU) ACPI: LAPIC (acpi_id[0x01] lapic_id[0x01] enabled) Processor #1 ACPI: LAPIC_NMI (acpi_id[0x00] high edge lint[0x1]) ACPI: LAPIC_NMI (acpi_id[0x01] high edge lint[0x1])

ACPI: IOAPIC (id[0x02] address[0xfec00000] gsi_base[0]) IOAPIC[0]: apic_id 2, address 0xfec00000, GSI 0-23 ACPI: INT_SRC_OVR (bus 0 bus_irq 0 global_irq 2 dfl dfl) ACPI: INT_SRC_OVR (bus 0 bus_irq 9 global_irq 21 low level) ACPI: IRQ0 used by override. ACPI: IRQ2 used by override. Setting APIC routing to physical flat Using ACPI (MADT) for SMP configuration information Nosave address range: 000000000009f000 - 00000000000a0000 Nosave address range: 00000000000a0000 - 00000000000f0000 Nosave address range: 00000000000f0000 - 0000000000100000 Allocating PCI resources starting at 40000000 (gap: 3df00000:a2100000) SMP: Allowing 2 CPUs, 0 hotplug CPUs PERCPU: Allocating 43264 bytes of per cpu data Built 1 zonelists. Total pages: 248267 Kernel command line: ro root=/dev/VolGroup00/LogVol00 rhgb quiet Initializing CPU#0 PID hash table entries: 4096 (order: 12, 32768 bytes) Console: colour VGA+ 80x25 Dentry cache hash table entries: 131072 (order: 8, 1048576 bytes) Inode-cache hash table entries: 65536 (order: 7, 524288 bytes) Checking aperture... CPU 0: aperture @ d3b4000000 size 32 MB Aperture too small (32 MB) No AGP bridge found Memory: 988476k/1014656k available (2454k kernel code, 25792k reserved, 1458k data, 312k init) Calibrating delay using timer specific routine.. 4001.98 BogoMIPS (lpj=2000993) Security Framework v1.0.0 initialized SELinux: Initializing. SELinux: Starting in permissive mode selinux_register_security: Registering secondary module capability Capability LSM initialized as secondary Mount-cache hash table entries: 256 CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU 0/0 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 0 SMP alternatives: switching to UP code ACPI: Core revision 20060707 Using local APIC timer interrupts. result 12499179 Detected 12.499 MHz APIC timer. SMP alternatives: switching to SMP code Booting processor 1/2 APIC 0x1 Initializing CPU#1 Calibrating delay using timer specific routine.. 3998.94 BogoMIPS (lpj=1999474) CPU: L1 I Cache: 64K (64 bytes/line), D cache 64K (64 bytes/line) CPU: L2 Cache: 256K (64 bytes/line) CPU 1/1 -> Node 0 CPU: Physical Processor ID: 0 CPU: Processor Core ID: 1 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ stepping 02 CPU 1: Syncing TSC to CPU 0. CPU 1: synchronized TSC with CPU 0 (last diff -2 cycles, maxerr 505 cycles) Brought up 2 CPUs Disabling vsyscall due to use of PM timer time.c: Using 3.579545 MHz WALL PM GTOD PM timer. time.c: Detected 1999.866 MHz processor.

Informe de Tesina Proyecto Switch Transaccional

Página 98 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

sizeof(vma)=176 bytes sizeof(page)=64 bytes sizeof(inode)=720 bytes sizeof(dentry)=224 bytes sizeof(ext3inode)=968 bytes sizeof(buffer_head)=104 bytes sizeof(skbuff)=248 bytes sizeof(task_struct)=1920 bytes migration_cost=117 NET: Registered protocol family 16 ACPI: bus type pci registered PCI: Using configuration type 1 ACPI: Interpreter enabled ACPI: Using IOAPIC for interrupt routing ACPI: PCI Root Bridge [PCI0] (0000:00) PCI: Probing PCI hardware (bus 00) ACPI: Assume root bridge [\_SB_.PCI0] bus is 0 Boot video device is 0000:01:05.0 PCI: Transparent bridge - 0000:00:14.4 ACPI: PCI Interrupt Routing Table [\_SB_.PCI0._PRT] ACPI: PCI Interrupt Link [LNKA] (IRQs 3 4 5 6 7 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKB] (IRQs 3 4 5 6 7 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKC] (IRQs 3 4 5 6 7 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKD] (IRQs 3 4 5 6 7 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKE] (IRQs 3 4 5 6 7 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNKF] (IRQs 3 4 5 6 7 10 11) *0, disabled. ACPI: PCI Interrupt Link [LNK0] (IRQs 3 4 5 6 7 *10 11) ACPI: PCI Interrupt Link [LNK1] (IRQs 3 4 5 6 7 10 *11) ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.P2P_._PRT] ACPI: PCI Interrupt Routing Table [\_SB_.PCI0.AGP_._PRT] Linux Plug and Play Support v0.97 (c) Adam Belay pnp: PnP ACPI init pnp: PnP ACPI: found 14 devices usbcore: registered new interface driver usbfs usbcore: registered new interface driver hub usbcore: registered new device driver usb PCI: Using ACPI for IRQ routing PCI: If a device doesn't work, try "pci=routeirq". If it helps, post a report NetLabel: Initializing NetLabel: domain hash size = 128 NetLabel: protocols = UNLABELED CIPSOv4 NetLabel: unlabeled traffic allowed by default pnp: 00:01: ioport range 0x140-0x15f has been reserved pnp: 00:01: ioport range 0x228-0x22f has been reserved pnp: 00:01: ioport range 0x40b-0x40b has been reserved pnp: 00:01: ioport range 0x4d6-0x4d6 has been reserved pnp: 00:01: ioport range 0xc00-0xc01 has been reserved pnp: 00:01: ioport range 0xc14-0xc14 has been reserved pnp: 00:01: ioport range 0xc50-0xc52 has been reserved pnp: 00:01: ioport range 0xc6c-0xc6d has been reserved PCI: Bridge: 0000:00:01.0 IO window: e000-efff MEM window: fde00000-fdefffff PREFETCH window: f8000000-fbffffff PCI: Bridge: 0000:00:14.4 IO window: d000-dfff MEM window: fdd00000-fddfffff PREFETCH window: fdc00000-fdcfffff NET: Registered protocol family 2 IP route cache hash table entries: 32768 (order: 6, 262144 bytes) TCP established hash table entries: 131072 (order: 10, 4194304 bytes) TCP bind hash table entries: 65536 (order: 9, 2097152 bytes) TCP: Hash tables configured (established 131072 bind 65536) TCP reno registered checking if image is initramfs... it is Freeing initrd memory: 2323k freed audit: initializing netlink socket (disabled)

audit(1181402237.442:1): initialized Total HugeTLB memory allocated, 0 VFS: Disk quotas dquot_6.5.1 Dquot-cache hash table entries: 512 (order 0, 4096 bytes) SELinux: Registering netfilter hooks ksign: Installing public key data Loading keyring - Added public key A2C7955D82CFA151 - User ID: Red Hat, Inc. (Kernel Module GPG key) io scheduler noop registered io scheduler anticipatory registered io scheduler deadline registered io scheduler cfq registered (default) 0000:00:13.2 EHCI: BIOS handoff failed (BIOS bug ?) 01010001 pci_hotplug: PCI Hot Plug PCI Core version: 0.5 ACPI: Fan [FAN] (on) ACPI: Thermal Zone [THRM] (29 C) Real Time Clock Driver v1.12ac Non-volatile memory driver v1.2 Linux agpgart interface v0.101 (c) Dave Jones Serial: 8250/16550 driver $Revision: 1.90 $ 4 ports, IRQ sharing enabled serial8250: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A 00:08: ttyS0 at I/O 0x3f8 (irq = 4) is a 16550A RAMDISK driver initialized: 16 RAM disks of 16384K size 4096 blocksize input: Macintosh mouse button emulation as /class/input/input0 Uniform Multi-Platform E-IDE driver Revision: 7.00alpha2 ide: Assuming 33MHz system bus speed for PIO modes; override with idebus=xx ATIIXP: IDE controller at PCI slot 0000:00:14.1 ACPI: PCI Interrupt 0000:00:14.1[A] -> GSI 16 (level, low) -> IRQ 16 ATIIXP: chipset revision 128 ATIIXP: not 100% native mode: will probe irqs later ide0: BM-DMA at 0xf300-0xf307, BIOS settings: hda:DMA, hdb:pio ide1: BM-DMA at 0xf308-0xf30f, BIOS settings: hdc:pio, hdd:pio Probing IDE interface ide0... hda: HL-DT-STDVD-RAM GSA-H20N, ATAPI CD/DVD-ROM drive ide0 at 0x1f0-0x1f7,0x3f6 on irq 14 Probing IDE interface ide1... Probing IDE interface ide1... ide-floppy driver 0.99.newide usbcore: registered new interface driver libusual usbcore: registered new interface driver hiddev usbcore: registered new interface driver usbhid drivers/usb/input/hid-core.c: v2.6:USB HID core driver PNP: PS/2 Controller [PNP0303:PS2K,PNP0f13:PS2M] at 0x60,0x64 irq 1,12 serio: i8042 KBD port at 0x60,0x64 irq 1 serio: i8042 AUX port at 0x60,0x64 irq 12 mice: PS/2 mouse device common for all mice input: AT Translated Set 2 keyboard as /class/input/input1 TCP bic registered Initializing XFRM netlink socket NET: Registered protocol family 1 NET: Registered protocol family 17 powernow-k8: Found 2 AMD Athlon(tm) 64 X2 Dual Core Processor 3600+ processors (version 2.00.00) powernow-k8: 0 : fid 0xc (2000 MHz), vid 0xe powernow-k8: 1 : fid 0xa (1800 MHz), vid 0x10 powernow-k8: 2 : fid 0x2 (1000 MHz), vid 0x12 ACPI: (supports S0 S3 S4 S5) Freeing unused kernel memory: 312k freed Write protecting the kernel read-only data: 1042k firmware_class: attempt to set timeout to 10 USB Universal Host Controller Interface driver v3.0 ohci_hcd: 2006 August 04 USB 1.1 'Open' Host Controller (OHCI) Driver (PCI) ACPI: PCI Interrupt 0000:00:13.0[A] -> GSI 19 (level, low) -> IRQ 19

Informe de Tesina Proyecto Switch Transaccional

Página 99 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

ohci_hcd 0000:00:13.0: OHCI Host Controller ohci_hcd 0000:00:13.0: new USB bus registered, assigned bus number 1 ohci_hcd 0000:00:13.0: irq 19, io mem 0xfe02d000 usb usb1: configuration #1 chosen from 1 choice hub 1-0:1.0: USB hub found hub 1-0:1.0: 4 ports detected ACPI: PCI Interrupt 0000:00:13.1[A] -> GSI 19 (level, low) -> IRQ 19 ohci_hcd 0000:00:13.1: OHCI Host Controller ohci_hcd 0000:00:13.1: new USB bus registered, assigned bus number 2 ohci_hcd 0000:00:13.1: irq 19, io mem 0xfe02c000 usb usb2: configuration #1 chosen from 1 choice hub 2-0:1.0: USB hub found hub 2-0:1.0: 4 ports detected ACPI: PCI Interrupt 0000:00:13.2[A] -> GSI 19 (level, low) -> IRQ 19 ehci_hcd 0000:00:13.2: EHCI Host Controller ehci_hcd 0000:00:13.2: new USB bus registered, assigned bus number 3 ehci_hcd 0000:00:13.2: irq 19, io mem 0xfe02b000 ehci_hcd 0000:00:13.2: USB 2.0 started, EHCI 1.00, driver 10 Dec 2004 usb usb3: configuration #1 chosen from 1 choice hub 3-0:1.0: USB hub found hub 3-0:1.0: 8 ports detected SCSI subsystem initialized libata version 2.00 loaded. sata_sil 0000:00:11.0: version 2.0 ACPI: PCI Interrupt 0000:00:11.0[A] -> GSI 23 (level, low) -> IRQ 23 ata1: SATA max UDMA/100 cmd 0xFFFFC2000001C080 ctl 0xFFFFC2000001C08A bmdma 0xFFFFC2000001C000 irq 23 ata2: SATA max UDMA/100 cmd 0xFFFFC2000001C0C0 ctl 0xFFFFC2000001C0CA bmdma 0xFFFFC2000001C008 irq 23 scsi0 : sata_sil input: ImPS/2 Generic Wheel Mouse as /class/input/input2 ata1: SATA link down (SStatus 0 SControl 310) scsi1 : sata_sil ata2: SATA link down (SStatus 0 SControl 310) ACPI: PCI Interrupt 0000:00:12.0[A] -> GSI 22 (level, low) -> IRQ 22 ata3: SATA max UDMA/100 cmd 0xFFFFC2000001E080 ctl 0xFFFFC2000001E08A bmdma 0xFFFFC2000001E000 irq 22 ata4: SATA max UDMA/100 cmd 0xFFFFC2000001E0C0 ctl 0xFFFFC2000001E0CA bmdma 0xFFFFC2000001E008 irq 22 scsi2 : sata_sil ata3: SATA link up 1.5 Gbps (SStatus 113 SControl 310) ata3.00: ATA-7, max UDMA/133, 312581808 sectors: LBA48 NCQ (depth 0/32) ata3.00: ata3: dev 0 multi count 16 ata3.00: configured for UDMA/100 scsi3 : sata_sil ata4: SATA link down (SStatus 0 SControl 310) scsi 2:0:0:0: Direct-Access ATA WDC WD1600JS-22N 10.0 PQ: 0 ANSI: 5 SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA SCSI device sda: 312581808 512-byte hdwr sectors (160042 MB) sda: Write Protect is off sda: Mode Sense: 00 3a 00 00 SCSI device sda: write cache: enabled, read cache: enabled, doesn't support DPO or FUA sda: sda1 sda2 sd 2:0:0:0: Attached scsi disk sda device-mapper: ioctl: 4.11.0-ioctl (2006-10-12) initialised: [email protected] kjournald starting. Commit interval 5 seconds EXT3-fs: mounted filesystem with ordered data mode. SELinux: Disabled at runtime.

SELinux: Unregistering netfilter hooks audit(1181402247.960:2): selinux=0 auid=4294967295 input: PC Speaker as /class/input/input3 EDAC MC: Ver: 2.0.1 May 16 2007 parport: PnPBIOS parport detected. parport0: PC-style at 0x378 (0x778), irq 7 [PCSPP,TRISTATE] Floppy drive(s): fd0 is 1.44M FDC 0 is a post-1991 82077 EDAC MC0: Giving out device to k8_edac Athlon64/Opteron: DEV 0000:00:18.2 8139cp: 10/100 PCI Ethernet driver v1.3 (Mar 22, 2004) 8139cp 0000:02:05.0: This (id 10ec:8139 rev 10) is not an 8139C+ compatible chip 8139cp 0000:02:05.0: Try the "8139too" driver instead. 8139too Fast Ethernet driver 0.9.28 ACPI: PCI Interrupt 0000:02:05.0[A] -> GSI 22 (level, low) -> IRQ 22 eth0: RealTek RTL8139 at 0xffffc20000020000, 00:16:ec:99:25:88, IRQ 22 eth0: Identified 8139 chip type 'RTL-8100B/8139D' hda: ATAPI 48X DVD-ROM DVD-R-RAM CD-R/RW drive, 2048kB Cache, UDMA(33) Uniform CD-ROM driver Revision: 3.20 shpchp: Standard Hot Plug PCI Controller Driver version: 0.4 sd 2:0:0:0: Attached scsi generic sg0 type 0 ACPI: PCI Interrupt 0000:00:14.5[B] -> GSI 17 (level, low) -> IRQ 17 lp0: using parport0 (interrupt-driven). lp0: console ready NET: Registered protocol family 10 lo: Disabled Privacy Extensions Mobile IPv6 input: Power Button (FF) as /class/input/input4 ACPI: Power Button (FF) [PWRF] input: Power Button (CM) as /class/input/input5 ACPI: Power Button (CM) [PWRB] No dock devices found. ibm_acpi: ec object not found md: Autodetecting RAID arrays. md: autorun ... md: ... autorun DONE. device-mapper: multipath: version 1.0.5 loaded EXT3 FS on dm-0, internal journal kjournald starting. Commit interval 5 seconds EXT3 FS on sda1, internal journal EXT3-fs: mounted filesystem with ordered data mode. Adding 1998840k swap on /dev/VolGroup00/LogVol01. Priority:-1 extents:1 across:1998840k ip6_tables: (C) 2000-2006 Netfilter Core Team ip_tables: (C) 2000-2006 Netfilter Core Team Netfilter messages via NETLINK v0.30. nf_conntrack version 0.5.0 (3963 buckets, 31704 max) eth0: link up, 100Mbps, full-duplex, lpa 0x41E1 Bluetooth: Core ver 2.11 NET: Registered protocol family 31 Bluetooth: HCI device and connection manager initialized Bluetooth: HCI socket layer initialized Bluetooth: L2CAP ver 2.8 Bluetooth: L2CAP socket layer initialized Bluetooth: RFCOMM socket layer initialized Bluetooth: RFCOMM TTY layer initialized Bluetooth: RFCOMM ver 1.8 Bluetooth: HIDP (Human Interface Emulation) ver 1.1 eth0: no IPv6 routers present ISO 9660 Extensions: Microsoft Joliet Level 3 ISOFS: changing to secondary root

Informe de Tesina Proyecto Switch Transaccional

Página 100 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Anexo D: Detalle Servidor de Base de Datos

Informe de Tesina Proyecto Switch Transaccional

Página 101 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Anexo E: Detalle del Servidor de Aplicaciones

Informe de Tesina Proyecto Switch Transaccional

Página 102 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 103 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Informe de Tesina Proyecto Switch Transaccional

Página 104 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

Anexo F: Detalle de las etapas de implementación DETALLE

DE ITERACIONES

FASE LANZAMIENTO - ITERACIÓN 1

Informe de Tesina Proyecto Switch Transaccional

Página 105 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE ELABORACIÓN - ITERACIÓN 2

Informe de Tesina Proyecto Switch Transaccional

Página 106 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE ELABORACIÓN - ITERACIÓN 3

Informe de Tesina Proyecto Switch Transaccional

Página 107 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 4

Informe de Tesina Proyecto Switch Transaccional

Página 108 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 5

Informe de Tesina Proyecto Switch Transaccional

Página 109 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 6

Informe de Tesina Proyecto Switch Transaccional

Página 110 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 7

Informe de Tesina Proyecto Switch Transaccional

Página 111 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 8

Informe de Tesina Proyecto Switch Transaccional

Página 112 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 9

Informe de Tesina Proyecto Switch Transaccional

Página 113 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 10

Informe de Tesina Proyecto Switch Transaccional

Página 114 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 11

Informe de Tesina Proyecto Switch Transaccional

Página 115 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 12

Informe de Tesina Proyecto Switch Transaccional

Página 116 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 13

Informe de Tesina Proyecto Switch Transaccional

Página 117 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 14

Informe de Tesina Proyecto Switch Transaccional

Página 118 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 15

Informe de Tesina Proyecto Switch Transaccional

Página 119 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 16

Informe de Tesina Proyecto Switch Transaccional

Página 120 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE REFINAMIENTO - ITERACIÓN 17

Informe de Tesina Proyecto Switch Transaccional

Página 121 de 122

Universidad Nacional de la Patagonia San Juan Bosco Facultad de Ingeniería – Sede Puerto Madryn

FASE CIERRE - ITERACIÓN 18

Informe de Tesina Proyecto Switch Transaccional

Página 122 de 122