CapíTulo 7

Arquitectura de Integración de Servicios 1

Capítulo 7.

Arquitectura de Integración de
Servicios.

7.1 Revisión ejecutiva.

La Arquitectura de Integración de Servicios define
las aplicaciones de negocios como reutilizables,
componentes fáciles de cambiar en las
funcionalidades del negocio y cómo estos
componentes se interrelacionan. Este es el concepto
de una arquitectura orientada a servicios (SOA).
Mientras SOA ha sido considerado como mejor
práctica en las últimas dos décadas, hasta la
actualidad, muy pocas compañías estaban
interesadas en ella. Ahora, de repente SOA es un
tema de moda en las TI, y al centro de muchas
iniciativas, esperando el incremento de la agilidad
del negocio. En este punto, si su compañía no está
al menos investigando SOA, debería hacerlo.

En una SOA, las discretas funciones o procesos de
negocios son creados como componentes
independientes con interfaces estándar que pueden
ser accedidas por otras aplicaciones, servicios y
procesos de negocios, sin importar la plataforma o
lenguaje de programación. Estos servicios pueden
ser combinados flexiblemente para soportar
diferentes o cambiantes funciones y procesos de
negocio. Soporta la creación de aplicaciones
modulares, las cuales son rápidamente
ensambladas desde servicios nuevos o existentes.

En el pasado, las compañías tenían que apostar en
CORBA, J2EE o .NET para crear SOA. Pero la
mayoría de las grandes compañías utilizan todos
ellos. Los riesgos y costos de estandarizar a uno
sólo, pesaba en los beneficios potenciales de SOA.
Esto conto para el poco porcentaje de adopción.
Integración Empresarial


Pero los servicios Web han alterado significativamente la ecuación de valor de
los SOAs, Los servicios Web son finalmente universalmente el estándar
aceptado porque todos los principales vendedores pueden, en teoría,
soportarla. Trabajan en .NET, J2EE, y CORBA (mientras que todos se apeguen
a la misma versión del estándar). A pesar de que algunas áreas del estándar
siguen inmaduras, los servicios Web y XML han eliminado significativamente
las barreras de riesgo de adoptar SOA, haciendo los beneficios mucho
mayores que los riesgos.

Las aplicaciones de misión críticas actualmente existentes en los mainframes y
otras plataformas, pueden ser empaquetadas en interfaces de servicios Web y
accedidas desde otras aplicaciones o buscadores Web. Esto permite a los
negocios el crear servicios de negocio desde los sistemas existentes, e
implementar e integrar rápidamente nuevas funcionalidades. Con la utilización
de los servicios Web, las compañías pueden comenzar a crear SOAs,
encaminando las inversiones existentes y añadiendo crecientemente nuevas
funcionalidades. SOA es la arquitectura que mejor permitirá la agilidad del
negocio a largo plazo porque soporta la reutilización y el rápido despliegue de
nuevas soluciones.



Historia de las Arquitecturas Orientadas a Servicios.

El concepto de SOA comenzó a principio de los 80s y fue tomada por las
comunidades de redes y programación orientada a objetos. En 1983 el Modelo de
Referencia OSI fue adoptado por la Organización Internacional de Estándares
(ISO) como una referencia común para el desarrollo de estándares de
comunicación de datos. Este define las funciones de comunicación de datos en
siete capas. Cada capa define servicios de comunicación y cada servicio tiene un
intercambio claro y definido con la capa superior e inferior. Este SOA ha pasado la
prueba del tiempo. Mientras la tecnología y capacidades de cada capa han
cambiado automáticamente, la arquitectura en sí se mantiene. Mientras las
interfaces entre servicios continúen igual, los servicios mismos podrán ser
cambiados.
La Fundación de Software Abierto (OSF), el grupo responsable por los
estándares de UNIX, desarrollaron el Ambiente Computacional Distribuido (DCE)
basado en una arquitectura orientada a servicios. La DCE provee una
infraestructura de servicios para computación distribuida, incluyendo la
autentificación de los servicios de seguridad (Kerberos), directorio de servicios,
procedimientos remotos y servicios de archivos y administración.
CORBA es una arquitectura e infraestructura de vendedor independiente
definida por el Object Management Group (OMG) que permite conectar
aplicaciones para que trabajen juntas entre la red, utilizando protocolos de
estándares IIOP. CORBA permite la interoperabilidad entre plataformas. Las
aplicaciones de CORBA son basadas en componentes.
Las tecnologías de componentes más actuales son J2EE y .NET, que son
plataformas basadas en componentes que administran infraestructuras distribuidas
y soportan los servicios Web para permitir aplicaciones de negocios
interoperables. Es actualmente el modelo de componentes más desplegado.
.NET es la implementación de la arquitectura de servicios Web de
Microsoft, la cual permite a las legiones de programadores de Microsoft, crear
servicios Web en los lenguajes de programación con que están más
familiarizados. Esto preserva una gran inversión en el conjunto de habilidades
existentes. Los programadores de J2EE son usualmente más costosos que los
programadores de Microsoft.

7.2 Beneficios de la Arquitectura Orientada a Servicios (SOA).

Permitir agilidad del negocio. SOA es la mejor manera de permitir la
agilidad del negocio. Maximiza el encaminamiento de recursos
existentes mientras minimiza el tiempo y costo de desarrollar nuevas
aplicaciones. En lugar de desarrollar aplicaciones de la nada, las
compañías pueden utilizar las funciones existentes y crear nuevas
soluciones mediante en ensamble de componentes de las aplicaciones
de funcionalidades existentes o nuevas. Esto permite el rápido desarrollo
de nuevas soluciones.



Proveer mayor retorno de inversión. Las compañías que definen
servicios de reutilización en el negocio y crean o empaquetan
funcionalidades de negocios como servicios estándar, maximizarán sus
inversiones de TI mediante la reutilización y encaminamiento de
características existentes.

Permitir agilidad de las TI. Las definiciones de servicios estándar
pueden proveer una capa de abstracción para los servicios del negocio.
Un servicio pude correr y ser accesado desde cualquier lugar. Por lo
tanto las compañías pueden fácilmente cambiar la localización o
tecnología del código resaltado.

Reducir costos de entrenamiento. Los servicios de negocio pueden
ser encapsulados y abstraídos de forma que sean fáciles de utilizar y
ensamblar a componentes de aplicaciones con la mínima programación.
Las compañías pueden utilizar programadores con más habilidades para
crear la funcionalidad resaltada y las definiciones de servicios, lo que
puede ser reutilizado por programadores menos técnicos y aplicaciones
visuales de ensamble.

Reducir el costo de pruebas y corrección de gusanos. Cada servicio
es como una caja negra que realiza una función específica y tiene una
interface publicada que acepta entradas definidas y produce salidas
definidas. Cada servicio puede ser probado individualmente, y luego
reutilizado una y otra vez. Las pruebas de interfaces son muy directas y
pueden ser automatizadas utilizando herramientas de prueba.

Soporte de múltiples tipos de clientes y plataformas. La SOA ofrece
una capa de abstracción de determinadas plataformas. Esto hace
posible tener muchos dispositivos de usuario final, incluyendo
buscadores y dispositivos móviles como celulares, PDAs y otros
dispositivos especializados para utilizar las mimas funcionalidades del
negocio y tienen información comunicada a diferentes dispositivos. Esta
independencia de plataformas provee un gran ahorro para las grandes
compañías que tienen millones de tecnologías en uso.

Rápido tiempo de desarrollo a través de desarrollo paralelo. Los
diferentes programadores pueden trabajar independientemente en
diferentes servicios, porque cada uno de éstos, está contenido en sí
mismo y no depende del estado de otro servicio. Mientras las interfaces
de servicios se encuentren bien definidas desde el principio del proyecto
y lo programadores sepan que esperar de los otros servicios, ellos
pueden fácilmente definir y crear servicios independientemente. Es
comúnmente dicho que pasado un cierto tiempo, el añadir más
programadores al proyecto aumenta el tiempo de desarrollo. Esto no es
verdad con SOA.


Aumento de escalabilidad y disponibilidad. Gracias a que SOA
ofrece transparencia de localización, está el potencial de aumentar
escalabilidad al añadir múltiples instancias de un servicio. La tecnología
de balanceo podría dinámicamente encontrar y enrutar los pedidos de
las instancias de servicios apropiadas. De la misma forma, si hubiera
múltiples instancias de un servicio en la red, y una está disponible, la
transparencia de software puede enrutar el pedido a otra instancia, y con
esto proveer mayor disponibilidad. Esto es más el caso de nuevos
servicios construidos en servicios de aplicaciones, y no funcionalidad de
herencia que ha sido empacada en interfaces de servicios Web.

Lo que hace que SOA sea tan convincente es que puede ser aplicada a grande
y pequeña escala con los mismos beneficios. La Universidad de Texas A&M
fue capaz de demostrar esos principios con el desarrollo de si sistema de
registro de clases en línea, descrito en el Caso de estudio 7.1 (Software AG
n.d.). Esta aplicación fue un pequeño paso en la aplicación de SOA a gran
impacto.

Finalmente, las SOAs se convertirán en la forma en que las organizaciones
construirán sus infraestructuras de TI, porque es la mejor y única forma
comprobada de proveer agilidad a largo plazo. Sin embargo, tomará algún
tiempo e inversión llegar a eso. Hasta la fecha, la mayoría de los enfoques de
las industrias ha sido resolver los problemas considerables de conectividad
técnica. Sin embargo, los grandes esfuerzos de permitir realmente la agilidad
del negocio a través de SOA están en la definición, construcción y
administración de servicios de negocio reutilizables.



Caso 7.1
Mejorando el Servicio a Estudiantes en Texas A&M.

La Universidad de Texas A&M ha sido un líder real en la aplicación
de tecnologías para mantener la misión de la universidad. Como una de las
más grandes instituciones educativas, el mejorar los servicios a los
estudiantes, especialmente durante el registro, continua siendo prioritario.
Una arquitectura orientada a servicios utilizando servicios Web es
bien encajada para mejorar el registro y los servicios de asistencia a los
estudiantes que esperaban más servicios electrónicos y menos tiempo de
esperar en las filas. La decisión fue implementar un servicio en línea. El
departamento de TI desarrolló su sistema de registro de clases utilizando
servicios web y dos personas y fue capaz de entregar un sistema en tres
meses. La mayor parte de los servicios eran provistos por Cobol y
programas Naturales que corrían en el mainframe. Estaban vinculados con
los servicios Web utilizando EntireX Communicator. Estaba estimada que el
uso de este enfoque y tecnología era un ahorro del 50% del tiempo de
desarrollo comparado con esfuerzos previos similares en el departamento.
Durante el registro, miles de estudiantes fueron atendidos simultánea
y eficientemente. El impacto a la universidad fue un mayor nivel de
satisfacción de los estudiantes y una reducción de llamadas telefónicas por
el personal de la Universidad.

7.3 Definición de Servicios. De abajo hacia arriba o de arriba hacia abajo.

Hasta la fecha, la mayoría de los enfoques de SOA y servicios Web han sido
en los detalles tecnológicos de definir las interfaces. Mientras la definición de
estándares de interfaces es el punto crítico que hace posible el sistema, un
enfoque de abajo hacia arriba tiene sus limitaciones. Si el enfoque es
solamente en la especificación de la interfaz, y no en cómo definir que
funcionalidades exponer como servicio, las compañías no arrancaran
completamente los beneficios de la SOA. El incremento de la agilidad del
negocio y disminución de costos dependen de servicios bien definidos, bien
administrados y reutilizables que son más rápida y fácilmente accedidos.
Desafortunadamente no hay teorías matemáticas o metodología que pueda
decir a un desarrollador si e componente o servicio está en el nivel de
granularidad correcto para maximizar su reutilización. El método más
comúnmente utilizado es el de crear servicios de negocios con un enfoque de
prueba y error. Este significa la definición de servicios en el contexto de un
proceso de negocios particular, luego la revisión de reutilización en la siguiente
solución.

Un enfoque de negocios para definir servicios de arriba hacia abajo permitirá a
las compañías satisfacer las necesidades actuales y futuras del negocio.


Comienza con los requerimientos del negocio. Cada servicio deberá proveer la
funcionalidad de satisfacer uno o más requerimientos, y un conjunto de
funcionalidades deben estar cercanamente relacionadas. Esto es llamado
cohesión de funcionalidad. Sin embargo, los servicios deberán estar
ligeramente acoplados. El procesamiento entre un servicio no debe depender
del estado de procesamiento de otro. Un servicio abstrae la funcionalidad de la
tecnología destacada.

En realidad, para realizar el trabajo, los dos métodos don necesarios. El
enfoque de arriba hacia abajo produce un nivel de abstracción necesario para
crear la agilidad del negocio. Sin embargo, en cierto punto el modelo necesita
satisfacer las necesidades de tecnología y los servicios necesarios para
implementar como componentes o colecciones de componentes. Las
compañías continuarán construyendo componentes de abajo hacia arriba para
encapsular los servicios del negocio. La clave es hacer una cohesión de la
funcionalidad de esos componentes para evitar traslape de funcionalidades y
acoplarlos ligeramente para permitir el cambio rápido y maximizar el impacto
del cambio.

7.4 Diseño de Servicios Dirigidos a Eventos

En este capítulo ofrecemos un método dirigido a eventos para definir servicios
de negocios discretos que pueden ser utilizados en base a proyecto o al total
de la empresa. La definición de requerimientos de negocio en términos de
eventos de negocio ofrece un número de ventajas. Primero, la arquitectura de
servicios orientada a eventos provee los sistemas más ágiles. En el ebizQ
webinar, “Creando la Nueva Agilidad Empresarial: Orientado a Servicios y
Dirigido a Eventos” (http://www.ebizq.net/expoq/events/evennt 39.html), Roy
Schulte, VP Gartner declaró que la “agilidad generalmente involucra practicas
de negocios dirigidas a eventos, facilitados por arquitecturas orientadas a
servicios”. El utilizó la analogía se los trenes y camiones para describir la
agilidad de SOA. “Cambiar la dirección de un camión es más fácil que hacer
que el tren vaya donde no hay carriles. Si quieres que el tren se mueva sobre
un pie, tienes que hacer un enorme esfuerzo reconstruyendo y reestructurando
los carriles”, dijo Schulte. “Por otra parte, todo lo que necesitas para cambiar a
un camión más ágil es mover el volante”. SOA es la arquitectura que provee los
volantes para la empresa ágil.

Segundo, los eventos del negocio son una buena forma de diseñar servicios
porque para los usuarios son fáciles de entender, identificar y verificar en un
diseño. Representan las actividades esenciales del negocio. Una de las
mejores formas de asegurar la máxima reutilización de un servicio es tener una
revisión del diseño de la interfaz, para que todos los inversionistas puedan
evaluar si el servicio cumplirá sus necesidades. Este es el proceso utilizado por
OASIS para desarrollar estándares, Cuando las compañías adoptan esta
práctica, los servicios comúnmente satisfacen un mayor rango de necesidades.
Los inversionistas del negocio son más capaces de definir r y verificar los


eventos del negocio y respuestas requeridas por los sistemas, que interfaces
técnicas. Las respuestas de eventos definan los requerimientos para el diseño
de interfaces.

Finalmente, la definición de los eventos del negocio que el sistema capturará y
responderá claramente, define los límites del sistema. Esto es esencial para
asegurar implementaciones rápidas y exitosas. Las respuestas de eventos son
después descompuestas en conjuntos de respuestas de sistemas
funcionalmente cohesionadas. Estas respuestas pueden ser provistas por
sistemas existentes o nuevo desarrollo. El servicio puede ser una interface
integrada a una serie de respuestas entregadas por diferentes sistemas que
necesitan ser coordinados. Un servicio puede proveer por sí mismo diferentes
niveles de abstracción El servicio puede ser una sola función provista por un
componente o aplicación. El enfocarse en eventos del negocio y respuestas
requeridas provee un enfoque orientado a la definición de SOA. Este método
es descrito en la Especificación de Servicios de Integración.

7.5 Especificación de la Arquitectura de Integración de Servicios.

Algunos han llamado a los procesos de crear servicios de negocio reutilizables
algo similar a cocinar waffles. Necesitan tirar el primero y se vuelve mejor con
el tiempo. Mientras es ciertamente un proceso iterativo, esta especificación
provee una guía para crear servicios reutilizables.

7.5.1 Introducción.

Esta especificación de SOA provee la arquitectura y el diseño guía para
aplicar el enfoque se arquitectura orientado a servicios en la integración.
Este documento define los eventos, servicios y componente. Es el
diseño de la arquitectura de especificación para el desarrollo de los
servicios y componentes.

7.5.2 Alcances.

El alcance de esta especificación es definida por el alcance del proyecto.
Documenta la arquitectura y diseño del enfoque de una SOA hacia una
solución de integración. El alcance de esta especificación debe describir
el alcance de la aplicación o sistema que está siendo diseñado.

7.5.3 Participantes clave.

Esta sección debe definir los inversionistas que pueden verificar los
eventos del negocio, servicios e interfaces: el equipo de desarrollo que
ejecutará la implementación del diseño; y el equipo responsable para la
arquitectura y diseño. Cualquier otro participante o inversionista debe ser
identificado, incluyendo sus roles.



7.5.4 Eventos del negocio.

La sección de eventos del negocio define las actividades que el sistema
debe soportar. Un evento del negocio es algo que:

Ocurre en el ambiente del negocio.
Ocurre en un determinado punto en el tiempo.
Debe ser respondido por el sistema.

La tabla de eventos describe las actividades relevantes que suceden en
los negocios y las respuestas de los sistemas requeridas. Hay dos tipos
de eventos: eventos de negocio y eventos temporales. Los eventos del
negocio son actividades dentro del alcance del sistema. Los eventos
temporales suceden en un punto de tiempo predeterminado. Los eventos
temporales existen porque las políticas del negocio demandad que
ciertas actividades del sistema ocurran en cierto tiempo o porque el
sistema produce sus salidas en base a un tiempo. El Caso de estudio
7.2 describe cómo se administraron eficientemente los eventos del
negocio en Delta Airlines puede tener un impacto significativo en su
negocio (Tillett and Schwartz 2001).

Los requerimientos del negocio son definidos en la Declaración de
Propuestas (Capítulo 2). De esa lista, hay que crear una lista de eventos
de negocio dentro del alcance del sistema, y definir las propuestas a
cada evento (ver Figura 7-1). En la columna de Descripción de Eventos
se incluye como el evento es iniciado, o detectado. Cuando se definan
las Respuestas, se deben dar nombres descriptivos que definan no
ambiguamente lo que la respuesta del sistema es, como “Verificación de
cliente existente”, “Alta de Nuevo Cliente”, “Verificación de Crédito”.



Caso 7.2
Delta Airlines. Administración de Eventos del Negocio a través del
Sistema Delta Nervous.

El Sistema Delta Nervous (DNS) representa una inversión de $1
billón, para entregar datos a tiempo a los clientes, empleados y socios. Sin
embargo, no es la entrega de la información, sino el uso de esos datos en
el manojo de los eventos del negocio, el mayor beneficio de DNS. Por
ejemplo, una aplicación inicial del sistema es requerida por manejadores
de equipaje y asegura que tengan una imagen precisa de los cambios de
sala y retrasos de vuelos para que puedan planear el movimiento del
equipaje arriba y debajo de los aviones. El cambio del estatus de un vuelo
es un evento del negocio que repercute a través de todo el sistema de la
aerolínea. Cuando un evento ocurre, el cambio en el estatus puede ser
actuado si se le provee a los participantes claves del evento la información
y servicios para reaccionar ante esos cambios.
El DNS está cambiando a Delta en una empresa de tiempo real
con la habilidad de servir mejor a los clientes. Además, también implica
una enorme generación de ingreso y disminución de costos. Por ejemplo,
tener información en tiempo real permite a Delta aumentar el número de
vuelos diarios moviendo a los aviones adentro y afuera más rápido. El
tiempo de la tripulación ociosa en tierra puede ser reducido a través de
mejor planeación. Los costos asociados con el mal manejo del equipaje
pueden ser eliminados.
Mientras el enfoque es en hacer la información disponible, el valor
estará en la identificación de eventos significativos y tomar acciones
apropiadas como resultado de esos eventos. No es necesario para un
negocio crear una nueva fuente de información. En vez de eso, es
importante crear una arquitectura capaz de actuar en eventos del negocio
y hacer que fluyan eficientemente a través del sistema como servicio.
Delta ha puesto este sistema a andar con su DNS,



7.5.5 Servicios.

Las respuestas del sistema definidas en la Tabla de Eventos son
utilizadas para determinar los servicios esenciales que debe proveer el
sistema. Algunos de estos servicios o funciones ya existen en otros
sistemas, y otras funcionalidades serán nuevas y deberán ser
desarrolladas e integradas. Las descripciones del servicio definen el
alcance de la funcionalidad requerida para realizar un servicio de
negocio específico.

Para maximizar la agilidad del negocio y las inversiones de TI, los
servicios de negocio deberán ser definidos al nivel de granularidad que



optimice su reutilización. Una cohesión que agrupe las funciones
cercanamente relacionadas en los servicios del negocio y acople
ligeramente los servicios, son las métricas de diseño que llevarán a un
diseño más reutilizable.

Tres partes de la especificación definen completamente cada servicio: la
Tabla de Categoría de Servicios, la Tabla de Definición de Servicios y la
Tabla de Interfaz de Servicios.

Este nivel de descripción es suficiente para desarrollar un nuevo servicio
Web o empacar las funcionalidades existentes como servicio de negocio.

Tabla de Categoría de Servicios

La Tabla de Categoría de Servicios enlista tolas las respuestas
requeridas ante eventos del negocio, y define si la funcionalidad ya
existe en uno o más sistemas o si es una nueva. El servicio en este
punto es una suposición primaria de la definición de los servicios y será
redefinida ampliamente en el siguiente paso. Cuando se definen los
servicios, se debe pensar en módulos dentro de una aplicación que
puedan realizar el servicio o componentes de módulos para desarrollo
(ver Figura 7-2).



Tabla de Definición de Servicios

La Tabla de Definición de Servicios describe completamente cada
servicio en un nivel suficiente para crear servicios Web u otras interfaces
de integración. Cada servicio deberá ser descrito en términos de su
funcionalidad y sistemas utilizados para crearlo. Al crear esta tabla, se
deben agrupar todas las funcionalidades y respuestas para formar un
módulo cohesionado. Por ejemplo, el servició deberá administrar un
conjunto de datos particular, como información del cliente o información
del producto, o deberá realizar un servicio especifico que puede ser
utilizado en otras aplicaciones, como revisión de crédito o precios. Debe
haber un ligero acoplamiento entre los servicios. Cada servicio deberá
interactuar con cualquier otro servicio a través de la interfaz definida. Los
cambios en alguno de los servicios no deberán impactar la funcionalidad
de los otros.

La descripción define cómo el servicio será implementado, como servicio
Web, adaptador de aplicación o interfaz de módulo de aplicación (Figura
7-3). Este es el lugar en la especificación que proporciona un diseño
completo al nivel de especificación de tecnología.



Tabla de interfaz de Servicios

Mientas los estándares de Servicios Web definen cómo especificar una
interfaz, no definen los datos y funcionalidades que la interfaz necesita
contener. La Especificación de Servicios de Interfaz provee la
información necesaria para crear servicios web u otras aplicaciones o
componentes de interfaces. Utilizar la Tabla de Definición de Servicios,
enlista las entradas, salidas y métodos que la interfaz necesita soportar,
y determina cómo ésta será implementada (Figura 7-4).


La meta de definir interfaces estándar es maximizar la agilidad del
negocio. Las interfaces estandarizadas, permiten construir a las
aplicaciones y servicios en diferentes plataformas con diferentes
lenguajes y tecnología para interoperar. Permiten también a los servicios
el cambiar la funcionalidad interna y reglas o resaltar tecnología sin
impactar a otras aplicaciones o componentes, mientras la interfaz
continúe igual. Por lo tanto, el tener una buena interfaz es necesario
para maximizar la reutilización y agilidad. Es recomendado que las
compañías sigan las mejores prácticas de los comités de estándares
cuando definan sus interfaces, teniendo revisiones de diseño que
incluyan a los inversionistas. También es recomendado que se cree un
glosario de terminología que es significativa y consistente a través de los
inversionistas. El propósito de la Especificación de la Interfaz, es permitir
estas revisiones de diseño y describir por completo la interfaz para que
pueda ser correctamente y óptimamente implementada.

7.5.6 Diagrama de Caso de Uso y Especificación.

Un diagrama de caso de uso puede ser utilizado para mostrar las
relaciones entre usuarios, eventos y servicios. Es la pieza final del
rompecabezas para la especificación e integra toda la información de las
secciones anteriores.

Los casos de uso definen a los actores y cómo van a interactuar con los
servicios del sistema. Los actores representan un papel, y pueden ser
humanos, otras computadoras o piezas de hardware, e incluso otros
sistemas de software. Estos deben dar estímulos o iniciar el evento en
turno que requiere una respuesta del sistema o servicio. Los casos de
uso describen el comportamiento del sistema cuando uno de estos



actores envía un estimulo particular y muestra los eventos del negocio y
respuestas de los sistemas en términos de estímulos de eventos que
llevan al caso de uso, las entradas de y las salidas a otros actores, y el
comportamiento que convierte las entradas en salidas.

Los componentes básicos de un diagrama de caso de uso son el actor,
el caso de uso y la asociación (ver Figura 7-5), Un actor es mostrado
utilizando una figura de palitos y el rol del usuario es escrito debajo del
icono. Los actores pueden ser humanos, otras computadoras, piezas de
hardware e incluso otros sistemas de software. Un caso de uso es
mostrado con una elipse, y el nombre es escrito adentro. Las
asociaciones son líneas entre actores y casos de uso, y ésto indica que
un actor participa en el caso de uso.

Para soportar el análisis de los requerimientos no funcionales (ej.
Confiabilidad, mantenimiento y funcionamiento), se utilizan casos de uso
que deben ser creados para soportar los escenarios en que éstos
requerimientos no funcionales serán probados. Algunos ejemplos
incluyen: 1) creación de un caso de uso que pruebe el funcionamiento
entre interfaces de componentes distribuidos, y 2) creación de casos de
uso que prueben la adaptabilidad de un componente mediante la
extenderlo (añadir clases) o examinarlo para definir si mantiene los
principios de diseño arquitectónico. Estos casos de uso a nivel de
sistema pueden ser implementados en un estilo de hacerlo solos donde
una parte de la arquitectura está siendo probada independientemente
del dominio de funcionalidad que necesitará soportar.

Para crear los casos de uso, primero se deben identificar a los actores
primarios del sistema. Después, priorizar los servicios que serán
implementados. Se recomienda la creación de casos de uso para cada
servicio propuesto. Un ejemplo es la figura 7-6.



La Especificación de Casos de Uso contiene el texto que describe
ampliamente el caso de uso (ver Figura 7-7). La especificación escrita
usualmente describe todo lo que puede ir mal en el curso del
comportamiento de la especificación, y cuál es la acción que el sistema
realizará para remediarlo. Esta especificación puede ser personalizada o
expandida para manejar asuntos particulares en la implementación o la
organización.



7.5.7 Conclusiones y Comentarios.

Esta sección debe incluir cualquier comentario final del sistema, el
diseño o el uso del sistema. Debe incluir también los problemas
conocidos, restricciones o factores extenuantes que contribuyan a las
decisiones o que pueden afectar al sistema en el futuro.

7.6 Mejores Prácticas en la Arquitectura de Integración de Servicios.

Una arquitectura orientada a servicios exitosa permite e las compañías
implementar rápidamente nuevas soluciones de negocio o cambiar las
existentes y puede entregar un ROI sustancial. Sin embargo, SOA no es
necesariamente fácil de lograr. Las siguientes mejores prácticas ayudarán a
obtener los beneficios completos de SOA.

Proveer estructura organizacional y soporte de algo nivel. El éxito
de SOA requiere el compromiso e inversión continuos por parte de la
empresa. SOA no puede ser lograda con un simple proyecto, necesita
contar con un grupo de expertos, como un centro de competencia, que
se enfoquen en la definición, crecimiento y reutilización de SOA. Debe
haber procesos organizacionales y políticas que gobiernan la integración
empresarial. Como la integración cruza barreras organizacionales,
puede causar disputas territoriales. Las compañías necesitan procesos y
políticas para manejar esas disputas (descritos más detalladamente en
la sección 4.4, Estructura Organizacional y Arquitectura de Gobierno).

Implementar arquitectura basada en estándares. Los estándares
ayudan a asegurar tanto la interoperabilidad como la portabilidad.
Previenen el estanque de la tecnología, y ayudan a preservar el valor en
las inversiones de TI. Los estándares de servicios Web están
permitiendo la adopción universal de SOA, a pesar de que ha sido
conocida como la mejor práctica de arquitectura por más de tres
décadas. XML permite a los sistemas estandarizar el formato de
trasporte, administración y almacenamiento para los datos estructurados
y contenido no estructurado en las organizaciones.

Implementar un enfoque basado en estándares. Es recomendable
seguir el ejemplo de los comités de estándares que tienen una larga
experiencia creando procesos que son exitosos en la creación de
estándares interoperables. Realizar revisiones de diseño para las
interfaces de los servicios, e incluir a los inversionistas. Los
inversionistas pueden ser identificados a través de los casos de uso.

Pensar en grande, comenzar en pequeño. Cuando se plañera la
implementación de SOA, se debe considerar un impacto a lo largo de la
empresa para maximizar la reutilización y agilidad. Pero se debe



comenzar con un proyecto que tengo alcance limitado y alta probabilidad
de éxito. Nada es más exitoso que el éxito. Se aprende bastante de
cada implementación, así que hay que esperar a tener varias pequeñas
implementaciones antes de comenzar con los retos más difíciles.

Invertir en entrenamiento. Se tendrá una mayor probabilidad de éxito si
los empleados saben lo que hacen. Pocos diseñadores y programadores
tienen experiencia con SOA construida bajo estándares como servicios
Web y XML. Es todo nuevo para ellos también. Todos los inversionistas,
incluyendo los administradores de TI, arquitectos, diseñadores,
programadores y personal de soporte operativo necesitan entender
todos los conceptos de SOA y cuál será su papel en el proceso. Los
arquitectos y diseñadores necesitan comprender los parámetros del
diseño y las mejores prácticas para crear sistemas ágiles y reutilizables.
Los programadores necesitan comprender las nuevas tecnologías y
cómo implementar la infraestructura de los servicios y componentes. El
personal de soporte operativo necesita comprender las implicaciones de
administrar una SOA distribuida.

Uso de herramientas para ahorrar tiempo y dinero. No se debe tratar
de realizar manualmente todo. Hay una gran variedad de herramientas
disponibles y pueden reducir el tiempo y serie de habilidades requeridas
para implementar la solución. Las ventajas de invertir en herramientas
pesan más que los costos.

El Grupo de Vanguardia es un caso de estudio interesante donde cada una de
las mejores prácticas es llevada a cabo (Caso de estudio 7.3) (Dragoon 2003).



Caso 7.3
La “Brillantemente Simple Solución” del Grupo de Vanguardia.

Se ha descrito como una solución brillantemente simple cuando el
Grupo de Vanguardia tomó una decisión a finales de los 90s para alinear a
los clientes del portal Web con su sistema de servicio a clientes. En
retrospectiva, es sorprendente que más organizaciones no hayan llegado
al a misma conclusión, porque los beneficios parecen aparentes:

La paridad entre los canales de interfaz del cliente en
funcionalidad.
La reducción de la complejidad en el mantenimiento de múltiples
sistemas.
Una arquitectura que puede ser llevada a la reutilización para otros
propósitos.

Los resultados actuales han sido impresionantes. El entrenamiento
de empleados internos fue reducido significativamente, eliminando
virtualmente de 4 a 6 semanas de entrenamiento. El retirar un gran
número de bases de datos y aplicaciones redujo la complejidad de la
arquitectura resaltada. Casi el 10% menos de personal fue requerido para
mantener los sistemas. Los tiempos de respuesta de los usuarios fueron
reducidos del 60% al 70%, incrementando la eficiencia del personal.
Además, la arquitectura soportó el desarrollo de aplicaciones que
mejoraron varios procesos de negocio claves, resultando en
procesamiento de transacciones directas. Los ahorros de éstos cambios
fueron esperados por $30 millones anuales. La inversión para alcanzar
esto fue significativa, pero el ROI esperado es un índice interno de retorno
del 20%.
Mientras las inversiones en arquitectura frecuentemente lanzan
costos que no tienen beneficio aparente, Vanguardia demostró que la
implementación de una arquitectura que soporta la reutilización puede ser
un impacto significativo en el negocio. Una arquitectura orientada a
servicios bien diseñada es la clave de alcanzar estos beneficios. Los
servicios Web no son requeridos, como vemos lo que Vanguardia alcanzó,
pero deberá ayudar a bajar los costos que nacieron en el proyecto
mediante la reducción de la cantidad de trabajo de personalización de la
infraestructura que es provista ahora a través de la tecnología de servicios
Web.

7.7 Siguientes Pasos.

Los servicios están construyendo bloques para aplicaciones modulares e
integración por procesos. Definir servicios empresariales reutilizables, así como



administrar y medir la reutilización, requieren una inversión y compromiso
continuo. EL éxito con SOA es un asunto de administración como lo es de
tecnología. Las compañías interesadas en lograr agilidad del negocio a largo
plazo invertirán en todos los aspectos de la arquitectura de integración
empresarial, incluyendo una arquitectura de integración de información y
procesos (Capítulo 8 y Capítulo 9, respectivamente), Las compañías enfocadas
en resolver necesidades tácticas, definirán solo lo que es absolutamente
necesario para moverse hacia la implementación (Parte III). Ver figura 7-8.


CapíTulo 7

Recomendados

Recomendados

Más contenido relacionado

La actualidad más candente

La actualidad más candente (20)

Destacado

Destacado (8)

Similar a CapíTulo 7

Similar a CapíTulo 7 (20)

CapíTulo 7