Professional Documents
Culture Documents
SOCIEDAD DE LA INFORMACIN
SWITCH TRANSACCIONAL
INFORME DE TESIS
PUERTO MADRYN, DICIEMBRE 2007
Informe de Tesina
Agradecimientos
Necesariamente a la familia ya que sin Nora, Matas y Manuel seria impensable haber alcanzado este logro y el soporte
y apoyo necesario para que a los 40 aos haya toma la decisin de terminar esta carrera que tanto amo.
A mi viejo el Peke (deformacin ietesca de Jefe) por ser el visionario que ha impulsado, en gran medida, parte de
los conceptos aqu vertidos y por lo tanto haber sido el compaero que da el sustento filosfico y social a esta tesis.
Al Magster Gustavo Cajaraville porque como tutor de esta tesis me ha dado la libertad necesaria y el apoyo requerido
para encarar lucidamente los temas aqu tratados.
Al Licenciado Carlos Buckle, porque sin su desinteresado asesoramiento me hubiera sido imposible salir del
estancamiento tcnico en que se encontraba la tesis.
En toda formacin universitaria deben existir necesariamente esos impulsores que provocan que uno est seguro de la
carrera elegida, sin duda en ese aspecto debo mi formacin profesional y agradecimiento al Licenciado Ricardo Bustelo
y al Ingeniero Ernesto Mayorga (los duros) por haber compartido y transferido conocimientos y pasin por la profesin
y al Contador Ricardo Barrera por la formacin particularmente lcida en sistemas y en lo sistmico, generado
apertura a nuevas ideas.
Por ltimo a la Universidad Nacional de la Patagonia San Juan Bosco por ser el lugar en el que transcurre gran parte
de mi vida, generador de amistades y alegras en todos estos aos.
Informe de Tesina
Contenido
Agradecimientos...................................................................................................3
Captulo 1 Introduccin......................................................................................6
Encuadre del Proyecto.................................................................................................6
Resumen............................................................................................................................................................
6
Introduccin.........................................................................................................................
.............................6
Descripcin del Proyecto..............................................................................................7
Propsito, Alcances y Objetivos.......................................................................................................... ................7
Justificacin..................................................................................................................................
.....................8
Principales caractersticas........................................................................................................................ ...........9
Resumen de Actividades.................................................................................................................................... .9
Arquitectura............................................................................................................................................
...........9
Informe de Tesina
Ambientes de Testing................................................................................................................................
.......46
Ambiente de produccin..........................................................................................................................
.........46
Control de configuraciones...........................................................................................................
....................47
Plan de Contingencia...............................................................................................................................
.........48
Administracin del proyecto.......................................................................................49
Detalle de Horas por Historias del usuario (User Story) Ejecutadas en el Proyecto.............................................49
Resumen de iteraciones.........................................................................................................
..........................51
Solucin...................................................................................................................53
Principales Casos de Uso.................................................................................................................
.................53
Diseo del Switch Transaccional........................................................................................................ ...............56
Modelo de Datos...........................................................................................................................
...................59
Componentes........................................................................................................................................
...........62
Implementacin y Pruebas Formales....................................................................................... .........................68
Captulo 4 Conclusiones...................................................................................70
Bibliografa y referencias.....................................................................................71
Anexos..............................................................................................................72
Anexo A - XML Tags usados para definir un mensaje SOAP...........................................72
Anexo B Proceso General de Implementacin............................................................73
Introduccin..................................................................................................................................................
...73
Elementos del proceso iterativo......................................................................................................... ...............78
Proceso General de Implementacin - Generalidades............................................................................... .........81
Fases e iteraciones del PGI......................................................................................................................... ......84
Roles del PGI..........................................................................................................................
.........................85
Actividades, Responsables y Entregables del PGI................................................................................ ..............88
Anexo C: Detalle del Sistema Operativo.......................................................................94
Anexo D: Detalle Servidor de Base de Datos................................................................97
Anexo E: Detalle del Servidor de Aplicaciones..............................................................98
Anexo F: Detalle de las etapas de implementacin......................................................101
Detalle de iteraciones.....................................................................................................................
................101
Informe de Tesina
Captulo 1 Introduccin
Encuadre del Proyecto
Esta investigacin se realiza como tesina de finalizacin de la carrera de Licenciatura en Informtica dictada por la
Facultad de Ingeniera de la Universidad Nacional de la Patagonia San Juan Bosco Sede Puerto Madryn.
Integrantes: Damin Pablo Barry
Tutor propuesto: Magster Gustavo Cajaraville.
RESUMEN
El objeto del presente trabajo es analizar cmo la sociedad de la informacin tiene un rol primordial para resolver la
problemtica actual en la integracin de aplicaciones, que no es solo econmica sino conceptual y estructural, para ello
intentar por un lado una aproximacin sumaria a la teora del pensamiento complejo y por el otro las capacidades
actuales del estado de la tecnologa como una herramienta de integracin de aplicaciones, basndose para ello en los
distintos consorcios y comits encargados de la definicin de estndares de integracin y conectividad.
Acompaando a la base terica de integracin de aplicaciones se desarrolla un Software denominado Switch
Transaccional que permite gestionar la integracin de distintas aplicaciones agregando una capa de procesos y
validacin de circuitos entre partes, en definitiva el Switch transaccional deber actuar como regulador y controlador
del contrato de intercambio de informacin entre partes.
Palabras claves: Sociedad de la Informacin, Entropa, Neguentropa, Estndares, Comunicacin, Tecnologa, XML,
A2A, B2B, OASIS, W3 Consortium, SOA, Web Services, SOAP, BPM, BPEL, WS-Security.
INTRODUCCIN
A modo de introduccin utilizar algunos textos que ilustrarn la concepcin base que fundamenta este trabajo.
As, desorden y orden a la vez se confunden, se llaman, se necesitan, se combaten, se contradicen. Esta Dialgica se
pone en marcha en el gran juego fenomnico de las interacciones, transformaciones, organizaciones, donde trabajan
cada uno para si, cada uno para todos, todos contra uno y todos contra todos....
El orden viviente es tan refinado y delicado que sera de una fragilidad extrema, si precisamente su refinamiento no le
permitiera manipular el desorden en su provecho y sobre todo regenerarse y reorganizarse permanentemente.
En la ciencia y sobre todo en la poltica, las ideas, a menudo ms testarudas que los hechos, resisten el embate de los
datos y de las pruebas. Los hechos se estrellan efectivamente contra las ideas, mientras no exista nada que pueda
reorganizar de otra manera la experiencia.
En efecto la teora del sistema se anima all donde hay juego activo de interacciones, retroacciones, emergencias,
constreimientos, all donde los antagonismos entre partes, entre las partes y el todo, entre lo emergente y lo
sumergido, lo estructural y lo fenomnico se ponen en movimiento. La teora del sistema toma vida all donde hay vida
y su inters terico mas grande, se despliega a nivel de las sociedades humanas....
La idea de cibernticaarte-ciencia del gobierno puede integrarse y transformarse en co-ciberntica arte-ciencia de
Informe de Tesina
pilotear conjuntamente, donde la comunicacin ya no es til del mando, sino una forma simblica compleja de
organizacin.
La informacin generativa y la informacin circulante pueden transformarse la una en la otra, pero la transformacin
de una informacin circulante o de seales de informacin generativa no es posible ms que si se encuentra un
aparato capaz de registrarla y tratarla.
As la informacin solo puede nacer a partir de una interaccin entre una organizacin generativa y una perturbacin
aleatoria al ruido. Ergo la informacin no puede desarrollarse ms que a partir del ruido. Y desde luego, en el
nacimiento de una informacin, siempre se necesita una actitud organizacional de carcter negentrpico que se supere
a si misma transformando el evento en novedad, el error en verdad
La informacin es inseparable de la actividad de la totalidad en tanto que totalidad, no obstante, no se diluye en una
confusin holstica. Por el contrario, se convierte en uno de los conceptos cuajados en la idea de organizacin
negentrpica geno - fenomnica de naturaleza informacional / comunicacional.
Edgar Morin, Ctedra Itinerante UNESCO para el Pensamiento Complejo.
As como es indebido anteponer los problemas a las necesidades, la explicacin a la comprensin y la accin al
pensamiento, se torna indispensable aplicar el concepto de interdependencia. Por lo tanto, debemos respetar la
secuencia en la que no hay:
Deseos sin Estructura
Estructura sin Sistema
Sistema sin Funcin
Funcin sin rgano
rgano sin Finalidad
Esta cascada conceptual posee un valor nuclear, pues corrige las representaciones polticas preestablecidas por el
deseo, que indican cmo deben ser o dejar de ser las respectivas construcciones, pero no cmo son y cmo funcionan
en realidad.
Esta Funcin coordina procesos integrados que cruzan y resignifican las funciones tradicionales. De la correcta
aplicacin de esta ecuacin, depende la eficiencia y la equidad del sistema.
La crisis desdibuja su perfil cuando se la generaliza, pues se la vaca de contenido y se diluye la responsabilidad de sus
componentes. Se impone por lo tanto centrarnos en los objetivos y en los aspectos tcnicos y as contener el
desaliento que enturbia la visin del escenario y deforma a los protagonistas.
O revisamos las modalidades polticas que nos condujeron al fracaso, profundizaremos la crisis, que a su vez acenta
la incapacidad de resolverla.
Ignacio Katz, Doctor en Medicina (UBA).
A partir de las experiencias en sistemas de informacin para la administracin y control de gestin y ante el creciente
uso de tecnologa para la interconexin de aplicaciones y dentro de la problemtica poltico-social planteada en la
introduccin, intentar expresar cmo interactan todos los factores de la sociedad y cmo la Sociedad de la
Informacin contribuye al cambio del paradigma social.
Para ello ser clave el desarrollo de un Switch Transaccional que mediante la aplicacin de arquitectura SOA (Service
Oriented Architecture) garantice un medio flexible para la aplicacin de estndares y procesos de negocio.
Informe de Tesina
mtodos y mecanismos seguros para el transporte de dicha informacin. Este integrador tendr la finalidad de
garantizar las reglas de juego establecidas entre las partes, la seguridad y disponibilidad de los servicios ofrecidos y
solicitados. A dicho integrador lo llamaremos Switch Transaccional.
El Switch Transaccional es un conjunto de aplicativos e infraestructura que permiten soportar toda la exigencia y
eficiencia en la integracin de las distintas aplicaciones entre clientes de un servicio y los oferentes del mismo,
soportando mecanismos de seguridad de informacin transportada, flujo de procesos, aplicacin de reglas de negocio
y la recuperacin, seguimiento y continuidad de los servicios de transacciones ofrecidos.
EL Switch Transaccional debe ser considerado ms que un servicio de conectividad un Portal transaccional donde se
obtendrn los siguientes beneficios:
Publicacin de contenidos mediante Web Services a travs del portal del switch, permitiendo la personalizacin
de los mismos a cada usuario.
Tecnologa.
Web Enable.
Administracin y distribucin de mensajes y componentes.
Metamodelos para la definicin dinmica de servicios y procesos transaccionales.
Estndares del mercado: SOA, XML, BPEL, OASIS y W3C.
Posibilidad de conectar mltiples dispositivos de conexin front-end: IVR, POS, Aplicacin cliente PC, Internet.
Conectividad con todos los actores de los distintos sistemas a integrar. Permite mediante protocolos de
comunicacin estndar, conectar las distintas organizaciones y actores, facilitando la interoperabilidad entre
los mismos.
Integra informacin entre las distintas aplicaciones back office del sistema: Construye informacin, permite
publicar mediante servicios informacin de inters de los distintos actores.
Provee independencia entre las aplicaciones back office y las aplicaciones transaccionales. Back office y el
dispositivo front-end
Reglas para el comportamiento de la red. Descomposicin de servicios en sub-servicios dependiendo de pasos
y reglas configurables para cada servicio.
JUSTIFICACIN.
Cada da es mayor la incidencia de las tecnologas de informacin dentro de la sociedad, generando nuevos
paradigmas y enfrentando distintos intereses de la sociedad. Por ello es necesario generar mecanismos que permitan
democratizar la informacin y servicios de las distintas organizaciones que intervienen en la sociedad.
Desde la perspectiva del estado como regulador y controlador de las distintas actividades de los actores de una
sociedad y desde la perspectiva de los ciudadanos como usuario e interesados en la imposicin de mecanismos
garanticen mayor justicia, ecuanimidad y que permitan el acceso a informacin de inters de los particulares y de las
distinats organizaciones.
Por lo tanto es necesaria la construccin de herramientas de infraestructura tecnolgica que faciliten la integracin de
las partes.
Por ello el presente proyecto adems de basarse en estndares de integracin de aplicaciones y servicios promover el
uso de los mismo y la promocin de software Open Source, generando con el presente trabajo un base para futuros
proyectos Open Source enmarcados dentro del mbito universitario. Para alcanzar este objetivo adems de usar
exclusivamente herramientas Open Source el producto resultante queda registrado dentro del esquema de Copy Left,
pasando a formar parte del dominio pblico, para ello se ha registrado dentro del portal de Google para registracin de
Software Open Source utilizando una licencia GLP v2. (http://switchtransaccional.googlecode.com)
Informe de Tesina
PRINCIPALES CARACTERSTICAS.
RESUMEN DE ACTIVIDADES
Investigacin sobre los estndares a utilizar: SOA, XML, BPEL, OASIS y W3C.
Investigacin de casos de xito de implementaciones concretas en la integracin de aplicaciones y servicios a
nivel e-Gobierno y comunidad.
Elaboracin de un Paper resumiendo las investigaciones realizadas.
Relevamiento de requerimientos necesarios para el diseo del Switch Transaccional. Escritura de StoryBoard
que representen la funcionalidad operativa requerida por el Switch Transaccional.
Definicin y administracin de la Arquitectura tecnolgica en la cual se soportar el Switch transaccional.
Arquitectura y Diseo del Switch Transaccional, utilizando UML.
Casos de Uso.
Diagrama de Actividades.
Diagrama de Datos y Clases.
Diagrama de Secuencia.
Diagrama de estados.
Construccin
Construccin de los parsers dinmicos mediante el uso de metamodelos para la validacin de los mensajes
y servicios.
Construccin del flujo de procesos dinmico mediante el uso de metamodelos para la composicin y
construccin de superservicios. Administracin de respuestas a los clientes.
Construccin del router de mensajes y servicios hacia los back-office.
Construccin del modulo de administracin del portal. Usuarios, Servicios, Back-office, Front-End.
Construccin del mdulo de logging.
Pruebas Formales.
Puesta en marcha.
ARQUITECTURA.
La Arquitectura del Switch Transaccional prev como primer medida el ruteo y sincronizacin de servicios entre
Informe de Tesina
organizaciones y entidades, de esta forma el intercambio de servicios y mensajes queda concentrado y estandarizado
en el Switch Transaccional.
Informe de Tesina
Resumen
El objeto del presente trabajo es analizar cmo la sociedad de la informacin tiene un rol primordial para resolver la
problemtica actual en la integracin de aplicaciones, que no es solo econmica sino conceptual y estructural, para
ello intentar por un lado una aproximacin sumaria a la teora del pensamiento complejo en relacin al concepto de
organizacin sistemas y sub-sistemas interdependientes y la comunicacin transformada en informacin como
elemento complejo, que acelera los procesos de negentropa de los sistemas-organizaciones evitando de esta manera
la entropa de los mismos y por el otro las capacidades actuales del estado de la tecnologa como elemento clave en
la sociedad de la informacin y en particular asociado a los estndares de integracin de aplicaciones promovidos por
OASIS.
Informe de Tesina
conforman distintas organizaciones que interactan e interaccionan entre si y con la Organizacin Global. As en el
sistema, cada interaccin, cada contrato, cada accin impacta en el todo y cada una de las partes como un todo.
La unidad menor de este sistema y objeto mayor es el hombre, organizacin a su vez biolgica-cultural que integra los
sistemas y sub-sistemas sociales, econmicos, polticos, culturales etc. y que es tambin permanentemente,
interactuado por fenmenos directos, indirectos y emergentes o sumergentes de los mismos. Por ejemplo su salud
como su calidad de vida, estarn ntimamente ligados a su sistema biolgico, cultural, social, poltico, econmico,
ecolgico, medio ambiente etc. y las interacciones de cada uno de estos, ms sus propios comportamientos como
interactuante, receptor, generador y modificador de los mismos.
Por otra parte algunos de estos individuos son integrantes de sub-sistemas de las distintas organizaciones. Su visin
del problema y su resolucin ser diferente porque de acuerdo a su ubicacin y su situacin sus determinaciones sern
distintas.
Conectividad (Internet), intercambio de informacin, interaccin de las partes e interoperabilidad, tableros de
comando, monitoreo y seguimiento de polticas, sern el desafo tecnolgico del futuro que garantizar una mejor
calidad de vida al hombre asegurando una mejor utilizacin de los recursos econmicos, profesionales, logsticos,
culturales y sociales disponibles dentro de cualquier tipo de organizacin poltica y garantizando el equilibrio entre
todas las partes tanto pblicas como privadas, equilibrando sus contradicciones y potenciando sus cualidades.
Obligando al uso racional de la informacin y a reducir la brecha sobre el conocimiento que existe actualmente.
La informacin que intercambien las partes ser en algunos casos determinante de acciones de distinto tipo por cada
uno de los actores y los sistemas que integran. Pero en la medida que esta informacin circule como una unidad entre
las partes y las acciones que determinen puedan ser monitoreadas y cuantificadas y su resultado dimensionable en
calidad de vida, garantas jurdicas y viabilidad de aplicacin, econmica, cultural, social etc. el sistema tender a la
fortificacin y cada una de las partes se beneficiar, pero de continuar por el camino en que estn hoy los sistemas de
informacin, la entropa es inevitable y la consecuente disolucin o dispersin de cada uno de los sub-sistemas
tambin.
Este es el gran desafo de la tecnologa y el nico camino que tienen por seguir aquellos que estn solo interesados en
mejorar la calidad de vida del hombre y sus organizaciones y sistemas.
Informe de Tesina
Democratizar la Informacin.
Las comunicaciones favorecen el intercambio y la interaccin democrtica de la informacin, permitiendo si se utiliza
correctamente, sinergia y crecimiento entre las distintas partes y actores que acceden a ella, eliminado,
probablemente, intereses particulares de las partes. Compartir y regular la informacin permite auditar y controlar las
actividades de los distintos actores de los sistemas y organizaciones.
La tecnologa y las comunicaciones son el factor impulsor de este intercambio. La capacidad de los distintos sistemas
que procesen dicha informacin, permitir implementar procedimientos cualitativamente superiores, debido al acceso a
dicha informacin y a la posibilidad de interactuar en lnea sobre los diversos sucesos de los sistemas interactuantes.
Los sistemas y los actores deben alimentarse del flujo de informacin para trabajar con ella en todos los niveles. Cada
parte tomar de la informacin circulante lo que necesita para aprender y crecer. Este crecimiento y la interaccin de
los actores mantendrn en equilibrio el sistema de informacin y permitir mejorarlo.
En este sentido el trabajo interdisciplinario y multidisciplinario es clave para enriquecer los servicios que prestan las
organizaciones brindados en todos los niveles.
Actualmente el crecimiento exponencial en el uso de Internet y el acceso a herramientas y comunicaciones cada vez
ms econmicas y accesibles, permiten suponer que lograr sinergia de informacin entre los sistemas y sus sub-
sistemas posibilitando la neguentropa ser una realidad posible.
En este sentido, es clave, la integracin geogrfica de todos los actores y sus sistemas de informacin, logrando
transformar un modelo fsico de lejana geogrfica, en un modelo de informacin virtualmente sin distancias ni brechas
temporales.
De todas formas no se debe descuidar la gran debilidad que puede significar la utilizacin de tecnologa en pases en
vas de desarrollo como lo son los pases que integramos Latinoamrica. Ya que si hablamos de democratizar la
informacin, bajo ningn concepto debemos ni podemos hacer que la utilizacin de tecnologa no sea un recurso
sustentable.
Para ello es importante la participacin del estado en la regulacin y en la administracin de un crecimiento
homogneo y democrtico en la utilizacin de tecnologa y ms an en las polticas de acceso y distribucin de
informacin.
Informe de Tesina
Dentro de los distintos sistemas organizacionales, ya sean privados, pblicos o de gobierno, nos encontramos con una
gran cantidad de actores que necesitan intercambiar servicios e informacin. Estas operaciones estn sumamente
atomizadas, requiriendo la intervencin simultanea de los actores mencionados.
A dichas operaciones se agregan adems intereses contrapuestos y necesidades de control y contralor que lo hacen
mas complejo an.
Esta complejidad genera una gran cantidad de dialectos de comunicacin entre las partes, provocando el clsico
telfono descompuesto. Debido esto, normalmente, a reglas de interpretacin poco claras. Donde el principal
damnificado es el hombre, donde normalmente es sometido a largas esperas y en algunos casos re-hacer los trmites
y operaciones por dicha falta de interpretacin.
Es por ello que la alta interoperabilidad de dichos servicios e informacin requiere de una interpretacin precisa de lo
que se solicita como servicio y de lo que se pretende informar o recibir como informacin.
De aqu que la mayor necesidad de las organizaciones y actores intervinientes sea la definicin de estndares de
servicios y comunicaciones que garanticen o por lo menos minimicen la posibilidad de confusiones y malas
interpretaciones en el intercambio de informacin.
Esta situacin no es menor si tenemos en cuenta que muchos de los servicios propuestos tienen una criticidad muy
alta, como puede ser por ejemplo la correcta identificacin de una persona como paciente en un hospital y el acceso a
su historia clnica centralizada. Fallar en esta situacin podra en algunos casos provocar la muerte del paciente por
falta o mala interpretacin de la informacin requerida.
SISTEMAS E INTEROPERABILIDAD
La sociedad y su sistema de organizacin social, requiere que sus organizaciones, ya sean privadas, semi pblicas o
pblicas interaccionen tanto con los ciudadanos (en cualquiera de sus roles) como con otras organizaciones.
Informe de Tesina
Los ciudadanos estn ligados a distintos organismos y organizaciones por diversos motivos dentro de sus
obligaciones y derechos. Tambin estn vinculados a organizaciones privadas o semi-publicas por motivos de
distinto grado de pertenencia de acuerdo a sus inclinaciones, actividades sociales y profesionales.
As un maestro est ligado a la escuela e indirectamente al ministerio de educacin.
Un paciente, est ligado al sistema de salud: hospitales, centros de atencin Obra social o pre-paga.
Un ciudadano est vinculado a los gobiernos municipales, provinciales y nacionales debido a sus obligaciones.
El nexo comn es la sociedad en si misma.
El factor impulsor es la organizacin de dicha sociedad con sus actividades, sociales, econmicas y las
obligaciones y derechos de los ciudadanos y actividad privada (empresas y organizaciones).
El estado est obligado a supervisar y ordenar todas las actividades ejecutadas dentro de una sociedad.
Todos los integrantes de dicha sociedad tienen un alto nivel de interdependencia.
En la figura presentada a continuacin se puede apreciar un ejemplo solamente para el rea de salud
Claramente se puede observar el nivel de interoperabilidad, dependencia y atomizacin que nos llevan a concluir el
siguiente diagnstico:
Sistema atomizado con muchos intermediarios.
Industria de informacin intensiva.
Gastos transaccionales y operacionales elevados con tendencia a la ineficiencia.
Situacin econmico / financiera comprometida.
Falta de polticas integrales y estndares.
Escasa inversin en tecnologa.
Es importante destacar el rol central que tienen los factores econmicos dentro de esta interoperabilidad y el papel
preponderante que juegan las organizaciones financiadoras y el gobierno como factores de equilibrio entre calidad y
distribucin de las prestaciones.
Informe de Tesina
La evolucin de los sistemas sociales hace pensar que estamos frente a una problemtica de demanda infinita y
recursos limitados y es aqu donde estas organizaciones tienen la responsabilidad de administrar y distribuir en toda la
poblacin el derecho y acceso a la informacin y un equilibrio entre las actividades desarrolladas en una sociedad.
OASIS
OASIS, acrnimo de (Organization for the Advancement of Structured Information Standards) es un consorcio
internacional sin fines de lucro que se orienta al desarrollo, consenso y adopcin de estndares para el intercambio
de informacin entre aplicaciones (e-Business, e-Government).
Los miembros del consorcio deciden cmo y qu trabajos se deben emprender a travs de un proceso abierto y
democrtico.
Los trabajos tcnicos abarcan las siguientes categoras: Adoption Services, Computing Management, Document-Centric
Applications, e-Commerce, Law & Government, SOA, Standards Adoption, Web Services, XML Processing.
HISTORIA:
OASIS fue fundada inicialmente en 1993 como una asociacin comercial, denominada SGML Open, para promover la
adopcin del estndar SGML. Principalmente mediante el desarrollo de actividades educativas, incluyendo tambin
actividades tcnicas como el intercambio de especificaciones en organizaciones administrativas.
En 1998, con el apogeo de XML en TI, SGML cambio su enfoque de SGML a XML, y cambio su nombre a OASIS. El
rea de inters del consorcio abarca desde promociones de adopcin de estndares hasta el desarrollo de
especificaciones tcnicas de los mismos. En julio del 2000 se creo un nuevo comit tcnico. En la actualidad hay cerca
de 70 comits.
Durante 1999 OASIS se reuni con la UN/CEFACT, el comit de las Naciones Unidas para negociar los estndares de
negocios, para que conjuntamente se desarrollen nuevas normas y estndares para el intercambio de informacin
electrnica. La junta inicial se la llamo ebXML y se reunieron por primera vez en Noviembre de 1999, fue establecida
por un periodo de 3 aos. En la reunin final bajo los primeros estatutos, en Viena, UN/CEFACT y OASIS coincidieron
en dividir el trabajo en las dos organizaciones y coordinar la finalizacin de los trabajos en comits especficos. En
2004 OASIS propuso la especificacin de ebXML a la ISO TC154 donde fue aprobada como la ISO 15000.
Algunos de los estndares desarrollados por OASIS:
DITA (OASIS Darwin Information Typing Architecture) es un modulo portable y extensible basado en el lenguaje
XML para temas bsicos como ayuda on-line, documentacin de proyectos, asesoramientos y capacitacin.
OpenDocument (OASIS Open Document Format for Office Applications) es un formato de documento abierto
para el respaldo de documentos de oficina tales como documentos de texto, planillas de clculo, presentaciones,
memos, y grficos.
SAML (Security Assertion Markup Language) es un estndar basado en XML para la seguridad en el intercambio,
autenticacin y autorizacin de informacin.
XRI (eXtensible Resource Identifier) es un esquema compatible con URI y un protocolo de resoluciones usado
por identificadores abstractos para la identificacin y intercambio de recursos a travs de dominios y
aplicaciones.
XDI (XRI Data Interchange) es un estndar para el intercambio, interconexin y sincronizacin de datos
(dataweb) mediante el uso de mltiples dominios y aplicaciones usando documentos XML (XRIs, eXtensible
Resource Identifiers) y nuevos mtodos distribuidos de control de datos llamados linkContract.
Informe de Tesina
LegalXML es un estndar para el intercambio de informacin legal y jurdica entre todas las partes del sistema
judicial.
EL consorcio es de carcter internacional y por lo tanto crea las normas para un mercado internacional. Con la oficina
principal en Estado Unidos de Amrica, el consorcio tiene la representacin corporativa en Europa y Asia, y
participacin activa de miembros en los cinco continentes.
Los miembros incluyen:
1. Usuarios que buscan asegurar sus requisitos comerciales.
2. Agencias gubernamentales que quieren minimizar la superposicin de normas y reducir el riesgo de la
nueva tecnologa.
3. Los proveedores de software impulsando la cooperacin de la industria a travs de normas y estndares.
Adems ofrece un rango de niveles de miembros para los usuarios y vendedores, gobiernos y universidades, grupos de
comercio y proveedores de servicios.
Los archivos de los Comits Tcnicos de OASIS, documentos y los correos electrnicos son pblicamente accesibles
incluso para los no-miembros y pueden ser supervisados y mejorados abiertamente.
OASIS se caracteriza por su gobierno y su forma de operacin. Los mismos miembros fijan la agenda tcnica, usando
un proceso sencillo diseado para promover el consenso en la industria y para unir esfuerzos dispares. Los trabajos
completados son debatidos mediante el voto abierto (Ballot). Los funcionarios de la Junta Directiva de OASIS y la
Junta Asesora Tcnica son escogidos por eleccin democrtica para servir por el trmino de dos aos. La Direccin del
consorcio esta basada en el mrito individual y no en su contribucin financiera, situacin corporativa o cita especial.
OASIS mantiene participacin y relaciones con algunas de siguientes organizaciones:
W3C
ISO
ISO/IEC JTC1
ITU
UNECE
RosettaNet
Y muchas otras...
HL7
HL7 (Health Level Seven) es una organizacin sin fines de lucro que desarrolla estndares para minimizar las
incompatibilidades entre sistemas de informacin en salud, permitiendo la interaccin y el intercambio productivo de
datos entre aplicaciones heterogneas, independientemente de su plataforma tecnolgica o de su lenguaje de
desarrollo.
Diferentes sectores: prestadores de servicios de salud, desarrolladores de software, consultores, usuarios finales,
organizaciones gubernamentales y no gubernamentales; participan en forma colaborativa en la discusin y en el
desarrollo de estndares por consenso, en un entorno abierto. Estos estndares ofrecen un marco que permite a los
diferentes sistemas de informacin, comunicarse a travs de mensajes estandarizados que viajan por una nica
interfaz.
Se trata de una iniciativa que comenz en 1987, en base a la necesidad de normalizar las interfaces entre los mltiples
sistemas heterogneos de informacin, y rpidamente se convirti en el estndar de facto para el intercambio
electrnico de datos clnicos y administrativos en los servicios de salud de los Estados Unidos.
La amplia difusin de los estndares desarrollados, dio origen en los ltimos aos a filiales internacionales (Canad,
Informe de Tesina
Australia, China, Finlandia, Alemania, India, Japn, Corea, Holanda, Nueva Zelanda, Sudfrica, Reino Unido, Argentina,
Brasil, para mencionar solo algunos), y a un comit internacional, que permite armonizar y discutir las necesidades
locales de adaptar los estndares en distintas partes del mundo.
La estructura internacional de la organizacin, el procedimiento de votacin balanceado, y las polticas abiertas de
asociacin, aseguran que todos los requerimientos sean tenidos en cuenta uniformemente y equitativamente con
calidad y consistencia. Adems todas las organizaciones HL7 y sus desarrollos, estn reconocidas en Estados Unidos
por el instituto ANSI (American National Standards Institute) y por la SDO (Standards Developing Organization).
Tecnologas necesarias.
La tecnologa por si misma no podra modificar absolutamente nada dentro de la sociedad de la informacin. Esta es
solamente el soporte, la infraestructura necesaria para que las comunidades que la utilizan construyan a partir de ella.
En este sentido las comunidades internacionales estn dando ejemplo que la construccin cooperativa de sistemas es
posible.
Claramente el ejemplo ms contundente lo ha dado la misma comunidad que desarrolla y promueve los estndares
mencionados anteriormente.
Otro ejemplo contundente y adems basado en el concepto de componentes distribuidos lo ha dado la comunidad
Java a travs de la especificacin JEE (Java Enterprise Edition) y sin duda el esfuerzo mayor lo han dado las mismas
empresas de tecnologa mediante la voluntad de crear en Internet estndares que permitan la integracin de cualquier
sistema independientemente de su plataforma mediante la utilizacin de XML y Web Services.
SOA
DEFINICIN.
SOA es la sigla que en ingles representa a Service Oriented Arquitectura (Arquitectura Orientada a los servicios).
Bsicamente la arquitectura propuesta es un nuevo paradigma dentro de las ciencias informticas que permite
organizar y utilizar distintas capacidades distribuidas (servicios) ofrecidos por distintos actores (personas y/u
organizaciones) a lo largo de Internet.
Esta arquitectura toma mas fuerza gracias al surgimiento del concepto de Web Services (servicio Web) que se
explicar ms adelante.
Hasta ahora, la mayora de las discusiones sobre SOA, giraban en torno a temas sobre la integracin de sistemas
dispares, el aprovechamiento de las Bases de Datos existentes en una organizacin o la creacin de una arquitectura
robusta. Si bien todos estos temas son relevantes para SOA, existen otros temas significativos e interesantes
relacionados con SOA que merecen atencin. Para lograr su objetivo de conectar sistemas heterogneos y autnomos,
SOA se adhiere a varios principios de diseo esenciales. Uno de los principios mantiene que la existencia de servicios
independientes implica la presencia de partes de cdigo y datos interconectados mediante mensajera.
Es ms, los servicios estn ntimamente vinculados a la mensajera ya que el nico camino de entrada y salida de un
servicio es a travs de mensajes. No obstante, los servicios seguirn funcionando de forma independiente de los
dems.
Por lo tanto SOA proporciona una metodologa y un entorno de trabajo para documentar capacidades de negocio y
puede dar soporte a las actividades de integracin y consolidacin entre organizaciones.
En un ambiente SOA, los nodos de la red hacen disponibles sus recursos a otros participantes en la red como servicios
independientes a los que tienen acceso de un modo estandarizado. La mayora de las definiciones SOA identifican la
utilizacin de Servicios Web (empleando SOAP y WSDL) en su implementacin, no obstante se puede implementar
SOA utilizando cualquier tecnologa basada en servicios.
Informe de Tesina
Nube se Servicios
Al contrario de las arquitecturas orientadas a objetos, SOAs est formada por servicios de aplicacin dbilmente
acoplados y altamente interoperables. Para comunicarse entre s, estos servicios se basan en una definicin formal
independiente de la plataforma subyacente y del lenguaje de programacin (por ejemplo WSDL. Ver Web Services ms
adelante). La definicin de la interfaz encapsula (oculta) las particularidades de una implementacin, lo que la hace
independiente del fabricante, del lenguaje de programacin o de la tecnologa de desarrollo (como Java o .NET). Con
esta arquitectura, se pretende que los componentes de software desarrollados sean muy reusables, ya que la interfaz
se define siguiendo un estndar; as, un servicio C Sharp podra ser usado por una aplicacin Java.
Dos ejemplos de soluciones comerciales SOA seran "Java Enterprise System" de Sun Microsystems y "Connected
Services Framework" (BizTalk Server + SQL Server + Windows Server + .NET Framework) de Microsoft.
Los lenguajes de alto nivel como BPEL (ver mas adelante) llevan el concepto de servicio un paso adelante al
proporcionar mtodos de definicin y soporte para flujos de trabajo y procesos de negocio.
Uno de los problemas de SOA se encuentra en los servicios independientes que requieren la presencia de partes de
cdigo y datos, y en los servicios de interconexin de mensajes. Cada servicio es una coleccin nica de cdigo y
datos que es autnoma e independiente de los dems servicios. No obstante, cada servicio est interconectado con
otros servicios a travs de la mensajera.
La mensajera tiene una importancia enorme en SOA. Los mensajes se envan entre servicios y flotan entre ellos. La
definicin de esquema para cada mensaje y el contrato que define el flujo de los mensajes especifican el
comportamiento de "caja negra" del servicio. Los servicios estn vinculados a la mensajera ya que el nico camino de
entrada y salida de un servicio es a travs de mensajes. Un servicio asociado slo est pendiente de la secuencia de
los mensajes que fluyen de un lado a otro.
A veces, se envan muchos mensajes relacionados entre dos servicios distintos. Estos dos servicios pueden
intercambiar mensajes durante un perodo de semanas o meses.
Informe de Tesina
Los servicios son el centro de atencin del proceso evolutivo. Los servicios proporcionan una manera de establecer una
divisin granular de mayor tamao y con ms independencia entre los fragmentos de cdigo que las funciones y los
componentes. En primer lugar, los servicios siempre interactan entre s mediante mensajes. En segundo lugar,
normalmente son duraderos, lo que les permite sobrevivir cuando el sistema presenta un error o se reinicia. Por
ltimo, los servicios tienen entornos de implementacin opacos en los que desde el exterior slo es posible ver las
interacciones de los mensajes.
DEFINICIONES SOA
W3C (World Wide Web Consortium): Conjunto de componentes que pueden ser invocados, cuyas descripciones
de interfaces se pueden publicar y descubrir
CBDI (Service Oriented Architecture Practice Portal) rechaza esa definicin:
Los componentes pueden no ser conjuntos. La definicin slo considera los componentes y no la prctica o el
arte de construir la arquitectura. Por lo tanto presenta la siguiente definicin:
Estilo resultante de polticas, prcticas y frameworks que permiten que la funcionalidad de una aplicacin se
pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor.
Los servicios pueden invocarse, publicarse y descubrirse y estn abstrados de su implementacin utilizando
una sola forma estndar de interfaz.
Informe de Tesina
Infraestructura de alto nivel basada en best practices y patrones para crear soluciones basadas en servicios, de
alta cohesin y bajo acoplamiento (Geniant).
Estilo arquitectnico apto para implementar bajo acoplamiento entre agentes. Los agentes son proveedores y
consumidores de servicios, que son la unidad de trabajo. (Hao He).
Una arquitectura de aplicacin en la cual todas las funciones se definen como servicios independientes con
interfaces invocables bien definidas, que pueden ser llamadas en secuencias definidas para formar procesos de
negocios (IBM).
MITRE (System Engineering and Advanced Technology to Critical National Problems):
Una aplicacin SOA es una coleccin de servicios
Gartner:
SOA es una arquitectura de software que comienza con una definicin de interfaz y construye toda la topologa
de la aplicacin como una topologa de interfaces, implementaciones y llamados a interfaces. Sera mejor
llamada arquitectura orientada a interfaces. SOA es una relacin de servicios y consumidores de servicios,
ambos suficientemente amplios para representar una funcin de negocios completa.
Comportamiento SOA
WEB SERVICES
Un servicio Web es una coleccin de protocolos y estndares que sirve para intercambiar datos entre aplicaciones.
Distintas aplicaciones de software desarrolladas en lenguajes de programacin diferente y ejecutada sobre cualquier
Informe de Tesina
plataforma pueden utilizar Web Services para intercambiar mensajes (servicios) en redes como Internet. La
interoperabilidad se consigue mediante la adopcin de estndares abiertos. OASIS y W3C son los comits responsables
de la arquitectura y reglamentacin de los Web Services.
Los Web Services, garantizando el uso de estndares en la tecnologa subyacente utilizada, permiten el gran
crecimiento del concepto SOA en la actualidad. Ya que los Web Services permiten independizarse de la plataforma y
de los lenguajes de programacin a ser utilizados.
Los Web Services, no son por lo tanto aplicaciones con una interfaz grfica con la que las personas puedan
interactuar, sino que son un conjunto de especificaciones de software accesible en Internet (o en redes privadas que
usen tecnologas Internet) por otras aplicaciones. De esta forma podemos desarrollar aplicaciones que hagan uso de
otras aplicaciones que estn disponibles en Internet.
Un tpico ejemplo podra ser un Web Service al que se le pudiese preguntar por una empresa y que nos retornase en
tiempo real el valor al que estn cotizando las acciones de dicha compaa.
De esta forma cualquier aplicacin (ya sea Web o de escritorio) que quiera mostrar esta informacin slo tendra que
solicitarla a travs de Internet al Web Service cuando la necesitase.
Otro ejemplo podra ser uno que al pasarle el nombre de una ciudad, nos devolviese la temperatura, humedad, y otras
condiciones de clima.
ESTNDARES EMPLEADOS
1. Web Services Protocol Stack: As se denomina al conjunto de servicios y protocolos de los servicios Web.
2. XML (eXtensible Markup Language): Es el formato estndar para los datos que se vayan a intercambiar.
3. SOAP (Simple Object Access Protocol) o XML-RPC: Protocolos sobre los que se establece el intercambio.
4. Otros protocolos: los datos en XML tambin pueden enviarse de una aplicacin a otra mediante protocolos
normales como HTTP, FTP, o SMTP.
5. WSDL (Web Service Definition Language ): Es el lenguaje de la interfaz pblica para los servicios Web. Es
una descripcin basada en XML de los requisitos funcionales necesarios para establecer una comunicacin
con los servicios Web.
6. UDDI (Universal Description, Discovery, and Integration): Protocolo para publicar la informacin de los
servicios Web. Permite a las aplicaciones comprobar qu servicios web estn disponibles.
7. WS-Security: Protocolo de seguridad aceptado como estndar por OASIS. Garantiza la autenticacin de los
actores y la confidencialidad de los mensajes enviados.
Informe de Tesina
Informe de Tesina
Para tener una mayor comprensin del significado de la mencionada coordinacin, veremos distintas topologas de
coordinacin (orquestacin) para transacciones y mensajes entre servicios:
1. Relacin Binaria: El contexto y la actividad estn implcitas en cada servicio, logrando de esta forma un criterio
de auto-coordinacin.
Coordinacin Binaria
Informe de Tesina
2. Hub o Spoke: Relacin entre servicios coordinados por un concentrador de transacciones que tiene la
responsabilidad del intercambio como as las actividades de control, validacin, flujo de proceso y seguridad.
3. Punto a punto en Multigrupo: Existe un coordinador que auspicia de rbitro entre las partes, pero tanto el
contexto como las actividades son explcitas pero dependientes de cada servicio. Este esquema es una
solucin mixta entre el esquema concentrador y el distribuido punto a punto.
Coordinacin Multigrupo
Informe de Tesina
Arquitectura de un Coordinador
Actualmente se encuentran disponibles varios lenguajes estndar de orquestacin y especificacin de procesos entre
los que podemos encontrar:
1. XLANG - XML Business Process Language.
2. BPML - Business Process Modeling Language.
3. BPSS Business Process Specification Schema.
4. WSFL - Web Services Flow Language.
5. WSCL Web Services Conversation Language.
6. WSCI - Web Service Choreography Interface.
7. BTP - Business Transaction Protocol.
8. WS-BPEL Web Services Business Process Execution Language.
9. WS-C, WS-T, WS-AT, WS-BA (Coordination, Transaction).
10. BPMN - Business Process Modeling Notation.
De los lenguajes mencionados anteriormente el que se est imponiendo es WSBPEL, ya que siendo originalmente
desarrollado e impulsado por BizTalk e IBM ha sido cedido a OASIS para que forme parte de los estndares que esta
organizacin administra. Este impulso inicial adems ha sido reforzado fuertemente por compaas como Oracle, BEA,
OpenStorm y Microsoft.
Informe de Tesina
BPEL adems de ser compatible SOA y Web Services, soporta otros tipos de procesos como Java y JCA e incorpora las
especificaciones de WS-Security, lo que lo convierte en un lenguaje de procesos robusto.
En resumen en el siguiente grfico podemos ver la arquitectura completa para realizar una correcta integracin de
aplicaciones y procesos distribuidos.
Informe de Tesina
ESTNDARES SOA
XML
XML (Extensible Markup Language) es un lenguaje extensible de etiquetas, desarrollado por el World Wide Web
Consortium (W3C).
Se propone como un estndar para el intercambio de informacin estructurada entre diferentes plataformas. Permite
compartir la informacin de una manera segura, fiable y sencilla.
Es un subconjunto de SGML (Standard Generalized Markup Language, lenguaje de marcado generalizado estndar), y
su objetivo es permitir el uso de SGML en Internet, de modo que un documento escrito en XML sea servido, recibido y
procesado de la misma manera que un documento HTML. Si bien es una forma restringida de SGML, preserva una
buena parte de su potencial y riqueza, e incluye sus caractersticas ms utilizadas. Fue diseado para que fuera fcil
de implementar, y para interoperar tanto con SGML como con HTML.
El SGML es un lenguaje para describir lenguajes de marcado, particularmente aquellos utilizados en intercambio,
manejo y publicacin de documentos electrnicos. Surgi a mediados de los '80 y se ha mantenido bastante estable.
Gran parte de su estabilidad se debe a que es un lenguaje rico y flexible. Esta flexibilidad, sin embargo, hace que
tenga un alto nivel de complejidad, lo cual impide que pueda utilizarse en varios entornos, incluyendo la Web. Este
lenguaje permite definir la gramtica de lenguajes especficos para diferentes necesidades.
Los objetivos al disear XML fueron:
1. Que fuera directamente utilizable en Internet.
2. Que soportara una amplia variedad de aplicaciones.
3. Que fuera compatible con SGML.
4. Que fuera sencillo escribir programas que procesaran documentos XML.
5. Que la cantidad de caractersticas optativas fuera mnima, en lo posible cero.
Informe de Tesina
6. Los documentos XML deban ser legibles a nivel humano y razonablemente claro.
7. El diseo de XML deba prepararse rpidamente, ser formal y conciso.
8. Los documentos XML deban ser fciles de crear.
9. Lograr etiquetas concisas sera lo menos importante.
Ventajas del XML:
1. Comunicacin de datos. Permite la transferencia de informacin en texto plano, con formato XML, entre
aplicaciones diferentes.
2. Migracin de datos. Facilita un lenguaje intermedio para escribir los datos de una aplicacin a otra diferente,
por ejemplo para intercambio entre diferentes sistemas de bases de datos.
3. Aplicaciones Web. Una sola aplicacin maneja los datos y cada navegador aplica el estilo adecuado para
mostrarlos.
HTML fue pensado como un lenguaje de publicacin e intercambio de documentos tcnicos y cientficos. Resolva el
problema de la complejidad de SGML especificando un pequeo conjunto de etiquetas para edicin de documentos
relativamente simples. Adems de simplificar la estructura de los documentos, HTML agreg soporte para hipertexto.
Ms tarde se agregaran capacidades multimedia. En un breve lapso de tiempo, HTML se hizo muy popular, y
rpidamente super su propsito original. Desde su creacin, se han agregado nuevos elementos para incluir en el
estndar, y as adaptarlo a mercados ms especializados. Esta gran variedad de nuevos elementos trajo problemas
para operar con documentos entre diferentes plataformas.
En XML es relativamente sencillo introducir nuevos elementos o atributos de elementos. La familia XHTML fue
diseada para acomodar esas extensiones por medio de mdulos XHTML y tcnicas para desarrollar nuevos mdulos
compatibles con XHTML.
Tales mdulos permitirn la combinacin de nuevas caractersticas junto con las existentes.
Constantemente se introducen nuevas formas de acceso a Internet. La familia XHTML fue diseada pensando en la
interoperabilidad de agentes de usuario generales. Mediante un nuevo agente de usuario y un mecanismo de perfilado
de documentos, distintos servidores, proxies y agentes de usuario podrn intercambiar contenidos. Finalmente, ser
posible desarrollar contenido en formato XHTML utilizable por cualquier agente de usuario XHTML.
XHTML (Lenguaje de Marcado de Hipertexto Extensible) es una versin ms estricta y limpia de HTML. Surge con el
objetivo de remplazar a HTML ante su limitacin de uso con las cada vez ms abundantes herramientas basadas en
XML. XHTML extiende HTML 4.0, combinando la sintaxis de HTML, diseado para mostrar datos, con la de XML,
diseado para describir los datos.
XHTML surge como el lenguaje cuyo etiquetado, ms estricto que HTML, va a permitir una correcta interpretacin de
la informacin, independientemente del dispositivo desde el que se accede a ella. XHTML puede incluir otros lenguajes
como MathML, SMIL o SVG.
Beneficios
1. Los documentos XHTML son compatibles con XML. Como tales, pueden verse, editarse y validarse con
herramientas estndares de XML.
2. Los documentos escritos en XHTML son compatibles con los agentes de usuario (ejemplo, navegadores) para
HTML 4.
3. Los documentos XHTML pueden utilizar aplicaciones (por ejemplo scripts, o applets) basados en el modelo de
objetos de documento de HTML o en el modelo de objetos de documento (DOM) de XML.
4. A medida que la familia XHTML evolucione, los documentos basados en XHTML 1.0 podrn operar en y entre
varios entornos XHTML.
Informe de Tesina
SOAP
El protocolo SOAP (del ingls Single Object Access Protocol) define una estructura que permite el intercambio de
mensajes, como aquellos necesarios en un Servicio Web, a travs de una red, como por ejemplo Internet.
SOAP permite el intercambio de informacin en ambientes distribuidos y descentralizados. Esta basado en XML, y
define un framework de mensajera extensible, proveyendo un formato de mensajes que puede ser utilizado en una
amplia variedad de escenarios. Est diseado para ser independiente de cualquier modelo particular de programacin.
La especificacin original fue diseada por Microsoft e IBM. Actualmente se encuentra a cargo del XML Protocol
Working Group, del W3C.
Estructura de un mensaje
Un mensaje en formato SOAP se divide en dos secciones contenidas dentro de una envoltura ( envelope): un header
o cabecera y un Body o cuerpo.
La envoltura es el elemento raz de un mensaje SOAP. Mediante este, un proceso que reconoce mensajes SOAP puede
identificarlos.
La cabecera cuenta con informacin destinada a los posibles intermediarios que se encuentren durante el viaje del
mensaje hacia su destinatario final, y es una seccin opcional que puede estar vaca. La funcin que cumple es la de
contener informacin de ruteo que le permita desplazarse por los diferentes intermediarios hasta llegar a su destino
final.
Mediante agregados a esta seccin, se puede expandir la funcionalidad de SOAP, por ejemplo agregando informacin
para identificacin, transacciones, etc.
El cuerpo aloja el contenido primario, o sea, la informacin relevante a la aplicacin o sistema, de inters para el
emisor y el receptor final. Puede tambin no contener informacin.
Un mensaje SOAP puede contener, adems, un attachment, que no necesariamente tiene que ser un documento XML:
una imagen, un documento de texto, etc.
Informe de Tesina
Medios de Transporte
SOAP puede ser utilizado sobre varios medios de transporte, como HTTP o SMTP. Actualmente el medio ms utilizado
es HTTP, por su mayor aceptacin y mejor adaptacin a la infraestructura actual de Internet. SOAP puede operar sin
dificultades con firewalls, ya que estos por lo general liberan el puerto necesario para HTTP, o pueden reconocer un
mensaje SOAP (contenido del tipo text/xml-SOAP).
El uso de HTTP como medio de transporte se especifica mediante un HTTP Binding, en el cual se puede indicar el
mtodo de intercambio a utilizar (GET o POST).
El uso de SMTP nos permite incluir el mensaje SOAP en un correo electrnico.
La eleccin de XML como lenguaje para definir el mensaje se debe a la amplia aceptacin de este, y por su
caracterstica multiplataforma, la que se extiende as al protocolo SOAP. Tambin ofrece la ventaja de ofrecer una
sintaxis y estructura compresible para humanos.
Escenarios
El intercambio ms simple que puede ser representado es el patrn requestresponse, como por ejemplo el RPC
(Remote Procedure Call). SOAP es, de hecho, el sucesor del XML RPC.
Un conjunto mucho mayor de escenarios de uso puede ser definido como un intercambio de informacin basada en
XML, a travs de mensajes SOAP. De esta forma se conforma una conversacin entre aplicaciones o sistemas. La
semntica es definida a nivel de aplicacin, por lo cual SOAP es neutral al objetivo de estas.
Los mensajes SOAP son enviados y recibidos por clientes SOAP y servidores con servicios Web. El cliente genera y
enva, a travs de HTTP, un mensaje que es recibido y procesado por el servidor SOAP.
Debilidades
Debido al uso de mensajes XML largos, una solucin SOAP puede ser ms lenta que otra usando CORBA. Tambin se
ha nombrando como una limitacin el hecho de que se dependa del WSDL.
En el Anexo A se puede ver un ejemplo de formato de mensaje SOAP.
WSDL
A medida que la estandarizacin de los protocolos de comunicacin se extiende, la posibilidad de encarar exitosamente
una organizacin estructurada de las comunicaciones se convierte en una realidad. WSDL (del ingls Web Services
Description Language) es un estndar que permite encarar este objetivo ofreciendo descripciones de servicios.
WSDL permite describir la interfaz de un Servicio Web, y cmo debe ser ligado con una direccin de red.
Generalmente se utiliza en combinacin con SOAP para proveer servicios a travs de Internet. Cualquier programa
cliente que se conecte al Servicio Web puede determinar que funcionalidad esta disponible a partir del documento
WSDL asociado.
El estndar WSDL esta siendo desarrollado por el W3C.
Informe de Tesina
1. Definiciones
2. Operaciones
3. Service Bindings (Ligaduras de Servicios)
Las definiciones son expresadas, generalmente, en XML. Se encargan de definir los tipos de datos y mensajes
utilizados. El vocabulario XML empleado para las definiciones puede basarse en uno previamente acordado mediante
algn tipo de definicin estndar, o usarse uno especialmente definido si se planea un desarrollo para uso in-house.
Otros lenguajes pueden ser utilizados, como el IDL, aunque se opta por XML por ser el dominador del mercado. Para
asegurar un uso nico de nombres de elementos, definiciones, operaciones, etc, se utiliza un XML Namespace.
Mediante las operaciones se describe las acciones para los mensajes soportadas por el Servicio Web. Existen cuatro
tipos de operaciones:
1. De una va (one-way): mensajes que no necesitan una respuesta.
2. Pedido/Respuesta (request-response): el emisor enva un mensaje, y el receptor responde al recibirlo.
3. Solicitud de respuesta (solicit response): un pedido de respuesta (la definicin especifica an esta pendiente)
4. Notificacin (notificacin): envo de un mensaje a varios destinatarios (la definicin especifica an esta
pendiente)
De esta forma las operaciones indican un patrn de intercambio de uno o ms mensajes, indicando la cardinalidad,
tanto de mensajes enviados como recibidos, y quienes los enviaron y/o recibieron.
Finalmente, las operaciones son agrupadas en port types o interfaces. Las interfaces definen, entonces, el conjunto de
operaciones soportados por el Web Service.
Cabe notar que hasta el momento se ha llevado a cabo una definicin de funcionalidad en un sentido abstracto, sin
referirnos a ningn tipo de formato de transporte o plataforma subyacente. WSDL separa las anteriores definiciones de
los detalles concretos de su implementacin permitiendo la portabilidad y la reutilizacin de estas especificaciones.
El Service binding especfica la forma de conectar una interfase con un puerto o endpoint, definiendo una asociacin
con una direccin de red (por ejemplo, una URL) con dicha interfase. Describe cmo y donde acceder al Servicio Web,
por lo que se trata de una definicin a un nivel concreto. El servicio queda definido entonces a partir de una coleccin
de endpoints. El binding generalmente es creado utilizando SOAP, aunque otros protocolos para el pase de mensajes
pueden ser utilizados, como por ejemplo CORBA IIOP, DCOM, etc.
UDDI
UDDI, acrnimo de Universal Description, Discovery and Integration, define un registro para negocios o entidades que
quieran dar a conocer en Internet sus servicios disponibles. As, UDDI es un Servicio Web que maneja informacin
sobre proveedores, implementaciones de servicios y datos adicionales sobre ellos. Esta basado en XML y es
independiente de cualquier plataforma. UDDI es otro de los estndares mantenidos por OASIS.
UDDI permite confeccionar un catalogo de negocios, permitiendo publicar listados de servicios y descubrir otros.
Tambin permite definir cmo los servicios o aplicaciones deben interactuar a travs de Internet. De esta manera los
proveedores de servicios Web pueden darse a conocer, y los potenciales clientes realizar bsquedas por servicios que
satisfagan sus necesidades.
La versin actual de UDDI es la V2.0 aprobada como un Estndar OASIS, y ya existen numerosos productos y servicios
Informe de Tesina
que la implementan. La versin V3.0 esta actualmente bajo desarrollo. Asimismo, UDDI es complementario con otros
proyectos de OASIS y el W3C, como ser SOAP, WSDL, WS-Security, etc.
La informacin que guarda un registro UDDI se puede dividir en un conjunto de categoras de datos simples:
1. Quin? (Who?) Informacin sobre el negocio o institucin. Nombre, identificacin, direccin de contacto,
etc.
2. Qu? (What?) Informacin de categorizacin (por ejemplo, cdigos industriales o clasificaciones de
productos) e informacin descriptiva de los servicios disponibles.
3. Dnde? (Where?) Informacin de registro sobre la URL, direccin de correo electrnico u otro medio a
travs de la cual se accede al servicio.
4. Cmo? (How?) Informacin de cmo funciona una interfase en particular del Servicio Web registrado.
Generalmente se agrupa a estas categoras bajo el nombre de Pginas blancas (Quin?), Pginas amarillas (Qu?) y
Pginas verdes (Dnde? y Cmo?).
UDDI esta diseada para interactuar con SOAP y WSDL. Por medio de un mensaje SOAP se puede interrogar a un
servidor UDDI para que este responda con informacin de acceso a un Servicio Web particular, por medio de un
documento WSDL.
Uso de UDDI
Un negocio u organizacin puede implementar uno o ms registros UDDI privados o pblicos. Un registro privado
permitir acceso slo a usuarios autorizados, mientras que uno pblico no impone restricciones de acceso. Una
combinacin de registros pblicos y privados permite realizar una divisin entre los servicios de informacin internos y
externos.
El beneficio de tener, y ofrecer, acceso a esta informacin es el de proveer medios para que terceros puedan descubrir
las interfaces disponibles para interactuar con un servicio, aumentando la eficacia de la organizacin que lo
implemente.
Informe de Tesina
WS-SECURITY
Muchos problemas se asocian con el envo de mensajes en una ruta ms compleja que la de solicitud/respuesta o a
travs de un sistema de transmisin en el que no interviene HTTP. La identidad, integridad y seguridad del mensaje y
el remitente se deben proteger en los distintos saltos. A lo largo de la ruta se deben utilizar varias claves de cifrado.
Los dominios de confianza se cruzarn. HTTP y sus mecanismos de seguridad nicamente hacen frente a la seguridad
punto a punto. Es necesario que las soluciones ms completas incorporen un concepto de seguridad de extremo a
extremo. WS-Security trata el modo de mantener un contexto seguro a travs de una ruta de mensajes de varios
puntos.
WS-Security aborda el tema de la seguridad haciendo uso de las especificaciones y los estndares existentes. Con ello
se evita la necesidad de definir una solucin de seguridad completa en WS-Security. La industria ha resuelto muchos
de estos problemas. Kerberos y X.509 se ocupan del tema de la autenticacin. Asimismo, X.509 emplea la
infraestructura de clave pblica (PKI) existente en la administracin de claves. XML Encryption y XML Signature
describen distintas formas de cifrar y firmar el contenido de los mensajes XML. XML Canonicalization analiza los modos
de hacer que XML est preparado para el proceso de firma y cifrado. Lo que WS-Security aporta a las especificaciones
existentes es un marco para incorporar estos mecanismos a un mensaje SOAP.
WS-Security define un elemento de encabezado SOAP para transportar datos relacionados con la seguridad.
Fundamentalmente, WS-Security es una especificacin para un contenedor de metadatos de seguridad basado en
XML.
En el encabezado, los mensajes pueden almacenar informacin sobre el autor de la llamada y el modo en que se ha
firmado y cifrado el mensaje. WS-Security presenta una solucin extremo a extremo para la seguridad del servicio
Web conservando toda la informacin de seguridad en la parte SOAP del mensaje.
Los tres puntos siguientes son los principales aspectos presentes en el mbito de la seguridad:
1. Autenticacin
2. Firmas
3. Cifrado
Autenticacin
WS-Security proporciona un gran nmero de formas de validar a un usuario. En la especificacin se abordan tres
mtodos de entre todos los dems:
1. Nombre de usuario y contrasea.
2. Infraestructura de clave pblica (PKI) a travs de certificados X.509.
3. Kerberos.
Informe de Tesina
Informe de Tesina
Certificados X.509
El simple envo de un certificado X.509 es otra opcin en el proceso de autenticacin de usuarios. Estos certificados
informan exactamente de la identidad del usuario. Con el uso de PKI, el certificado se puede asignar a un usuario
existente en la aplicacin. El uso del certificado por s mismo podra suponer el riesgo de sufrir ataques repetitivos con
bastante facilidad. Por lo tanto, es una buena alternativa hacer que el remitente tambin firme el mensaje empleando
su clave privada. De este modo, cuando se descifra el mensaje, se sabr que se trata realmente del usuario.
Kerberos
Para el uso de Kerberos, el usuario presenta una serie de credenciales, como el nombre de usuario y la contrasea o
un certificado X.509. Una vez realizada la comprobacin oportuna, el sistema de seguridad concede al usuario un vale
(TGT). El usuario no podr descifrar los datos ocultos del vale, pero s presentarlos para obtener acceso a otros
recursos. El vale se suele presentar para obtener un vale de servicio (ST). Kerberos resulta una especificacin
interesante, ya que contiene un mecanismo para que el cliente pueda demostrar su identidad en un servicio y
viceversa. El vale de servicio slo es eficaz para tener acceso a un recurso de red que se pueda utilizar para conocer la
identidad del remitente. Cuando se presenta un vale Kerberos en un mensaje, los datos se deben copiar "a ciegas" en
el propio mensaje. WS-Security no explica cmo se obtiene un vale o un vale de servicio.
Firma
Cuando se firma un mensaje, es muy difcil que ste se pueda ver alterado. La firma no protege el contenido del
mensaje de accesos no autorizados. Con la presencia de la firma, el receptor del mensaje SOAP puede saber qu
elementos no se han modificado durante el envo. Siempre que se pueda, se debe utilizar XML Signature, debido a que
Informe de Tesina
ya administra una serie de elementos dificultosos que se pueden averiguar. WS-Security simplemente explica cmo
utilizar la firma para comprobar que el mensaje no se ha modificado.
La firma se genera utilizando XML Signature. Para firmar un mensaje sencillo como, por ejemplo, "Hola a todos", casi
todos los elementos del mensaje se deben firmar individualmente. Cada vez que cambia un elemento es necesario
actualizar la firma para que el resto de elementos aparezcan de forma correcta. Por qu? Si el contenido cambia,
puede que la firma no coincida. En un mensaje SOAP, las firmas y los datos necesarios adicionales agregan un poco de
informacin adicional.
Cifrado
Existen situaciones en las que no es suficiente con comprobar la identidad del remitente y demostrar que el contenido
del mensaje no se ha visto alterado. Si se enva un nmero de tarjeta de crdito o de cuenta bancaria en texto sin
formato y firmado, un intruso puede llegar a comprobar que ningn otro intruso haya modificado el contenido del
mensaje. Por lo tanto, el intruso tendr una gran seguridad de que los datos son vlidos. Esto no beneficia al usuario
en absoluto. Resultara mucho ms recomendable que los datos se cifraran de tal modo que slo la persona a la que
va destinado el mensaje pudiera consultarlos. Cualquier persona que observe el intercambio de conexin permanecera
ajena respecto al contenido del mensaje. Tal y como sucede con la firma de mensajes, la especificacin WS-Security
toma las medidas adecuadas, adopta un estndar ya existente y, asimismo, realiza la tarea de cifrado. Es decir, se
incorpor XML Encryption.
Cuando se cifran los datos, se puede optar por el uso del cifrado simtrico o asimtrico. El primero de ellos requiere un
secreto compartido. Es decir, la clave utilizada para cifrar el mensaje es la misma que se puede emplear para
descifrarlo. El cifrado simtrico resulta conveniente si se controlan ambos puntos finales y si las personas y
aplicaciones que utilicen las claves son de confianza.
Si los datos se deben enviar utilizando claves fcilmente distribuidas, se debe considerar el uso del cifrado asimtrico.
Los certificados X.509 lo permiten. El punto final que recibe los datos puede enviar pblicamente su certificado y
permitir a cualquier usuario o a todos ellos cifrar la informacin con la clave pblica. El receptor ser el nico que
conozca la clave privada. Por ello, solamente l podr descifrar los datos y hacerlos legibles.
Informe de Tesina
WS-Security en resumen
WS-Security permite que el mensaje SOAP identifique al remitente, firme el mensaje y cifre su contenido. Siempre que
se pueda, las especificaciones existentes se vuelven a utilizar para reducir la cantidad de innovacin necesaria para
transmitir de forma segura un mensaje SOAP. Debido a que toda la informacin se transmite en el propio mensaje,
existir una neutralidad de transporte. El mensaje puede estar seguro si se transmitiera mediante HTTP, correo
electrnico o CD-ROM.
Informe de Tesina
El proceso general de implementacin describe en forma general el proceso para implementar cualquier tipo de
proyecto de tecnologa. Pero el mismo debe ser adecuado a las realidades de cada proyecto. Por ello en esta seccin
se detallan las particularidades del proceso empleado en el presente proyecto.
El presente entallamiento tiene dos particularidades centrales, la primera es que se enmarca dentro de un trabajo de
tesis de licenciatura y por lo tanto uno de los principales artefactos a producir es el trabajo de investigacin en si. El
cual se encuentra en el Capitulo 2 Fundamentacin Terica la segunda particularidad es el aspecto solitario de
implementacin del presente proyecto, provocando esto que se haya tomado la decisin de utilizar metodologas, que
si bien respetan al PGI, se adaptan mejor a este tipo de situacin.
Como se mencion, para agilizar la gestin del proyecto, se ha decidido realizar la misma bajo la consigna de las
metodologas Agile. Donde para garantizar su correcto uso se ha utilizado la herramienta XPlanner que se ha adaptado
perfectamente a la tipologa descripta, utilizando en particular la metodologa eXtreme Programming (XP).
A continuacin se describe brevemente (segn Wikipedia) en que consiste dicho paradigma:
La programacin extrema o eXtreme Programming (XP) es un enfoque de la ingeniera de software formulado por
Kent Beck, autor del primer libro sobre la materia, Extreme Programming Explained: Embrace Change (1999). Es la
ms destacada de los procesos giles de desarrollo de software. Al igual que stos, la programacin extrema se
diferencia de las metodologas tradicionales principalmente en que pone ms nfasis en la adaptabilidad que en la
previsibilidad. Los defensores de XP consideran que los cambios de requisitos sobre la marcha son un aspecto
natural, inevitable e incluso deseable del desarrollo de proyectos. Creen que ser capaz de adaptarse a los cambios de
requisitos en cualquier punto de la vida del proyecto es una aproximacin mejor y ms realista que intentar definir
todos los requisitos al comienzo del proyecto e invertir esfuerzos despus en controlar los cambios en los
requisitos.Se puede considerar la programacin extrema como la adopcin de las mejores metodologas de desarrollo
de acuerdo a lo que se pretende llevar a cabo con el proyecto, y aplicarlo de manera dinmica durante el ciclo de
vida del software.
Informe de Tesina
Programacin en parejas: se recomienda que las tareas de desarrollo se lleven a cabo por dos personas en un
mismo puesto. Se supone que la mayor calidad del cdigo escrito de esta manera -el cdigo es revisado y
discutido mientras se escribe- es ms importante que la posible prdida de productividad inmediata.
Frecuente interaccin del equipo de programacin con el cliente o usuario. Se recomienda que un
representante del cliente trabaje junto al equipo de desarrollo.
Correccin de todos los errores antes de aadir nueva funcionalidad. Hacer entregas frecuentes.
Refactorizacin del cdigo, es decir, reescribir ciertas partes del cdigo para aumentar su legibilidad y
mantenibilidad pero sin modificar su comportamiento. Las pruebas han de garantizar que en la refactorizacin
no se ha introducido ningn fallo.
Propiedad del cdigo compartida: en vez de dividir la responsabilidad en el desarrollo de cada mdulo en
grupos de trabajo distintos, este mtodo promueve el que todo el personal pueda corregir y extender cualquier
parte del proyecto. Las frecuentes pruebas de regresin garantizan que los posibles errores sern detectados.
Simplicidad en el cdigo: es la mejor manera de que las cosas funcionen. Cuando todo funcione se podr
aadir funcionalidad si es necesario. La programacin extrema apuesta que es ms sencillo hacer algo simple y
tener un poco de trabajo extra para cambiarlo si se requiere, que realizar algo complicado y quizs nunca
utilizarlo.
La simplicidad y la comunicacin son extraordinariamente complementarias. Con ms comunicacin resulta ms fcil
identificar qu se debe y qu no se debe hacer. Mientras ms simple es el sistema, menos tendr que comunicar
sobre este, lo que lleva a una comunicacin ms completa, especialmente si se puede reducir el equipo de
programadores.
Informe de Tesina
INTRODUCCIN
El presente documento tiene por objetivo describir la infraestructura (equipos informticos, software y
comunicaciones) requerida para el proceso de desarrollo e implementacin de producto Switch Transaccional que ser
desarrollado dentro del marco de la Tesis de Licenciatura en informtica de la Universidad de la Patagonia San Juan
Bosco.
Informe de Tesina
El presente documento establece el detalle de herramientas de desarrollo como todo el software necesario y requerido
para la puesta en marcha del presente trabajo de tesis.
ARQUITECTURA
La Arquitectura del Switch Transaccional prev como primer medida el ruteo y sincronizacin de servicios entre
organizaciones y entidades, de esta forma el intercambio de servicios y mensajes queda concentrado y estandarizado
en el Switch Transaccional.
Como se puede observar la arquitectura del portal est definida fundamentalmente por un conjunto de servicios back-
end soportados en el concepto de arquitectura B2B (Business to Business) o A2A (Application to Application) basada
en el concepto de colas para aplicaciones distribuidos, en este caso implementadas mediante la implementacin de
Web-Services y el uso de BPEL.
Informe de Tesina
Por otra parte existe un mdulo de configuracin del portal que estar desarrollado en JAVA en una arquitectura en
capas utilizando para ello J2EE y el patrn Model-View-Controller.
DEFINICIN DE AMBIENTES
Un ambiente est definido por un conjunto de Soft de base (SO, Base de datos y servidor de aplicaciones) y por las
herramientas con sus respectivas versiones y configuraciones utilizadas.
Es muy importante para la estabilidad de un ambiente conocer cada herramienta y las versiones utilizadas para
determinar de esta forma una configuracin dada para un ambiente y de esta forma mantenerlo controlado ante los
cambios que deban sufrir (actualizaciones y nuevas versiones).
As mismo los ambientes contienen un conjunto de configuraciones y de datos de la aplicacin a desarrollar que
tambin debern ser controlados por cada ambiente para mantener la integridad de la aplicacin, su desarrollo y las
pruebas que se deban realizar sobre la misma.
DESARROLLO
Formalmente se utilizar la denominacin DESA para referirnos a este ambiente.
Es el ambiente donde se desarrolla todo el proceso implementacin (Anlisis, diseo y Construccin). Por proceso de
implementacin se entiende:
Desarrollo de casos de usos: Requerimientos funcionales de la aplicacin.
Construccin de la aplicacin.
Informe de Tesina
Construccin de scripts para realizar las distintas pruebas de la aplicacin y ajustes a las configuraciones
existentes.
Construccin de componentes de ingeniera de sistemas y soporte.
TESTING
Formalmente se utilizar la denominacin TEST para referirnos a este ambiente
Es el ambiente donde se realizan las pruebas de conformidad de los casos de uso implementados (durante el proceso
de implementacin), y donde adems se realizan pruebas de carga. Especialmente en el desarrollo de la presente
aplicacin donde su caracterstica de backend se basa fundamentalmente en la actividad transaccional de servicios
Este ambiente tambin se utiliza en los procesos de capacitacin.
El ambiente TEST puede ser clonado de los ambientes DESA o PROD con la finalidad de equiparar cualquiera de los
ambientes y realizar las pruebas respectivas. Este mismo proceso de clonado servir tambin para el testeo de los
paquetes de Deploy, garantizando que la aplicacin de los mismos mantendr la integridad en el ambiente PROD. En
la seccin Control de Configuraciones se detallan los procedimientos asociados al clonado de ambientes.
PRODUCCIN
Formalmente se utilizar la denominacin PROD para referirnos a este ambiente
Es el ambiente de produccin que se utilizar para uso de la Solucin durante y luego de la finalizacin del proceso de
implementacin.
El contenido de datos y funcionalidad de este ambiente va aumentando a medida que se avanza en el proceso de
implementacin y en el refinamiento de casos de uso. Los usuarios del cliente trabajan sobre este ambiente utilizando
todas aquellas funcionalidades que hayan sido puestas en marcha. Cada nuevo caso de uso cuya implementacin haya
sido aprobada por el cliente en el ambiente de TEST, es implementado (siguiendo el plan de estrategia de control de
configuraciones) en este ambiente para su utilizacin por parte de los usuarios.
AMBIENTE DE DESARROLLO
Dada la gnesis del proyecto donde la utilizacin y la produccin de software de cdigo abierto (Open Source) es un
factor impulsor de la Sociedad de la Informacin. El ambiente de desarrollo del producto Switch Transaccional debe
cumplir con las caractersticas mencionadas.
Se debe mencionar que por las caractersticas del producto a construir se ha decidido la utilizacin de Java como
lenguaje debido a la gran integracin que posee el mismo con las tecnologas de aplicaciones distribuidas. De hecho
Java fue pensado como un lenguaje orientado a las aplicaciones en redes y sistemas distribuidos
Para ello se han recorrido distintos ambientes IDE (Integrated development environment) que permitieran lograr los
objetivos Open Source y la utilizacin de Java como lenguaje.
Dicho ambiente deba soportar adems la utilizacin de PlugIns (componentes enchufables o lo que se conoce como
tecnologa de cartuchos). Dichos PlugIns deban permitir la incorporacin de diversas herramientas para la realizacin
del proyecto, no solo desde el punto de vista de desarrollo sino tambin para la Ingeniera de Requerimientos,
Arquitectura, Diseo, Construccin, Testing y Documentacin.
En el proceso se investigaron y probaron varias herramientas de las cuales solo dos cumplan con los requisitos
buscados:
Eclipse de Eclipse Foundation
ver http://www.eclipse.org/org/
NetBeans
Informe de Tesina
SOFTWARE DE BASE
Sistema Operativo
GNU/Linux Fedora Core 6 de 64 bits. http://www.redhat.es/fedora/ http://fedoraproject.org/
Linux version 2.6.20-1.2952.fc6 (brewbuilder@ls20-bc2-14.build.redhat.com) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007
Ver Anexo C: Detalle del Sistema Operativo
Base de datos
MySQL 5.0.27 http://www.mysql-hispano.org/ http://www.mysql.org/
HERRAMIENTAS DE GESTIN
XPlanner Version 0.7b7 --> Herramienta de planificacin, control y seguimiento de proyectos utilizando
metodologas Agile (eXtreme Programming: XP) http://www.xplanner.org/
OpenOffice.org 2.0.4 --> Herramienta de oficina que permiten gestionar documentos, planillas de clculo y
pesentaciones. http://es.openoffice.org/
HERRAMIENTA DE DESARROLLO
NetBeans IDE 6 (Release Beta1) http://www.netbeans.org/community/releases/60/index.html
Visual Web Pack http://www.netbeans.org/products/visualweb/
Enterprise Pack http://www.netbeans.org/products/enterprise/
UML Modeling http://www.netbeans.org/products/uml/index.html
HARDWARE UTILIZADO
Motherboard: ECS RS485M-M
Procesador: AMD Athlon(tm) 64 X2 Dual Core Processor 3600+
Informe de Tesina
AMBIENTES DE TESTING
Para el ambiente de Testing se utilizar el mismo hardware, Soft de base y herramientas que para el ambiente de
desarrollo pero se utilizarn un esquema de base de datos diferencial al igual que un deploy diferente en el servidor de
aplicaciones.
AMBIENTE DE PRODUCCIN
Para el ambiente de produccin tambin se utilizar el mismo hardware, Soft de base y herramientas que para el
ambiente de desarrollo. Tambin aqu con el esquema de ambiente diferenciado para la Base de datos y servidor de
aplicaciones.
Pero dada la gnesis de integracin de aplicaciones y simulando las posibles aplicaciones clientes de las organizaciones
que demanden y provean servicios, se agrega una nueva plataforma con el objetivo de realizar dichas pruebas y
garantizar que el Switch Transaccional funciona integrando distintas plataformas de ejecucin
SISTEMA OPERATIVO
GNU/Linux Fedora Core 6 de 64 bits. http://www.redhat.es/fedora/ http://fedoraproject.org/
Linux version 2.6.20-1.2952.fc6 (brewbuilder@ls20-bc2-14.build.redhat.com) (gcc version 4.1.1 20070105
(Red Hat 4.1.1-51)) #1 SMP Wed May 16 18:18:22 EDT 2007
Ver Anexo A: Detalle del Sistema Operativo
BASE DE DATOS
SERVIDOR DE APLICACIONES
GlassFish V2 https://glassfish.dev.java.net/
HARDWARE UTILIZADO
Motherboard: MICRO-STAR INTERNATIONAL CO., LTD (6A6LVM4D) Bios: Phoenix-Award BIOS v6.00PG
Procesador: AMD Athlon TH (Thoroughbred) / AMD Duron(tm) processor / 1399 Mhz
Controlador: ATA Controller
Disco Rgido: Western Digital de 80 GB de 7500 RPM (WDC WD800LB-55DNA0)
Memoria: 512 MB SDRAM de 60 ns + 256 MB SDRAM de 60 ns.
RED: VIA Rhine II Fast Ethernet Adapter
Informe de Tesina
CONTROL DE CONFIGURACIONES
Definiciones
PI --> Paquete de Instalacin. El mismo contiene las siguientes secciones:
DB:
Actualizacin e instalacin de tablas, vistas, triggers y procedimientos de la Base de datos. El script deber
prever e ir solicitando informacin as corresponda. Usuario de conexin y esquema a instalar. Ser
responsabilidad del instalador conocer el ambiente donde instalar y garantizar que se est instalando el
script en dicho ambiente.
Tambin este proceso debe garantizar la actualizacin de datos cuando corresponda, salvo que se requiera
intervencin de los usuario en cuyo caso deber quedar aclarado en la documentacin general del PI
XML --> Conjunto de XML, XSLT, DTS o XSD de la aplicacin. A tal fin se definir un nico directorio del
servidor de aplicaciones que contendr todos los archivos de este tipo para cada ambiente. Estos archivos
pueden ser tanto de configuracin de uso de la aplicacin, como de definiciones de usuario como puede ser un
proceso BPEL y una parser o transformacin requerida.
JAR --> Conjunto de paquetes Java con la aplicacin en si. A tal fin se definir un nico directorio del servidor
de aplicaciones que contendr todos los archivos de este tipo para cada ambiente.
VGUI --> Conjunto de archivos vinculados a la parte visual de la aplicacin. A tal fin se definir un nico
directorio del servidor de aplicaciones que contendr todos los archivos de este tipo para cada ambiente. Estos
archivos pueden ser tanto Java Server faces (JSF) como Java Server Pages (JSP).
DOC --> Conjunto de archivos vinculados con la documentacin de la aplicacin. A tal fin se definir un nico
directorio del servidor de aplicaciones que contendr todos los archivos de este tipo para cada ambiente. Estos
archivos pueden contener tanto documentos de texto, como hojas de clculo, presentaciones y adems todo el
material UML desarrollado y mantenido en el anlisis y diseo de la aplicacin. Esto permitir garantizar una
trazabilidad entre los objetos de la aplicacin y su documentacin.
AI -->
Actualizacin Intermedia. Este paquete puede contener las mismas secciones anteriores salvo la seccin DB.
De esta forma se garantizar que los AI no contienen cambios estructurales a la aplicacin. Ya que el resto de
las secciones son inocuas ante nuevos Deploy, pero la base de datos no, ya que all se registrar el
comportamiento de la aplicacin mediante una arquitectura de meta informacin de la misma.
Deber quedar claro por lo tanto que no se podr incluir ningn nuevo objeto de la aplicacin que requiera de
dichos cambios de Base de datos. Quedando las actualizaciones limitadas a solucionar problemas existentes en
la aplicacin que impiden realizar, por ejemplo, el plan de pruebas trazado.
Informe de Tesina
Como herramienta de administracin y control de configuraciones se disear una pequea base de datos que
permita registrar las actualizaciones y la registracin de parches instalados en cada ambiente, permitiendo de esta
forma controlar los componentes y las revisiones de instalacin de cada ambiente.
Ser muy importante la clara documentacin de los PI y de los AI que permitir realizar la trazabilidad de los
componentes que contiene cada ambiente y su respectiva versin.
PLAN DE CONTINGENCIA
Debido a la gnesis del proyecto no implica un mayor riesgo la administracin de un plan de contingencia ya que el
proyecto afecta a la tesis de licenciatura donde se involucra a una sola persona y donde no existen riesgos econmicos
afectados a la misma.
Por lo tanto no se describirn posibles escenarios de amenaza ni impactos consecuentes de dichas amenazas. S se
establecer un esquema de resguardo del proyecto y una indicacin de restauracin del mismo y los tiempos
incurridos para la restauracin del mismo.
Toda la gestin y desarrollo del proyecto se administra desde un slo equipo, por lo tanto el procedimiento que a
continuacin se describe afecta a dicho equipo utilizado en el ambiente DESA y TEST. No se preve respaldo del
ambiente de produccin ya que el mismo es reinstalable y recuperable desde los parches de actualizacin e
instalacin en produccin.
CONFIGURACIN
ARCHIVE_DIR=/media/backup/demian
COMPRESSION=gzip
DEV=/dev/hda
DVD_DIR=/media/dvd
DVD_SIZE=4.7G
EXCLUDE_FILE=/home/demian/excluded.files
INCLUDE_FILE=/home/demian/included.files
LOG_FILE=/home/demian/yakup.log
MEDIA=dvd
MKISOFS_OPTS="-r -J"
PREFIX=yakup%l.$(date +%Y%m%d)
RESTORE_DIR=/media/restore/demian
VOLUME_ID="yakup%l $(date +%F) (%n of %N)"
Informe de Tesina
DETALLE DE HORAS POR HISTORIAS DEL USUARIO (USER STORY) EJECUTADAS EN EL PROYECTO
Informe de Tesina
Informe de Tesina
RESUMEN DE ITERACIONES
Para un detalle completo del registro de todas las tareas ejecutadas en el proyecto ver Anexo F: Detalle de las etapas
de implementacin a continuacin se realiza un resumen de los principales hitos y/o entregables de cada iteracin:
Se definieron y especificaron las clases Java y las JSP correspondientes a la aplicacin de administracin
del Switch Transaccional.
Informe de Tesina
Capacitacin sobre las herramientas tecnolgicas propuestas tercera parte: SOA y BPEL.
Informe de Tesina
Solucin
La solucin completa del SwitchTransaccional se encuentra registrada en Google Code como proyecto Open Source. Si
se desea una copia completa de los resultados del presente trabajo se debe bajar la informacin de:
http://switchtransaccional.googlecode.com donde en la pestaa source se puede obtener el cdigo y documentacin
completa del proyecto.
A fin de realizar el presente informe se realiza una sntesis y resumen de todos los resultados del proyecto, mostrando
los resultados mas relevantes del proyecto.
Informe de Tesina
Informe de Tesina
SWITCHTRANSACCIONAL
Informe de Tesina
Informe de Tesina
DIAGRAMAS DE SECUENCIA
Mensaje Sincrnico
Informe de Tesina
Mensaje Asincrnico
Informe de Tesina
MODELO DE DATOS
A continuacin se presenta el modelo de datos completo utilizado para el desarrollo del Switch Transaccional. El detalle
completo del diccionario de datos se encuentra alojado en el sitio Open Source del proyecto:
http://switchtransaccional.googlecode.com
Informe de Tesina
ENTIDADES EXTERNAS
Informe de Tesina
Informe de Tesina
COMPONENTES
Las clases del Switch Transaccional se dividen en dos grupos, por un lado todas las clases necesarias para
implementar el patrn MVC (Model/View/Controller) que permiten administrar los meta-modelos y configuraciones del
Switch Transaccional y por otro todos los Web Services y BPEL's que conforman el motor del Switch Transaccional.
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.
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
Pginas JSP
Todas las pginas JSP se construyeron usando tags extendidos del Framework SOFIA.
Aplicacin Infraestructura
AbmcAccesoMenu.jsp --> Implementa las altas, bajas, modificaciones y consultas de la configuracin de
acceso a los mens por parte de los usuarios. Utiliza el modelo infraestructura.models.AccesoMenuModel y
el controlador infraestructura.controllers.BaseController.
AbmcAtributoGenerico.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin para
implementar atributos genricos que puedan ser utilizados tanto por entidades externas como por cualquier
tabla declarada en el diccionario de la aplicacin. Utiliza el modelo infraestructura.models.AtributosRolModel
y el controlador infraestructura.controllers.BaseController.
AbmcClaseAtributoRol.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin para
implementar clases de atributos genricos o sea grupo de atributos que permitan clasificar y armar las
pestaas genricas en las pantallas de administracin de atributos. Utiliza el modelo
infraestructura.models.ClaseAtributoRolModel y el controlador infraestructura.controllers.BaseController.
AbmcClaseListaValorAtributo.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin
de valores asociados a un atributo genrico, permitiendo armar listas de validacin dinmica en el alta de los
atributos. Utiliza los modelos infraestructura.models.ClaseLovAtributoModel y
infraestructura.models.LovAtributoModel y el controlador
infraestructura.controllers.AbmcClaseListaValorAtributoController.
AbmcConfiguracion.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de
configuraciones genricas en funcin de valores alcanzados por atributos genrico, permitiendo implementar
comportamientos dinmicos en las aplicaciones. Utiliza los modelos
infraestructura.models.ConfiguracionModel, infraestructura.models.EsquemaConfiguracionModel e
infraestructura.models.AtributosConfiguracionModel y el controlador
infraestructura.controllers.AbmcConfiguracionController.
AbmcDiccionarioAplicacion.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de
objetos de la aplicacin como por ejemplos las tablas de la base de datos. Utiliza el modelo
infraestructura.models.DiccionarioAplicacionModel y el controlador infraestructura.controllers.BaseController.
AbmcEntidadExterna.jsp --> Implementa las altas, bajas, modificaciones y consultas de entidades externas
de la aplicacin, pudiendo estos tomar uno o varios roles definido para la aplicacin. Tambin administra
todos los atributos genricos definidos para la entidad agrupndolos segn su clase. Utiliza los modelos
infraestructura.models.EntidadExternaModel, infraestructura.models.RolesEntidadModel e
infraestructura.models.AtributosEntidadModel y el controlador
infraestructura.controllers.AbmcEntidadExternaController.
AbmcEsquemaConfiguracion.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin
de los posibles esquemas de configuracin genrica que utilizar la aplicacin. Utiliza el modelo
infraestructura.models.EsquemaConfiguracionModel y el controlador
infraestructura.controllers.AbmcEsquemaConfiguracionController.
AbmcMenues.jsp --> Implementa las altas, bajas, modificaciones y consultas de los mens de la aplicacin,
Informe de Tesina
permitiendo de esta forma configurar cualquier estructura de men genrica. Utiliza el modelo
infraestructura.models.MenuModel y el controlador infraestructura.controllers.BaseController.
AbmcRolEntidad.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de los
posibles roles de entidades externas que se usarn en la aplicacin. Tambin permite asociar que atributos
genricos quedan definidos para el rol. Utiliza los modelos infraestructura.models.RolEntidadModel e
infraestructura.models.AtributosRolModel y el controlador
infraestructura.controllers.AbmcRolEntidadController.
AbmcRoles.jsp --> Implementa las altas, bajas, modificaciones y consultas de la definicin de los roles de
usuario para implementar el acceso a la aplicacin. Utiliza el modelo infraestructura.models.RolesModel y el
controlador infraestructura.controllers.AbmcRolEntidadController.
AbmcWebSiteUsers.jsp --> Implementa las altas, bajas, modificaciones y consultas de los usuarios de la
aplicacin y los roles de acceso. Utiliza los modelos infraestructura.models.WebsiteUserModel e
infraestructura.models.UsuarioRolesModel y el controlador infraestructura.controllers.WebSiteUserController.
Aplicacin SwitchTransaccional
AbmcConfiguracionServicio.jsp --> Implementa las altas, bajas, modificaciones y consultas del
comportamiento especfico para los servicios distribuidos. Utiliza los modelos
switchTransaccional.models.ServicioDistribuidoModel y
switchTransaccional.models.ConfiguracionServicioModel y el controlador
switchTransaccional.controllers.AbmcConfiguracionServicioController.
AbmcRecuperaAtributos.jsp --> Implementa las altas, bajas, modificaciones y consultas que permiten
configurar cmo se recupera el contenido de un atributo de un servicio distribuido. Utiliza los modelos
switchTransaccional.models. RecuperaAtributoModel y switchTransaccional.models. ServicioDistribuidoModel
y el controlador switchTransaccional.controllers.AbmcRecuperaAtributosController.
AbmcServicioDistribuido.jsp --> Implementa las altas, bajas, modificaciones y consultas de lo sservicios
distribuidos que atiende el Switch Transaccional, permitiendo administrar los atributos genricos del mismo
que darn origen al contenido. Utiliza los modelos switchTransaccional.models.ServicioDistribuidoModel e
infraestructura.models.AtributosEntidadModel y el controlador
switchTransaccional.controllers.AbmcServicioDistribuidoController.
AbmcServiciosEntidad.jsp --> Implementa las altas, bajas, modificaciones y consultas de los servicios
asociados a un proveedor de servicios distribuidos que son los responsables de atender los mensajes
enviados por los clientes. Utiliza los modelos switchTransaccional.models.ServiciosEntidadModel y
switchTransaccional.models.ServicioDistribuidoModel y el controlador
switchTransaccional.controllers.AbmcServiciosEntidadController.
Controladores
Los controladores son los mencionados en la seccin Pginas JSP y tiene como misin capturar las interacciones de los
usuarios de las pginas web y la de aplicar las reglas de negocio respectivas para el correcto funcionamiento de las
pginas.
Todos los controladores derivan de infraestructura.controllers.BaseController que es el responsable de controlar el
aspecto general de las pginas, como por ejemplo el men y de la seguridad de acceso a la aplicacin.
Informe de Tesina
RecuperaAtributosServicio
AdministraLogSwitch
Informe de Tesina
Informe de Tesina
Informe de Tesina
DeterminaConfiguracionServicio
RESUMEN DE BPEL'S
Los BPEL de la solucin son el corazn del Switch Transaccional ya que permiten acoplar y orquestar todas las
actividades requeridas para recibir la solicitud de un servicio, interpretar segn su contenido como se descompone el
mismo, re-enviar todos las solicitudes que se requieran y re-ensamblar una respuesta.
Tambin en los BPEL se pueden implementar capas que permita realizar actividades de Parser y transformacin de
mensajes aplicando normalizaciones a los mismos
Informe de Tesina
Informe de Tesina
Informe de Tesina
Casos testeados
Informe de Tesina
Configuracin requerida
Informe de Tesina
Informe de Tesina
Informe de Tesina
Captulo 4 Conclusiones
La humanidad se encuentra hoy atravesando situaciones graves y complejas que estn impactando en todos los
sistemas: sociales, polticos, educativos, econmicos, ambientales, tecnolgicos, comunicacionales, etc. La discusin no
puede ni debe reducirse a los sistemas ideolgicos que en el pasado obraron como grandes impulsores de sistemas
cerrados y estructurados, los anlisis centrados entre los roles predominantes de lo pblico y/o lo privado, lo
econmico o lo social, la libertad o la planificacin. Debern dejar lugar al concepto de racionalidad, eficiencia y
urgencia que la realidad demanda, pero en este anlisis el hombre y su calidad de vida debern ser el imperativo y
centro de toda accin e indiscutible objeto final de cualquier sistema.
La sociedad de la informacin y especialmente la democratizacin de la comunicacin-informacin tendrn un rol
protagnico en los objetivos de lograr la negentropa de los sistemas y evitar caos de los mismos.
La calidad de vida se vern altamente impactadas por los sistemas comunicacionales, transaccionales e informticos.
En el futuro deber decidirse con muy buena informacin proveniente de indicadores adecuados y monitoreo en lnea
y en tiempo real, cada situacin de arbitraje entre los distintos sistemas y sub-sistemas de las organizaciones polticas,
sociales y econmicas.
Con informacin adecuada se podr, por ejemplo, dimensionar daos por impactos industriales en el medio ambiente,
su impacto en la salud de la poblacin involucrada, en el empleo, en la organizacin social, etc., etc. Podrn
interactuar los sistemas y equilibrarse, pudiendo resolver en forma mas adecuada que la actual, en donde
determinadas decisiones emanan de razones econmicas o polticas sin medir su impacto en las consecuencias
terribles en la calidad de vida y el costo asociado que de la misma deriva. Con la informacin en el momento que se
necesita e interactiva se podr analizar cada variable y los sistemas interactuarn mas equitativa y racionalmente.
Ms an si entendemos que en el caso planteado, por lo menos en los pases desarrollados y en vas de desarrollo, la
brecha digital no es significativa debido a que no estamos hablando del acceso de la tecnologa a las personas sino a
las organizaciones. Ms an si consideramos que las tecnologas descriptas en su mayora son de cdigo abierto y por
lo tanto de acceso pblico para su utilizacin, donde el aporte realizado por el Switch Transaccional engrosa slo un
poco ms las herramientas de conocimiento y tecnologa ya existentes, permitiendo como gran avance el
procesamiento de las transacciones orientados al contenido, utilizando para ello reglas definidas en forma genrica.
Por lo tanto el inconveniente econmico mas relevante es el de la infraestructura de comunicaciones requerida para
implementar este conjunto de herramientas e infraestructura ya que el resto de las cuestiones son inherentes a la
voluntad y decisin poltica y social de cada pas, donde lamentablemente en muchsimas ocasiones todos los recursos
existen menos la voluntad de ponerlos en marcha.
El futuro es hoy, porque si dilapidamos los recursos, habremos comprometido la razn de ser de las organizaciones
humanas que es precisamente la sociedad en si misma.
Informe de Tesina
Bibliografa Y Referencias
1. Katz, Ignacio. Retornar al pensamiento lgico. Revista Mdicos Nmero, NEWSLETTER 82 / 24 de Marzo del
2003.
2. Jalfen, Luis J. Globalizacin y Lgica Virtual. Primera Edicin, Ediciones Corregidor, 1998.
3. Morin, Edgar. El Mtodo. Quinta Edicin, Ediciones Ctedra, 1999.
4. Barry, Jorge y Barry, Damin. La Salud en la Sociedad de la Informacin. 32 JAIIO (Jornadas Argentinas de
Informtica e Investigacin Operativa SIS 2003 (Simposio de Informtica y Salud)
5. Varios Autores. eGov-Interop'05 Conference. Observatory On Interoperable eGovernment Services.
6. Helland, Pat. Microsoft Corporation. Datos externos frente a datos internos.
7. Daz Toledano, Moiss Daniel. Web Services -Introduccin y Escenarios para su Uso.
8. OASIS. Organization for the Advancement of Structured Information Standards: http://www.oasis-
open.org/home/index.php
9. Bray Tim. Sun on Open Office XML ISO Certification.
http://www.tbray.org/ongoing/When/200x/2004/09/24/SmartEC.
10. Carrera, Daniel. The Future Is Open: What OpenDocument Is And Why You Should Care.
http://www.groklaw.net/article.php?story=20050130002908154.
11. Seely, Scott. WS-Security. Microsoft Corporation. Octubre de 2002.
http://www.microsoft.com/spanish/msdn/articulos/archivo/121202/voices/understw.asp
12. Magster Freh, Stephan Alexander. Analysis of global eID with focus on Interoperability by using the TFI
Model. Marzo del 2005. Departament of Information systems London School of Economics and Political
Science.
13. Michelson, Adam. SOA Versus the Appliance. Mayo del 2006. revista LinuxWorld.
14. Panda, Debu. An Introduction to Service-Oriented Architecture from a Java Developer Perspective. Enero del
2005. http://www.onjava.com
15. Angelov, Samuil & Grefen, Paul. A Framework for Analysis of B2B Electronic Contracting Support. University of
Twente, The Netherlands.
16. Laskey, Ken. Reference Model for Service Oriented Architecture. Marzo 2006. Developed by OASIS SOA
Reference Model Technical Committe.
17. Varios autores. SOA Application Learning Trail. Netbeans.org. http://www.netbeans.org/kb/trails/soa.html
18. Varios autores.Java EE Applications Learning Trail. http://www.netbeans.org/kb/trails/java-ee.html
19. David Hunter, Kurt Cagle, Chris Dix et al, Beginning XML, 2nd Edition: XML Schemas, SOAP, XSLT, DOM, and
SAX 2.0. Wrox Press 2003.
20. Kim Topley, Java Web Services in Nutshell. O'ReillyPub. Junio 2003.
21. Englander, Robert. Java and SOAP. O'Reilly.
22. St. Laurent, Simon & Johnston, Joe & Dumbil Edd. Programming Web Services with XML-RPC. O'Reilly
Informe de Tesina
Anexos
Anexo A - XML Tags usados para definir un mensaje SOAP
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap,org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
<SOAP-ENV:Body>
<m:GetLastTradePricexmlns:m="Some-URI">
<symbol>DIS</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
Ejemplo:
El cliente necesita saber que producto corresponde con el cdigo ID 827635
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetails xmlns="http://warehouse.example.com/ws">
<productID>827635</productID>
</getProductDetails>
</soap:Body>
</soap:Envelope>
El Servicio Web responde con el siguiente mensaje:
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/">
<soap:Body>
<getProductDetailsResponse xmlns="http://warehouse.example.com/ws">
<getProductDetailsResult>
<productName>Toptimate 3-Piece Set</productName>
<productID>827635</productID>
<description>3-Piece luggage set. Black Polyester.</description>
<price>96.50</price>
<inStock>true</inStock>
</getProductDetailsResult>
</getProductDetailsResponse>
</soap:Body>
</soap:Envelope>
Informe de Tesina
INTRODUCCIN
El Proceso General de Implementacin (PGI) provee un mtodo disciplinado de asignacin de tareas y
responsabilidades aplicable al desarrollo de proyectos de tecnologa de la informacin.
El principal objetivo del PGI es el de asegurar la calidad de la implementacin, cumpliendo con las necesidades y
expectativas del Proyecto, dentro de un calendario y un presupuesto predecibles.
La siguiente figura muestra la arquitectura del proceso:
Relevamiento de Negocio
Reingeniera de Procesos
Requerimientos
Solucin
Implementacin
Migracin e Integracin
Prueba Formal
Puesta en Marcha
Infraestructura
Control de Configuracin
Aseguramiento de Calidad
Iteraciones
Informe de Tesina
IMPLEMENTACIN ITERATIVA
El mtodo iterativo plantea una aproximacin progresiva al resultado final en la concrecin del proyecto, la cual se va
desarrollando por medio de la ejecucin de sucesivas iteraciones, cada una de las cuales va agregando nueva
funcionalidad a la ya disponible, a la vez que produce las mejoras que el Cliente o el Proyecto requiera sobre la
funcionalidad implementada en iteraciones anteriores (aspecto dinmico del proceso).
Dentro de cada iteracin se repite con nfasis variable un ciclo de tareas que se inicia con el relevamiento de los
requerimientos del Cliente, y concluye con la puesta en marcha de una porcin de la Solucin (aspecto esttico del
proceso).
Para permitir este avance gradual, el mtodo prev como cierre de cada iteracin la entrega al Cliente de una versin
utilizable de la Solucin, y fomenta el uso de prototipos a lo largo de la implementacin.
El Cliente comprueba peridicamente la validez de las soluciones planteadas no solo por medio de la revisin de la
documentacin generada, sino tambin a travs de de la utilizacin de las porciones de la Solucin que van siendo
implementadas.
Las principales caractersticas del mtodo son las siguientes:
La Solucin se construye en forma incremental, implementando los requerimientos gradualmente.
Se dispone peridicamente de una versin utilizable de la Solucin.
El equipo de trabajo aprende y mejora su rendimiento a lo largo del proyecto.
El proceso se refina a lo largo del proyecto.
El siguiente diagrama muestra la mecnica del proceso iterativo:
Informe de Tesina
Tareas
I nicio de Fase Verticales
Tareas
Transversales
Fase 1
Fin de Fase
Varias
it eraciones
en cada Fase
Fase n
Fin de Fase
CASOS DE USO
Los Casos de Uso (CU) constituyen una metodologa de anlisis de sistemas utilizada para identificar, clarificar y
organizar requerimientos. Cada CU est compuesto por un conjunto de interacciones entre actores (personas fsicas,
personas jurdicas, aplicaciones, mquinas, etc.) dentro de un entorno especfico, y en relacin a una meta particular.
Objetivo que quiere alcanzar el actor principal.
A su vez, cada CU contiene un escenario principal, y diferentes excepciones derivadas de los pasos del escenario
principal. Por lo tanto, un CU puede ser visto como una coleccin de escenarios.
La vista de escenarios de CU es esencial para la administracin de los requerimientos, especialmente desde el punto
de vista de su priorizacin e implementacin dentro del proyecto.
A su vez los CU son derivados de Historias del usuario (Story Boards) que son el relato lineal de las actividades que
desarrolla o ejecuta un actor en particular. Desde esta perspectiva las historias de los usuarios son casos de uso no
refinados que el analista convierte en caso de uso.
Desde un punto de vista general, un CU o conjunto de CU tiene las siguientes caractersticas:
Permite organizar requerimientos funcionales.
Modela las metas de las interacciones entre los actores.
Registra los escenarios dentro de los que se producen las interacciones entre los actores.
Describe un flujo principal de eventos, y posibles flujos alternativos excepcionales.
Los CU pueden ser utilizados con distintos propsitos: desarrollar los requerimientos de un proyecto de desarrollo o
implementacin de software, validar diseos, efectuar pruebas formales, etc. Una de las ventajas principales de su
utilizacin deriva del hecho de que los CU permiten captar los requerimientos desde el punto de vista del Cliente (o del
usuario) y de las metas perseguidas por el mismo. Los caos de uso se centran en los objetivos que deben alcanzar las
personas dentro de una organizacin y por ende capturan los objetivos organizacionales.
Informe de Tesina
Tener distintos niveles de definicin: informal, descripcin del escenario principal, descripcin de
extensiones.
Pertenecer a distintos tipos: reales o abstractos.
Informe de Tesina
Una vez recopilados los CU del proyecto, los mismos se organizan dentro de grupos de casos de uso, los cuales
agrupan un conjunto de CU relacionados entre si (por ejemplo, por el hecho de pertenecer a un mismo rea del
negocio, o por tener un determinado conjunto de actores en comn).
HITOS
Constituyen los puntos en los que una iteracin finaliza formalmente, e implican (en la casi totalidad de los casos) un
release de la implementacin.
FASES
Desde el punto de vista de la Administracin del Proyecto, el proceso se descompone a lo largo del tiempo en varias
fases secuenciales, cada una de las cuales concluye en un hito principal. Esencialmente, una fase se puede definir
como el perodo de tiempo transcurrido entre dos hitos principales.
Informe de Tesina
Al finalizar cada fase se realiza una evaluacin para determinar si se han alcanzado los objetivos de la misma. Si el
resultado de la evaluacin es satisfactorio, el proyecto avanza hacia la prxima fase.
Tal como puede apreciarse en el Diagrama de Visin General, las fases son dismiles entre si en cuanto a esfuerzo y
planificacin.
ITERACIONES
Una iteracin puede ser vista como un mini-proyecto dentro del proyecto general, dentro del cual se ejecutan (con un
nfasis que vara de acuerdo al grado de avance del proyecto) todas las tareas que componen el PGI, resultando en la
gran mayora de los casos en una implementacin completamente funcional (aunque parcial) de la Solucin General.
Cada iteracin comienza con una planificacin de las actividades, y culmina con un release de la implementacin, el
cual puede o no ser puesto en produccin.
ROLES
Un rol define el comportamiento y las responsabilidades de un individuo o un grupo de individuos que trabajan
conjuntamente dentro del contexto del equipo de trabajo que realiza la implementacin.
Cada rol tiene un conjunto cohesivo de actividades asignadas. Estas actividades se relacionan entre si, estn acopladas
funcionalmente, y se desarrollan ms eficientemente si son realizadas por un mismo individuo.
Asimismo, cada rol es responsable de la generacin de un determinado conjunto de artefactos.
Se debe notar que un rol no equivale a un individuo. La asignacin entre individuos y roles, se efecta durante el inicio
del proyecto, y puede implicar que un mismo individuo desempee varios roles simultneamente, y/o que un mismo
rol sea desempeado por varios individuos simultneamente.
ACTIVIDADES
Cada actividad representa una unidad de trabajo cuya realizacin le puede ser solicitada a cualquier individuo que
desempee el rol al cual est asignada la actividad. La actividad debe tener un propsito bien definido, usualmente
expresado en trminos de la creacin o la actualizacin de determinados artefactos. La granularidad de cada actividad
debe ser tal que permita que la misma sea utilizada como un elemento significativo de planificacin y evaluacin del
progreso del proyecto.
Los roles tienen asignadas actividades, las cuales definen el trabajo que deben desarrollar. Una actividad es algo que
realiza un rol, que tiene un resultado significativo dentro del contexto del proyecto.
Las actividades pueden ser repetidas varias veces a lo largo del proyecto, especialmente dentro de distintas
iteraciones, refinando y expandiendo progresivamente el alcance de los artefactos resultantes de la misma, siempre
bajo la responsabilidad del mismo rol (pero no necesariamente del mismo individuo).
Las actividades se descomponen en pasos, los cuales pueden pertenecer a tres categoras:
Pasos de elaboracin, en los cuales se comprende la naturaleza de la tarea, se recopilan y examinan los
artefactos a utilizar, y se formula el resultado.
Pasos de desarrollo, en los cuales se crea o actualiza el contenido de los artefactos implicados.
Pasos de revisin, en los cuales se compara el resultado obtenido contra un criterio determinado.
Se debe tener en cuenta que no todos los pasos son necesariamente desarrollados cada vez que se realiza la
actividad.
ARTEFACTOS
Los artefactos representan productos finales o intermedios resultantes del desarrollo de las actividades del proyecto.
Se utilizan para capturar y comunicar informacin entre todos los individuos que participan del mismo.
Informe de Tesina
Los roles utilizan los artefactos para desarrollar las actividades previstas en el proceso, y producen o actualizan
artefactos como resultado del desarrollo de dichas actividades. Los artefactos son responsabilidad de un nico rol, de
manera de promover la idea de que cada elemento del proceso deba ser responsabilidad de una persona especfica. Si
bien una nica persona es la duea del artefacto, el mismo puede ser utilizado por muchas otras personas, incluso
produciendo actualizaciones al mismo.
Cada actividad tiene un conjunto de artefactos de entrada y otro de salida.
Los artefactos deben estar sujetos a la administracin de configuraciones, y por lo tanto, debe existir un mecanismo
de versiones de los mismos.
Cada artefacto tiene asociada una plantilla, la cual establece el modelo o prototipo del artefacto, y permite lograr una
estandarizacin del contenido del mismo a lo largo del proyecto, sin importar cules fueron las personas que
intervinieron en el desarrollo del artefacto.
TAREAS
La mera enumeracin de roles, actividades y artefactos no constituye en si un proceso. Para ello, es necesario adems
definir cmo se conjugan entre si todos estos elementos, especificando secuencias significativas de actividades que
produzcan un resultado evaluable, y definir cmo interactan entre si los distintos roles.
Las definiciones precedentes se agrupan dentro de tareas, segn un determinado criterio. De esta manera, una tarea
es una coleccin de actividades relacionadas entre si, que pertenecen a un mismo rea de inters dentro del
proyecto general.
Cada tarea es representada dentro de un diagrama que muestra una secuencia semi-ordenada de actividades que
deben ser realizadas para alcanzar cierto resultado. El trmino semi-ordenada enfatiza el hecho de que las tareas no
representan la planificacin del trabajo real a desarrollar, ya que no describen la opcionalidad de las actividades, ni la
naturaleza iterativa de los proyectos. Sin embargo, esta forma de organizar las actividades permite facilitar el
entendimiento del proceso, subdividindolo en partes ms pequeas que el todo.
A continuacin se muestra un ejemplo de diagrama de tarea:
Para cada tarea, el proceso incluye un diagrama de detalle de la misma, en el cual se muestra el conjunto concreto de
actividades a desarrollar dentro de la tarea, los roles responsables de cada una de dichas actividades, los artefactos
que se deben utilizar para el desarrollo de dichas actividades, y los artefactos resultado del desarrollo de dichas
actividades.
Lanzamiento del
Proyecto
(Iteraciones subsecuentes)
Evaluar alcance y
riesgos del Proyecto
Planificar Iteracin
Desarrollar Plan
Monitorear y Controlar
General del Proyecto
el Proyecto
Administrar Iteracin
(Cierre de Proyecto)
(Cierre de Fase)
(Cierre de Iteracin)
Cerrar Fase
Cerrar Proyecto
Evaluar alcance y
riesgos del Proyecto
Informe de Tesina
El sentido de los diagramas de detalle de las tareas es el de hacer evidente que las actividades de una tarea no se
realizan secuencialmente, ni se realizan todas simultneamente. El diagrama de detalle muestra en qu casos es
recomendable trabajar por medio de talleres o reuniones de equipo en el transcurso del desarrollo de una tarea.
Tpicamente se trabaja en paralelo en ms de una actividad, y al hacerlo se tiene en cuenta ms de un artefacto.
El PGI presupone que como parte del proceso del estudio de factibilidad, se ha efectuado en forma conjunta con el
Cliente una fase durante la cual se realiza un diagnstico de la situacin y un relevamiento inicial del negocio
desarrollado por el Cliente.
Esta fase previa se denomina anlisis de alcance. El mismo se ejecuta en forma previa al inicio del proyecto, y no
forma parte del mismo.
El anlisis de alcance se realiza en base a un modelo de encuesta que permite evaluar la situacin del Cliente, y tiene
una importancia fundamental y un impacto directo sobre el proyecto, ya que como resultado del mismo se debe estar
en condiciones de efectuar las estimaciones iniciales sobre el volumen y la complejidad del proyecto.
Las estimaciones iniciales se efectan sobre el alcance marco enunciado como resultado del anlisis de alcance.
Como mnimo, el alcance marco debe constar de:
Una enumeracin de los componentes de la Solucin definidos por el Cliente, y el propsito con el cual han sido
incluidos en el proyecto.
Una matriz de objetivos macro o de nivel cero, la cual debe contener dentro de lo posible, la versin informal
de los casos de uso relacionados con dichos objetivos.
El resultado del diagnstico efectuado se debe tomar como un pre-anlisis de factibilidad, y debe garantizar que no
surjan imprevistos considerables una vez iniciado el proyecto.
Una vez efectuado el anlisis de alcance, nada de lo que se incluya posteriormente en el proyecto debe superar el
alcance marco inicial. El surgimiento de objetivos de negocio o casos de uso adicionales, no incluidos en forma
original, debe implicar una contratacin adicional por parte del Cliente, a travs de ampliaciones al proyecto primitivo.
Adicionalmente, el anlisis de alcance debe incluir tambin un detalle de los recursos que el Cliente se compromete a
aportar al proyecto, discriminados segn los roles previstos por el PGI, y detallando las capacidades de cada recurso
comprometido.
PLANIFICACIN
La Administracin del Proyecto se efecta basndose en dos artefactos fundamentales:
Plan General
Este artefacto se crea durante la Fase de Lanzamiento.
Detalla los hitos que determinan la finalizacin de cada una de las iteraciones.
Plan de Iteracin
Cada vez que se inicia una nueva iteracin se crea una nueva instancia de este artefacto.
Informe de Tesina
Por lo tanto, existe un ejemplar del mismo por cada iteracin ejecutada.
Tiene como objetivo la produccin de una nueva versin de la Solucin que est siendo implementada, y de
los artefactos producidos durante el proceso.
En general, todas las tareas del proyecto (ver Tareas del PGI), se ejecutan en todas las iteraciones (salvo mnimas
excepciones).
Los planes utilizados para la Administracin del Proyecto establecen las polticas a utilizar para las distintas actividades
del proyecto; son artefactos mayormente estticos, en el sentido que se formulan tempranamente y luego sufren
ajustes mnimos.
Importante:
La puesta en prctica de las polticas establecidas en los planes implica la generacin de artefactos que registren el
aspecto dinmico de dichas polticas, es decir, la instanciacin de ciertos aspectos establecidos en los planes.
Supongamos, por ejemplo, que el Plan de Aseguramiento de la Calidad establece que debern calcularse ciertas
mtricas, y utilizarse ciertos criterios para evaluar la satisfaccin del cliente. Estas polticas deben luego concretarse en
determinados artefactos, dentro de los cuales se registrarn los valores reales calculados para las mtricas en cada
hito del proyecto, as como tambin el resultado de la evaluacin de la satisfaccin del cliente, es decir, el grado de
satisfaccin expresado con respecto a los criterios preestablecidos en el plan.
El PGI2 contiene guas y plantillas para facilitar el desarrollo de todos los planes previstos en el proceso, pero salvo
algunas excepciones (Lista de Riesgos, Resultados de Prueba Formal, etc.), no contiene guas y plantillas exhaustivos
para cada uno de los artefactos dinmicos mencionados, quedando los mismos sujetos a lo que se establezca dentro
de cada proyecto.
En resumen: en este sentido, los planes establecen qu se debe hacer, las guas establecen cmo se debe hacer, y la
forma en que se registre el resultado y avance de las actividades se deja librada a la ejecucin de cada proyecto.
ITERACIONES
Acople entre iteraciones
Se debe prever un determinado nivel de interdependencia o acople entre el trabajo desarrollado en dos iteraciones
sucesivas.
Esta relacin se da fundamentalmente entre las tareas de Relevamiento de Negocio y Solucin, por un lado, y las
tareas de Implementacin, Prueba Formal y Puesta en Marcha, por otro.
Para comprender mejor esta situacin, se presenta el siguiente ejemplo:
Extracto del contenido de la Iteracin n:
Informe de Tesina
Etc.
El ejemplo est basado en actividades relacionadas con los CU, pero el mecanismo general es aplicable al resto de los
artefactos del proceso.
Debido a que los roles responsables de las distintas tareas no son los mismos, este tipo de encadenamiento entre
iteraciones permite lograr cierto grado de paralelizacin del trabajo: una parte del equipo se dedica a generar
contenido para la prxima iteracin, mientras otra parte se concentra en el contenido propio de la iteracin en curso.
Por otra parte, el ejemplo presentado permite apreciar los desafos que plantea el mtodo iterativo a la Administracin
de Proyecto, a la Administracin del Cambio (coordinacin con el impacto del cambio en los procesos del Cliente), a la
Administracin del Riesgo, y a la Administracin de Configuraciones (existirn tantas versiones de la implementacin
como iteraciones se efecten).
Cierre de iteraciones
Al finalizar cada iteracin se efecta un cierre formal de la misma, durante el cual se evala el resultado de la
iteracin, determinando:
Si se alcanzaron los objetivos previstos en la planificacin inicial de la iteracin
Si el grado de calidad obtenido es satisfactorio
Si se redujeron o eliminaron los riesgos detectados.
Una vez efectuado el cierre de una iteracin, y como primer paso dentro de la siguiente, se procede a planificar la
nueva iteracin. El resultado de la evaluacin realizada al cierre de la iteracin anterior constituye uno de los
principales elementos utilizados como entrada de la planificacin de la iteracin que se inicia.
Adicionalmente, y de acuerdo al resultado de la evaluacin, puede surgir la necesidad de efectuar ajustes al Plan
General y a la Lista de Riesgos del proyecto.
Estas evaluaciones constituyen una de las ventajas principales del mtodo iterativo, ya que representan una
oportunidad de revisar frecuente y metdicamente el progreso y los riesgos del proyecto, y de tomar las decisiones
necesarias para mantener al mismo dentro de la direccin apropiada.
Informe de Tesina
3 semanas. En un proceso iterativo, esto significa que a lo largo del proyecto habr una nueva versin operable de la
Solucin cada 2 o 3 semanas, independientemente del porcentaje de los requerimientos que cada una de las mismas
cubra.
FASE DE LANZAMIENTO
La Fase de Lanzamiento representa el punto de despegue del proyecto, y tiene como meta fundamental lograr el
consenso de todas las partes interesadas en el proyecto con respecto a los siguientes aspectos:
Propsito y alcance del proyecto.
Riesgos preponderante, hechos relevantes y principales supuestos.
Formacin de comits de trabajo, y establecimientos de roles y responsabilidades.
Compromiso con respecto a las responsabilidades asumidas.
Arquitectura de la Solucin.
Mecanismos de control de calidad a implementar.
Estrategia y metodologa a utilizar.
Por lo general la Fase de Lanzamiento consta de una nica iteracin, la cual constituye la iteracin inicial del proyecto.
Con respecto a la tarea de Puesta en Marcha, independientemente del grado de avance que se logre con el
Relevamiento de Negocio, como resultado de esta primera iteracin se debe obtener mnimamente la instalacin de
todos las herramientas de infraestructura de la Solucin que se requieran usar para poder ejecutar y elaborar todos los
artefactos de la misma. Desde herramientas ofimticas hasta herramientas de anlisis y desarrollo.
Con respecto a la tarea de Administracin de Proyecto, el resultado de esta fase es la versin inicial del Plan General
del proyecto.
Durante el transcurso de esta fase se debe establecer la infraestructura general de soporte del proyecto, en cuanto a
la instalacin del hardware y software necesario para el funcionamiento de la Solucin, la generacin de ambientes de
implementacin, la creacin de instancias de base de datos, y la preparacin de la infraestructura edilicia y de
comunicaciones.
En caso de que se considere necesario, y especialmente si es la primera oportunidad en que el equipo de
implementacin utiliza el PGI, puede incluirse en la Fase de Lanzamiento una breve capacitacin al mismo acerca del
proceso, con el objetivo de que todos los recursos estn alineados desde el punto de vista de la metodologa de
implementacin a utilizar.
FASE DE ELABORACIN
La Fase de Elaboracin tiene como objetivo la recopilacin de la mayor parte de los Casos de Uso a implementar en el
proyecto, y el desarrollo de la mayor parte de la Arquitectura de la Solucin y de los Artefactos que describen la
Solucin. El objetivo en este punto es que durante la siguiente fase del proyecto (Fase de Refinamiento), las
actividades sobre los artefactos mencionados tiendan a concentrarse exclusivamente en el refinamiento de lo
elaborado durante esta fase.
Por lo general la Fase de Elaboracin consta de dos iteraciones, dentro de las que se efecta el desarrollo del 95% de
la Arquitectura de la Solucin y los Casos de Uso a implementar dentro del proyecto.
Informe de Tesina
FASE DE REFINAMIENTO
Durante la Fase de Refinamiento se registra una reduccin significativa en las tareas de Relevamiento de Negocio y
Solucin; las actividades sobre estas reas del proceso se deben concentrar en la depuracin y refinacin de la
Arquitectura de la Solucin y los Casos de Uso recopilados durante la Fase de Elaboracin. El objetivo en este punto es
que durante la siguiente fase del proyecto (Fase de Cierre), la actividad sobre estas reas tienda a ser nula.
Asimismo, esta es la fase del proyecto en la que se efecta el mayor esfuerzo con respecto a las tareas de
Implementacin y Prueba Formal de la implementacin, procedindose a plasmar las soluciones enunciadas en el
Documento de Solucin.
Con respecto a la tarea de Migracin de datos e integracin de aplicaciones, como resultado de la ejecucin de esta
fase se debe finalizar el desarrollo de la migracin de datos. El objetivo en este punto es que finalizada la Fase de
Refinamiento, la nica actividad que quede pendiente en relacin a esta rea sea la ejecucin de la migracin de datos
definitiva (la cual debe realizarse en la ltima iteracin del proyecto, dentro de la Fase de Cierre).
Por lo general la Fase de Refinamiento consta de tres o ocho iteraciones, segn el volumen del proyecto, cada una de
las cuales aporta sucesivamente un mayor grado de refinamiento a la implementacin.
FASE DE CIERRE
Los principales objetivos de la Fase de Cierre son los siguientes:
Cierre de la Arquitectura de la Solucin y del Documento de Solucin.
Migracin de datos definitiva.
Puesta en marcha global.
Desconexin de sistemas legados, si existen.
Es decir que durante el transcurso de esta fase se debe lograr que la implementacin de la Solucin est
completamente disponible para su utilizacin efectiva por parte de los usuarios finales (tanto desde el punto de vista
de la implementacin de la totalidad de los CU recopilados, como desde el punto de vista de la completitud de la
implementacin de cada uno de dichos CU), de manera que se pueda proceder a la desconexin definitiva de los
sistemas legados.
Con respecto a las tareas verticales, al iniciarse esta fase las tareas de Relevamiento de Negocio, Solucin e
Implementacin deben haberse completado casi totalmente, previendo nicamente:
La realizacin de ajustes finales mnimos a la Arquitectura de la Solucin, Casos de Uso y Documento de
Solucin.
La implementacin de los CU definidos durante la iteracin anterior.
La ejecucin de la migracin definitiva de datos (en caso de que la misma sea necesaria).
Por lo tanto, el esfuerzo aplicado dentro de esta fase debe concentrarse mayormente en las tareas de Prueba Formal
(incluyendo una prueba formal global de la implementacin) y Puesta en Marcha.
Al finalizar la Fase de Cierre se deben haber cumplido los objetivos previstos, y el proyecto tiene que estar en
condiciones de ser cerrado.
Por lo general la Fase de Cierre consta de una nica iteracin, la cual constituye la iteracin final del proyecto.
Informe de Tesina
El Comit de Direccin resuelve los conflictos que pudiesen surgir entre las partes
intervinientes en el proyecto, toma las decisiones de alto nivel y es responsable de la
solucin final de implementacin.
Es el responsable de la toma decisiones con respecto a los cambios de alcance que
pudieran surgir a lo largo del proyecto.
Descripcin
Es responsable de la economa global y de garantizar los recursos necesarios para el
correcto desarrollo del proyecto.
El CDI est conformado por Directores y Gerentes de Proyecto, asistidos por los Lderes de
Proyecto. En su integracin participan representantes de todas las organizaciones y reas
que participan del proyecto.
Informe de Tesina
El Consultor Funcional releva y analiza las caractersticas del negocio, desarrolla los casos
Descripcin de uso de negocio, y define cmo se implementar la Solucin para resolver dichos casos
de uso.
Informe de Tesina
El Usuario Clave proporciona los objetivos de negocio que el proyecto debe alcanzar,
describe el funcionamiento del negocio a travs de casos de uso, configura la Solucin,
Descripcin
valida los resultados intermedios del proyecto, y es el responsable de la aprobacin final de
la implementacin.
Subtarea Requerimientos
La tarea de Solucin utiliza los artefactos producidos por esta tarea como base
para el desarrollo del Documento de Solucin.
Relacin con otras La tarea de Prueba Formal utiliza los Casos de Uso producidos por esta tarea para
tareas el desarrollo de los Casos de Test.
La tarea de Administracin de Proyecto utiliza los artefactos producidos por esta
tarea como base para la planificacin de las iteraciones.
Artefactos relacionados
Entrada Salida
Informe de Tesina
Analizar soluciones CF
Artefactos relacionados
Entrada Salida
Plan de la Iteracin Documento de Diseo
Caso de Uso Diagrama de clases
Arquitectura de la Solucin Diagrama de secuencia
Diagrama de actividades
Diagrama de estados
Diagrama de Componentes
Diagrama de distribucin
Tarea Construccin
La tarea de Solucin especifica las soluciones que deben ser efectivizadas por esta
Relacin con otras tarea.
tareas El resultado del desarrollo de esta tarea se valida y verifica dentro de la tarea de
Prueba Formal.
Informe de Tesina
Efectuar configuraciones UC CT
Desarrollar Componentes CT
Desarrollar DB CT
Desarrollar UI CT
Artefactos relacionados
Entrada Salida
Plan de la Iteracin Gua de Implementacin
Documento de Solucin Manual de usuario
Componentes
Interfaces
DB
Informe de Tesina
Artefactos relacionados
Entrada Salida
Plan de la Iteracin Plan de Prueba Formal
Caso de Uso Casos de Test
Arquitectura de la Solucin Resultados de Prueba Formal
Ejecutar paralelo UC / UF CF
Artefactos relacionados
Entrada Salida
Plan de la Iteracin Documento de evaluacin de ejecucin en paralelo
Manual del Usuario
Informe de Tesina
Administrar iteracin LP GP
Artefactos relacionados
Entrada Salida
Caso de Uso Plan General
Arquitectura de la Solucin Plan de Iteracin
Mapa de Integracin Lista de Riesgos
Documento de Aceptacin y Cierre
Informe de Tesina
Artefactos relacionados
Entrada Salida
Plan de la Iteracin Plan de Administracin de Configuracin. CVS
Artefactos relacionados
Entrada Salida
Plan de la Iteracin Plan de Aseguramiento de calidad
Evaluaciones
Mtricas e Indicadores
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
DETALLE DE ITERACIONES
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina
Informe de Tesina