1. UNIVERSIDAD VERACRUZANA
FACUltAD DE ADmINIStRACIóN DE EmpRESAS y EmpRESAS tURíStICAS
CARRERA:
l.S.C.A.
tAREA:
CAp. 7; ARqUItECtURA DE INtEgRACIóN DEl SERVICIo
lECtURA 9
FEChA:
21/AbRIl/2009
AlUmNo:
gARCíA CRUZ JoAqUíN
goNZálEZ pItAlUA JUlIáN lUIS
RoDRígUEZ bAltAZAR DAVID ANtóN
CAtEDRátICo:
DR. CARloS ARtURo toRRES gAStElU

2. ARQUITECTURA INTEGRACIÓN DE SERVICIO
Descripción ejecutiva
La arquitectura de la integración del servicio define aplicaciones de negocio como
reutilizables, los componentes fácilmente cambiantes de la funcionalidad del negocio, y cómo
estos componentes se correlacionan. Éste es el concepto de una arquitectura orientada al
servicio (SOA). Mientras que SOA se ha considerado el best practice por más de dos
décadas, hasta hace poco tiempo, muy pocas compañías estaban interesadas en él. Ahora
SOA es un asunto importante en las TI y en muchas iniciativas dirigidas a aumentar la
agilidad del negocio. A este punto, si su compañía por lo menos no está investigando SOA,
debe ser.
En un SOA, las funciones o los procesos discretos del negocio se crean como componentes
independientes con interfaces estándares que pueden ser usadas por otros usos, servicios,
procesos del negocio, sin importar la plataforma o el lenguaje de programación. Estos
servicios se pueden combinar flexiblemente para apoyar procesos o funciones diversas del
negocio. Apoya la creación de aplicaciones compuestas, que se pueden montar rápidamente
de servicios existentes o servicios nuevos.
En el pasado, las compañías tuvieron que apostar el negocio a CORBA, a J2EE, o a .NET
para crear un SOA. Pero la mayoría de las compañías grandes utilizan todo lo antedicho. Los
riesgos y los costes de estandarizar en uno las ventajas potenciales de SOA. Esto explicó la
tarifa baja de la adopción. Pero los servicios de la Web han alterado perceptiblemente la
ecuación del valor de la SOA.
La historia de la arquitectura orientada al servicio
El concepto de SOA comenzó en los años 80 y fue abrazado por el establecimiento de una
red y comunidades de programación orientadas al objeto. En 1983 El modelo de la referencia
de la interconexión de los sistemas abiertos (OSI) fue adoptado por la organización de
estándares internacional (ISO) como referencia común para el desarrollo de los estándares de
la comunicación de datos. Define funciones de las comunicaciones de datos en siete capas.
Cada capa define al servicio de la comunicación, y cada servicio tiene una interfaz bien
definida con la capa sobre y debajo de ella. Este SOA ha pasado la prueba del tiempo.
Mientras que la tecnología y las capacidades en cada capa han cambiado dramáticamente, la
arquitectura sigue siendo la misma. Mientras las interfaces entre los servicios siguen siendo
iguales, los servicios pueden cambiar fácilmente.

3. La fundación abierta del software (OSF), el grupo responsable de los Estándar de UNIX,
desarrollo el ambiente de computadoras distribuido (DCE) basado en una arquitectura
orientada al servicio. El DCE proporciona los servicios de infraestructura para la
computación distribuida, incluyendo la autentificación y los servicios de seguridad
(Kerberos), servicios del directorio, el procedimiento alejado llaman, y servicios de archivo y
de gerencia.
CORBA es una arquitectura y una infraestructura definida por el grupo de gerencia del objeto
(OMG) que permite las aplicaciones de computadoras trabajen juntas en las redes usando el
protocolo estándar IIOP. CORBA permite interoperabilidad a través de plataformas. Las
Aplicaciones de CORBA se basan en los componentes.
Las tecnologías de componentes más actuales son J2EE y .NET. J2EE, es una plataforma
basada en componente que maneja la infraestructura de servicios distribuidos y soporta
servicios de Web que permite aplicaciones de negocios interoperables. Es actualmente el
modelo de componente más extensamente usado.
.NET es una puesta en práctica de Microsoft de una arquitectura de los servicios de Web, la
cuál permite a las legiones de programadores de Microsoft crear servicios de Web en los
lenguajes de programación con los que estén mas familiarizados. Esto preserva una inversión
muy grande en las habilidades existentes. Programadores de J2EE son generalmente más
costosos que los programadores de Microsoft.
Los servicios Web son el primer estándar universal aceptado porque todos los vendedores
importantes pueden, en teoría, apoyarla. Trabajan con .NET, J2EE, y CORBA (mientras cada
uno se pega a la misma versión del estándar). A pesar de que algunas áreas del estándar
siguen siendo no maduras, los servicios del Web y XML han quitado perceptiblemente las
barreras del riesgo para adoptar SOA, haciendo que las ventajas lejanas compensen los
riesgos.
Las aplicaciones críticas existentes actualmente en mainframe y otras plataformas se pueden
integrar en interfaces de los servicios de Web y después acceder desde otras aplicaciones o
buscadores de Web. Esto permite a negocios crear servicios de negocio fuera de sistemas
existentes, y rápidamente implantar e integrar nuevas funcionalidades. Usando servicios del
Web, las compañías pueden comenzar a crear un SOA. SOA es la arquitectura que permitirá
la mejor posible agilidad a largo plazo del negocio porque apoya la reutilización, y el
despliegue rápido de nuevas soluciones.

4. Beneficios de SOA
• Permite la agilidad del negocio. SOA es la mejor manera de permitir agilidad del negocio.
Maximiza los recursos existentes mientras que reduce al mínimo el tiempo y el coste de
desplegar nuevos aplicaciones. Compañías pueden utilizar funcionalidad existente y crear
nuevas soluciones montando los componentes de sus aplicaciones existentes y nuevas. Esto
permite el despliegue rápido de nuevas soluciones.
• Proporciona un regreso en la inversión más alta. Compañías que definen servicios de
negocio reutilizables y crean o envuelven funcionalidad del negocio maximizarán las
inversiones, a través de activos existentes de la reutilización.
• Permite agilidad. Las definiciones estándares de servicio pueden proporcionar una capa de
la abstracción para los servicios de negocio. Un servicio puede funcionar donde quiera y ser
accesado de donde sea. Por lo tanto, una compañía puede cambiar fácilmente la ubicación o
la tecnología del código subyacente.
• Reduce los costes del entrenamiento. Los servicios de negocio pueden ser encapsulados y
ser abstraídos de una manera que los hace fáciles utilizar y montar en componentes de
aplicaciones con la programación mínima. Las compañías pueden utilizar programadores más
expertos para crear las definiciones subyacentes de la funcionalidad y del servicio, que se
pueden entonces reutilizar por los programadores menos técnicos y las herramientas de
ensamblaje de aplicación visual.
• Reduzca el coste de prueba. Cada servicio es como una caja negra que realiza una función
específica y tiene un interfaz publica que acepta entradas definidas y produce salidas
definidas. Cada servicio se puede probar individualmente, después reutilizar repetidamente
otra vez. La prueba del interfaz es bastante directa, y se puede automatizar usando las
herramientas de prueba.
• Soporte de múltiples tipos de clientes y plataformas. El SOA ofrece una capa de la
abstracción de las plataformas subyacentes. Esto hace posible para los tipos múltiples de
dispositivos del usuario final, incluyendo los browsers y los dispositivos móviles tales como
paginadores, teléfonos, PDAs, y otros dispositivos especializados para utilizar la misma
funcionalidad del negocio y para tener información comunicada a diversos dispositivos.
• Tiempo de desarrollo con el desarrollo paralelo. Diversos programadores pueden trabajar
independientemente en diversos servicios porque cada servicio es autónomo y no dependen
del estado de otro servicio. Mientras los interfaces del servicio estén bien definidos al
principio del proyecto, y los programadores sepan qué esperar de otros servicios, pueden

5. definir y crear fácilmente servicios independientemente. Se solía decir que pasado más allá
de cierto punto si se agregaban más programadores al desarrollo de los proyectos aumentaría
el tiempo de desarrollo. Esto es no más verdad con SOAs.
• Aumento de la escalabilidad y la disponibilidad. Porque SOA ofrece la transparencia de la
localización, hay el potencial de aumentar escalabilidad agregando casos múltiples de un
servicio. La carga balanceada de tecnología encontraría y encaminaría dinámicamente la
petición al caso apropiado del servicio. Asimismo, si hay casos múltiples de un servicio en la
red, y uno llega a estar disponible, el software puede transparentemente encaminar la petición
a otra instancia, de tal modo proporcionando una mejor disponibilidad. Éste es más el caso
para los nuevos servicios construidos en aplicaciones de servicios, y no la funcionalidad de la
herencia que se ha integrado en interfaces de servicios de Web.
Lo Qué hace SOA así es que pueda ser hecho en una escala grande y pequeña con las mismas
ventajas. La universidad de Texas A&M pudo demostrar estos principios en el desarrollo de
su sistema en línea de registro descrito en el caso de el estudio 7.1 (software AG n.d.). Esta
aplicación era un paso pequeño en el uso de SOA con un impacto grande.
SOA se convertirá en la manera que la mayoría de las organizaciones construirán sus
infraestructuras de TI, porque es la mejor y única manera probada que proporciona a largo
plazo agilidad. Sin embargo, tomará cierto tiempo e inversión para conseguirlo. Hasta la
fecha, la mayor parte del foco de la industria ha estado en solucionar los problemas técnicos
considerables de la conectividad. Sin embargo, la verdadera agilidad del negocio con SOA
está en definir, construir, y manejar la reutilización de servicios de negocio.
Caso de estudio
Mejorando el servicio al estudiante en el ASM de Texas
La universidad de Texas A&M ha sido un líder verdadero en el uso de la tecnología para
apoyar la misión de la universidad. Como una de las instituciones educativas más grandes del
mundo, mejorar el servicio a los estudiantes durante el registro es prioritario.
Una arquitectura orientada al servicio que usa servicios Web está bien adaptada a
proporcionar un registro mejorado a los estudiantes que esperan servicios más electrónicos y
menos tiempo en líneas. Una decisión fue tomada para poner un servicio en ejecución en
línea. El Departamento desarrolló su sistema de clase-registro usando servicios Web. La
mayor parte del servicio fue proporcionado por el COBOL y los programas naturales que
funcionaban en el mainframe. Fueron puestos juntos en la Web con el comunicador de
EntireX. Era estimado que usar este acercamiento y tecnología allí era un ahorro del 50% de
tiempo de desarrollo comparado a los esfuerzos similares anteriores en el departamento.

6. Durante el registro, fueron atendidos millares de estudiantes simultáneamente y
eficientemente. El impacto fue un grado más alto de satisfacción de los estudiantes y de una
reducción significativa en las llamadas telefónicas para el personal de la universidad.
¿Definir el Servicio Fondo Para arriba o de arriba hacia abajo?
Fechar, la mayoría del foco en SOA y servicios de Web ha sido uno de los detalles técnicos
de definir interfaces. Mientras que la definición de interfaz estándar es lo crítico del sistema,
el acercamiento bottom-up tiene sus limitaciones. Si el foco está solamente en la
especificación de interfaz, y no en cómo definir qué funcionalidad exponer como servicio, las
compañías no cosechará las ventajas completas de un SOA. La agilidad creciente del negocio
y los costes disminuidos son dependientes sobre servicios bien definidos, bien-manejados,
reutilizables a los cuales sea rápido y fácil de conectar.
Desafortunadamente, no hay teoría o metodología matemática que puedan decir si el
componente o el servicio están en el nivel correcto del granularidad para maximizar la
reutilización. El método más común de uso general de crear servicios de negocio es el
acercamiento del ensayo-y-error. Esto significa generalmente definir servicios en el contexto
de un proceso particular del negocio, y después revisándolos para la reutilización en la
siguiente solución.
Un acercamiento de arriba hacia abajo del negocio para definir servicios permitirá a las
compañías conocer mejor las necesidades actuales y futuras del negocio. Comienza con los
requisitos del negocio. Cada servicio debe proporcionar la funcionalidad para resolver uno o
más requisitos del negocio, y el sistema de funciones debe ser relacionado de cerca. Esto se
llama cohesión funcional. Sin embargo, los servicios deben ser juntados libremente. El
proceso dentro de un servicio no debe ser dependiente sobre el estado del proceso en otro. Un
servicio abstrae la funcionalidad de la tecnología subyacente.
En verdad, conseguir el trabajo hecho, los métodos bottom-up y de arriba hacia abajo son
necesarios. El acercamiento de arriba hacia abajo rinde un nivel de la abstracción que es
necesaria para crear agilidad en el negocio. Sin embargo, en un cierto punto el modelo
necesita conocer la tecnología, y los servicios necesitan ser puestos en ejecución como
componentes o colecciones de componentes. Las compañías continuarán construyendo
componentes del bottom-up para encapsular servicios de negocio. La clave es hacer estos
componentes funcionalmente cohesivos para evitar traslapar funcionalidad y débilmente
acoplado para permitir el cambio rápido y para reducir al mínimo el impacto del cambio.

7. Diseño de servicio Event-Driven
En este capítulo ofrecemos un método event-driven de arriba hacia abajo para definir los
servicios de negocio discretos que se pueden utilizar en un proyecto o una base de la
empresa. Definir requisitos del negocio en términos de acontecimientos del negocio ofrece un
número de ventajas. Primero, las arquitecturas orientadas al servicio event-driven
proporcionan sistemas más ágiles. En el ebizQ webinar, “creando la nueva agilidad de la
empresa: Service oriented y Event-Driven quot;
(http://www.ebizq.net/expoq/events/event39.html), Roy Schulte, VP Gartner, indica, “la
agilidad implica generalmente las prácticas de negocio event-driven, facilitadas por
arquitecturas orientadas al servicios. Él utilizó la analogía de trenes y de carros para describir
la agilidad de SOA. “Cambiar la dirección de un carro es más fácil que la de un tren vaya a
adonde no lo hacen las pistas. Si usted quisiera que el tren se moviera sobre un pie, usted
tiene que hacer una cantidad inmensa de trabajo para redireccionarlo, Schulte dijo. “Por otra
parte, todo lo que usted necesita hacer para dar vuelta al carro más ágil es un movimiento de
la rueda de manejo. “SOA es la arquitectura que proporciona las ruedas para la empresa ágil.
En segundo lugar, los acontecimientos del negocio son una buena manera de diseñar
servicios porque son fáciles para que los usuarios del negocio entiendan, identifiquen, y los
verifiquen en un diseño. Representan las actividades esenciales del negocio. Una de las
mejores maneras de asegurar la reutilización máxima de un servicio es tener una revisión del
diseño del interfaz, así que todos pueden evaluar si el servicio resolverá sus necesidades. Éste
es el proceso usado por OASIS para desarrollar estándares. Cuando las compañías adoptan
esta práctica, los servicios pueden resolver una gama más amplia de necesidades. Los
tenedores de apuestas del negocio son mejores para definir y verificar acontecimientos del
negocio y respuestas de sistema requeridas, que las interfaces técnicas. Las respuestas del
acontecimiento definen los requisitos para el diseño del interfaz.
Finalmente, definiendo los acontecimientos del negocio el sistema se capturara y responderá
a definir claramente los límites del sistema. Esto es esencial para asegurar puestas en
prácticas acertadas y rápidas. Las respuestas del acontecimiento se descomponen más a fondo
en los sistemas de respuestas de sistema funcionalmente cohesivas. Estas respuestas pueden
ser provistas saliendo de sistemas o del nuevo desarrollo. El servicio puede ser una interfaz
integrada a un sistema de respuestas provistas por diversos sistemas que necesiten ser
coordinados. Un servicio proporciona diversos niveles de abstracción. El servicio puede
también ser una sola función proporcionada por un componente o una aplicación. El centrarse
en acontecimientos del negocio y respuestas requeridas proporciona un acercamiento
comercial para definir el SOA. Este método se describe en la.

8. Especificación de la arquitectura de integración del servicio
Algunos han llamado al proceso de crear servicios de negocio reutilizables similar a cocinar
las galletas.. Mientras que es ciertamente un proceso iterativo, esta especificación
proporcionará las pautas para crear servicios reutilizables.
Introducción
Esta especificación de SOA proporciona la dirección de la arquitectura y del diseño para
aplicar un acercamiento a la arquitectura orientada al servicio. Este documento define los
acontecimientos, los servicios, y los componentes. Es la especificación del diseño y de la
arquitectura para el desarrollo de los servicios y de los componentes.
Alcance
El alcance de esta especificación es definido por el alcance del proyecto. Documenta la
arquitectura y el diseño para un acercamiento de SOA a una solución integrada. El alcance de
esta especificación debe describir el alcance del uso o del sistema que se está diseñando.
Participantes dominantes
Esta sección debe definir a los tenedores de apuestas que pueden verificar los
acontecimientos, los servicios, y las interfaces del negocio; el equipo del desarrollo que
ejecutará la puesta en práctica del diseño; y el equipo responsable de la arquitectura y del
diseño. Cualesquiera otros participantes o tenedor de apuestas deben también ser
identificados, incluyendo sus papeles.
Acontecimientos del negocio
La sección de los acontecimientos del negocio define las actividades económicas que el
sistema debe apoyar. Un acontecimiento del negocio es algo que
• Ocurre en el ambiente de negocio
• Ocurre en un punto dado a tiempo
• Debe ser respondido por al sistema
Hay dos tipos de acontecimientos: acontecimientos del negocio y acontecimientos
temporales. Los acontecimientos del negocio son las actividades que ocurren en el negocio, y
son detectados definiendo cada actividad económica dentro del alcance del sistema. Los
acontecimientos temporales ocurren en un punto predeterminado a tiempo. Los
acontecimientos temporales existen porque la política de negocio exige que ocurran ciertas
actividades del sistema a veces, o porque el sistema produce sus salidas sobre una base

9. sincronizada. El estudio de caso 7.2 describe cómo los acontecimientos de manejo del
negocio más eficientemente en Delta Airlines pueden tener impacto significativo en su
negocio (Tillett y Schwartz 2001).
Los requisitos del negocio se definen en la declaración del propósito. De esa lista, cree una
lista de los acontecimientos del negocio dentro del alcance del sistema, y defina las
respuestas a cada acontecimiento.
Caso de estudio
Acontecimientos de Línea-Manejo del negocio del delta
A través del sistema nervioso del delta
El sistema nervioso del delta (DNS) representa una inversión de $1 mil millones “entregar
datos oportunos a los clientes, a los empleados, y a los socios. “Sin embargo, no es la entrega
de la información, sino el uso de los datos en la manipulación de acontecimientos del negocio
que es la ventaja principal del DNS. Por ejemplo, un uso inicial del sistema es tratantes
dirigidos del bagaje y asegurarse de que tienen un cuadro exacto de los cambios de la puerta
y el vuelo retrasa así que pueden mejorar plan el movimiento de los planos del equipaje por
intervalos. El cambio en estado de un vuelo es un acontecimiento del negocio que tiene
repercusiones a través del sistema de la línea aérea. Siempre que ocurra un acontecimiento, el
cambio en estado puede ser actuado sobre proveyendo de los participantes dominantes de ese
acontecimiento la información y servicios para reaccionar a estos cambios.
El DNS está dando vuelta a delta en una empresa en tiempo real con la capacidad de mejorar
servicio sus clientes. Sin embargo, también tiene la rédito-generación enorme e implicaciones
cost-saving. Por ejemplo, tener información en tiempo real permite que el delta aumente el
número de vuelos por día moviendo los planos adentro y hacia fuera más rápidamente. En
horas extras de equipos de tierra ociosos puede ser reducido con un planeamiento mejor. Los
costes asociados a manejar mal de bolsos pueden ser eliminados.
Mientras que el foco está en la fabricación de la información disponible, el valor consistirá en
identificar acontecimientos significativos y después tomar la acción apropiada como
resultado de los acontecimientos. No es necesario que un negocio cree una nueva fuente de la
información. Algo, es importante crear una arquitectura que pueda actuar sobre
acontecimientos del negocio y fluir ésos a través del sistema eficientemente como servicio. El
delta ha puesto tal sistema en lugar con su DNS.

10. Servicios
Las respuestas del sistema definidas en la tabla de eventos se utilizan para determinar los
servicios esenciales que debe proporcionar el sistema. Algunos de esos servicios o funciones
ya existen en otros sistemas, y otras funciones serán nuevas y deben ser desarrollados, a
continuación, se ha integrado. Las descripciones de servicio de definen el alcance de la
funcionalidad necesaria para realizar un servicio específico de negocio.
para maximizar la agilidad empresarial y de las inversiones de TI, los servicios de negocio
deben estar definidos en los niveles de granularidad que optimizaran la reutilización.
Haciendo cohesión cerca de la agrupación de funciones junto a los servicios de negocio y
relacionados conciertos acoplamiento entre los servicios que son la métrica de diseño que
producirá más diseños reutilizables.

11. Tabla de la categoría de servicios
El Tabla de la categoría de servicios muestra que todo requiere respuestas a eventos
comerciales, y define si la función que ya existe en uno o más sistemas, o si es una nueva
funcionalidad. La tabla también define servicios probables para proporcionar la
funcionalidad. El servicio en este momento es una mejor apuesta en un servicio y será más
refinado en el siguiente paso. Al definir servicios, pensando en módulos de una aplicación
existente que puede llevar a cabo el servicio o componente probablemente módulos para el
desarrollo.
Tabla de Definición de servicio
La Tabla de definición de servicios plenamente describe cada servicio a un nivel suficiente
para crear servicios Web o de otras interfaces de integración. Cada servicio debe ser descrito
en términos de sus funciones y los sistemas utilizados para crear el servicio. Creando esta
tabla, se agruparan todas las funciones y respuestas que juntas formarán un módulo
cohesivo. Por ejemplo, el servicio debe administrar un conjunto particular de datos, como
información del cliente, o información sobre el producto, o debe realizar un servicio
específico que podría utilizarse en otras aplicaciones, tales como la comprobación de crédito
o los precios. Debería haber sueltos de acoplamiento entre los servicios. Cada servicio debe
interactuar con cualquier otro servicio a través de la interfaz definida. Los cambios en un
servicio no deberían afectar funcionamiento de otros servicios.
La descripción define cómo el servicio será implementado, tales como el servicio Web,
adaptador de aplicación
o módulo de aplicación
interfaz. Este es el lugar
en la especificación que
lleva el diseño de arriba
hacia abajo a nivel del
especificación de
tecnología.

12. Tabla de la categoría de servicios
Tabla de Definición de servicio
Tabla de Interfaz
Tiempo estándar de servicios Web define cómo especificar una interfaz, no definir los datos y
la funcionalidad que debe contener la interfaz. la Especificación de interfaz de servicio
proporciona la información necesaria para crear Web servicios u otra aplicación o
componente interfaces. Utilizar la Tabla servicio de definición, enumere todos los insumos,

13. productos y métodos que la interfaz necesita apoyo y determinar cómo será la interfaz
aplicada.
Interfaz de servicio Tabla
El objetivo de definir las interfaces estándar es maximizar la agilidad empresarial. Permite
que la interfaz estándar de las aplicaciones y servicios construidas sobre plataformas
diferentes con diferentes idiomas y la tecnología interoperen. Permite a servicios cambiar la
funcionalidad interna y normas o subyacentes tecnología sin afectar a otras aplicaciones o
componentes, como interfaz sigue siendo el mismo. Por lo tanto, acertar la interfaz es
esencial para maximizar la reutilización y agilidad. Se recomienda a las empresas siguen
mejores prácticas de los comités de las normas que al definir interfaces tengan revisiones de
diseño que incluyan a todas las partes interesadas. También se recomienda crear un glosario
de terminología que sea significativo y coherente a través de todas las partes interesadas. El
propósito de la especificación de interfaz es permitir la revisión de diseño para describir
plenamente la interfaz de tal manera que puede aplicarse correctamente y de forma óptima.

14. Utilizar el diagrama de caso y especificaciones
Un Diagrama de casos de uso puede utilizarse para describir las relaciones entre los usuarios,
eventos, y servicios. Es la pieza final del rompecabezas para la especificación. Se integra toda
la información de las secciones anteriores.
Los Casos de uso definen los actores y cómo interactúan con los servicios del sistema.
Actores representan un papel y puede ser los seres humanos, otros equipos, piezas de
hardware o incluso de otros sistemas de software. Debe proporcionar estímulos para iniciar el
evento que a su vez requiere una respuesta del sistema (o el servicio). Casos de uso describen
el comportamiento del sistema cuando uno de estos actores envía un estímulo particular.
Describe los eventos de negocios y el sistema las respuestas en términos del estímulo del
evento que desencadena el caso de uso, las entradas y salidas a otros actores y de los
comportamientos que convierten las entradas en salidas.
Los componentes básicos de los diagramas de casos de uso son el actor, el caso de uso y la
Asociación. . Los Actores pueden ser los seres humanos, otros equipos, piezas de hardware,
o incluso de otro software sistemas. Un caso de uso se presenta con una elipse y el nombre
del caso de uso está escrito dentro. Las asociaciones son líneas entre actores y utilizan los
casos, y indican que el actor participa en el caso de uso.
Para apoyar el análisis de requisitos no funcionales (por ejemplo, fiabilidad, facilidad de
mantenimiento y rendimiento), utilizar casos debe ser creado para apoyar los escenarios en
los que los requisitos no funcionales serán probados. Algunos ejemplos son: 1) crear un caso
de uso de las pruebas de rendimiento a través de una interfaz de componentes distribuidos y
2) creación de un caso de uso de las pruebas de la adaptabilidad de un componente
extendiéndolo (es decir, agregar clases) y examinándolo para determinar si todavía tienen los
principios de diseño arquitectónico. Estos casos de uso de nivel de sistema pueden aplicarse
de manera independiente por el cual una parte o sector de la arquitectura se está probando
independientemente de la funcionalidad de dominio empresarial tendrá que apoyar.
Para crear el caso de uso, identifique primero los actores en el sistema. A continuación, dar
prioridad a los servicios que se apliquen. Nos recomienda la creación de un caso de uso para
cada servicio propuesto.

15. La especificación de casos de uso contiene el texto que Además, describe el caso de uso. La
especificación de texto también generalmente describe todo lo que puede salir mal durante el
curso de la Especificación del comportamiento, y qué medidas correctivas tomará el sistema.
Esto especificación puede personalizarse o ampliarse para tratar cuestiones concretas dentro
de una implementación o una Organización.
Conclusiones y comentarios
Esta Sección debería proporcionar cualquier comentario final sobre el sistema, el diseño, o el
uso del sistema. Debe incluir cualquier problema conocido, restricciones, o factores que
contribuyeron a las decisiones, o podrían afectar el sistema en el futuro.

18. Recomendaciones en la arquitectura de la integración de servicio
Una arquitectura exitosa orientada a servicios permite a las empresas implementar
rápidamente nuevas soluciones de negocio o cambiar los existentes y puede ofrecer un
substancial ROI. Sin embargo, la SOA no es necesariamente fácil realizar. El siguiente mejor
prácticas le ayudará a cosechar los beneficios completos de SOA.
• proporcionar estructura organizativa de alto nivel y apoyo. El éxito con SOA requiere
compromiso de la empresa e inversión. SOA no puede realizarse con un solo proyecto. Tiene
que haber un grupo de expertos, tales como el centro de competencia, que se centra en la
definición, crecimiento y la reutilización de la SOA. Se necesitan Organización de procesos y
políticas que rijan la integración de la empresa. Como integración cruza límites de la
Organización, también puede causar territorial controversias. Las empresas necesitan
procesos y políticas para administrar estas controversias.
• implementar arquitectura basada en estándares. las normas garantizan tanto entre
operabilidad y portabilidad. Impiden el bloqueo de tecnología y ayudan mantener el valor de
las inversiones en TI. Los servicios de Web permiten la adopción generalizada de SOA, a
pesar de las normas de servicio Esta ha sido una práctica de arquitectura conocida durante
tres décadas. XML permite a sus sistemas una manera de proporcionar un transporte basado
en estándares, la gestión y almacenamiento de datos estructurados y el contenido no
estructurado dentro de la Organización.
• implementar una enfoque basado en estándares. siga el ejemplo de los comités de las
normas que tienen larga experiencia con la creación de los procesos que tienen éxito en la
creación de estándares interoperables. Realizar revisiones para interfaces de servicios de
diseño que incluyen a todas las partes interesadas. Las partes interesadas pueden ser
identificadas a través de los casos de uso.
• pensar en grande, iniciar pequeño. Cuando planificamos para una implementación de SOA,
coincidir el impacto de toda la empresa para maximizar la reutilización y agilidad. Pero
comenzar con un proyecto que tiene un alcance limitado y una alta probabilidad de éxito.
Nada sucede como un éxito. Aprenderá mucho de cada implementación, por lo tanto espere a
que tenga un par de implementaciones menores antes de hacer frente a los más difíciles
retos.
• Invertir en formación. Tendrá una mayor probabilidad de éxito si sus empleados saben lo
que están haciendo. Algunos de los diseñadores y los programadores tienen experiencia con
SOAs que se basan en estándares como Web servicios y XML.

19. Es todo demasiado nuevo. Todos los Interesados, incluidos el negocio y los administradores
de TI, arquitectos, los diseñadores, programadores y personal de apoyo operacional necesitan
entender los conceptos generales de SOA y su papel en el proceso. Los Arquitectos
necesitan comprender los parámetros de diseño y las mejores prácticas para diseñar
creaciones de sistemas ágiles y reutilizables. Los programadores necesitan entender la nueva
tecnología y cómo implementar servicios y componentes de la infraestructura. el Personal de
apoyo operacional necesita entender las implicaciones de gestión de un SOA distribuido.
• usar Herramientas para ahorrar tiempo y dinero. No trate como artesanía todo. Hay una
amplia variedad de herramientas que pueden reducir tiempo y la habilidad para implementar
la solución. Invertir en herramientas cuando las ventajas sobrepasan claramente el costo.
El Grupo de vanguardia es un interesante caso de estudio en el que cada una de estas
prácticas recomendadas entra en juego
Caso de estudios
El grupo de vanguardia' solución simplemente brillantequot;
Se ha descrito como una quot;solución simple brillantementequot; cuando el grupo de vanguardia
tomó una decisión a finales de la década de los 1990 para alinear su portal de clientes con su
sistema de servicio al cliente. En retrospectiva, son sorprendentes las organizaciones que no
llegado a la misma conclusión, porque los beneficios parece tan evidente:
• La paridad entre los canales de interfaz de cliente en la funcionalidad
•reducción de la complejidad en el mantenimiento de sistemas múltiples
• una arquitectura puede ser aprovechada y volver a ser utilizada para otros fines
Los resultados actuales han sido impresionantes. La Formación de los empleados internos se
redujo significativamente, prácticamente hubo una eliminación de cuatro a seis semanas de
formación. El retiro de un gran número de bases de datos y aplicaciones redujo el
complejidad de la arquitectura subyacente. Casi un 10 % menos personal era necesario para
mantener los sistemas. los Tiempos de respuesta del usuario se redujeron del 60 al 70 %,
aumentando la eficacia del personal. Además, la arquitectura apoyo el desarrollo de
aplicaciones que mejoraron varios procesos clave empresariales.
Estos cambios se prevé que traduzca en un ahorro anual de 30 millones de dólares. La
inversión fue significativa, pero el rendimiento esperado es una tasa interna de devolución de
más de 20 %.

20. Mientras que las inversiones en la arquitectura se suelen considerar como los costos que no
tienen ningún beneficio aparente, vanguardia demuestra que la aplicación de una arquitectura
que apoya la reutilización puede tener un impacto significativo en un negocio. Un buen
diseño de arquitectura orientada al servicio es la clave para lograr estos beneficios. Los
Servicios Web no son necesarios, como vimos con lo que logro vanguardia , pero deberían
ayudar a reducir los costos que corrían en este proyecto reduciendo la cantidad de trabajo
personalizado de infraestructura que ahora se proporciona a través de la tecnología de
servicios Web.
Siguientes pasos
Los Servicios son los pilares fundamentales para aplicaciones compuestas y controladas por
el proceso de integración. La Definición de servicios de la empresa reutilizables, así como
gestión y medición reutilizar, requiere el compromiso de la empresa en curso y la inversión.
El éxito con SOA es tanto una cuestión de gestión como lo es la tecnología. Empresas
interesadas en la agilidad empresarial a largo plazo invertirán en todos los aspectos de la
integración de la empresa, incluyendo la información y el proceso de integración
arquitectura. Las empresas que se centran en presionar necesidades tácticas, definirán sólo
lo que es absolutamente necesario.