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 gAStElUDR. CARloS ARtURo toRRES gAStElU

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.

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.

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

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.

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.

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 " (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.

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

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.

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.

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.

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,

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.

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.

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.

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.

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 brillante"

Se ha descrito como una "solución simple brillantemente" 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 %.

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.