SISTEMAS INTEGRALES EN

LAS ORGANIZACION

ES

EQUIPO 8:

PACHECO MARTINEZ ADRIANA

PEREZ PALACIOS JONATHAN

ZAMUDIO ZARAGOZA NOHEMI

CAPITULO 7SERVICE

INTEGRATION ARCHITECTURE

VISIÓN GENERAL DE EJECUTIVO

La Arquitectura de Integración de Servicios se define como las aplicaciones de negocio reutilizables, fácilmente cambia la funcionalidad de los componentes de negocio. Este es el concepto de una arquitectura orientada a servicios (SOA). Mientras que SOA se ha considerado una buena práctica por más de dos décadas, hasta hace poco, muy pocas empresas se interesaron en ellos. Ahora de repente SOA es un tema candente en TI, y en el centro de muchas iniciativas, destinadas a aumentar la agilidad empresarial.

En una arquitectura SOA, las funciones empresariales discretas se crean como procesos independientes con componentes estándar entre caras que se puede acceder por otras aplicaciones, servicios o procesos de negocio, independientemente de la plataforma o lenguaje de programación. Estos servicios pueden ser combinados con flexibilidad para soportar diferentes o cambiar los procesos de negocio y funciones. Apoya la creación de compuestos de aplicaciones, que pueden ser rápidamente de los servicios nuevos y existentes.

En el pasado, las empresas apuestan por CORBA, J2EE o NET. Para crear una SOA, la mayoría de las grandes empresas utilizan todo lo anterior. El riesgo, y el costo de la normalización es compensados con los posibles beneficios de SOA. Esto representa una baja tasa de adopción. Pero los servicios Web han alterado significativamente la ecuación de valor.

LA HISTORIA DE LA ARQUITECTURA ORIENTADA A SERVICIOS

El concepto de SOA se inició en la década de 1980 y fue bien acogido por la creación de redes y programación orientada a objetos. En 1983, el de Interconexión de sistemas abiertos (OSI), modelo de referencia fue aprobado por la Organización Internacional de Normalización (ISO) como una referencia común para el desarrollo de normas de comunicación de datos. Define las funciones de comunicaciones de datos en siete capas. Cada capa se define el servicio de comunicación, y cada servicio tiene un interfaz claramente definido con la capa por encima y por debajo de él.

Este SOA ha pasado la prueba del tiempo. Si bien la tecnología y la capacidad de cada capa han cambiado drásticamente, la propia arquitectura actual. Mientras que las interfaces entre los servicios siguen siendo los mismos, los servicios pueden ser cambiados fácilmente.

El Open Software Foundation (OSF), el grupo responsable del estándar de UNIX, desarrollado el medio ambiente de computación distribuida (DCE), basado en una arquitectura orientada a servicios. DCE proporciona servicios de infraestructura de distribución. En informática, incluyendo autenticación y servicios de seguridad, servicios de directorio y las llamadas a procedimiento remoto de archivos y servicios de gestión.

CORBA es un proveedor independiente de la arquitectura y la infraestructura del Grupo de Gestión de Objetos (OMG), que permite las aplicaciones trabajar juntos a través de las redes mediante el protocolo estándar IIOP. CORBA permite la interoperabilidad entre plataformas.

Los más actual son las tecnologías de componentes J2EE y NET. J2EE es un componente basado en la plataforma que gestiona la infraestructura distribuida y apoya los servicios web interoperables que permiten a las empresas soluciones. En la actualidad es el más implementado modelo de componentes.

.NET de Microsoft es la aplicación de una arquitectura de servicios Web.

Que permiten a las legiones de programadores de Microsoft, para crear servicios web en los lenguajes de programación que están más familiarizados, con este conserva una gran inversión en instalaciones existentes, conjuntos de capacidades de J2EE son generalmente más caros que los programadores de Microsoft.

SOA. Servicios Web son la primera norma de aceptación universal porque todos los grandes proveedores pueden, en teoría, apoyarla. Con las que trabajan. NET, J2EE, CORBA (siempre y cuando todo el mundo se pone a la misma versión de la norma). A pesar de algunas zonas de la norma que aún están inmaduros, servicios web y XML han eliminado las barreras para el riesgo, la adopción de SOA, logra que los beneficios superan con creces los riesgos.

Aplicaciones de misión crítica existentes actualmente en el mainframe y otras plataformas puede ser envuelto en las interfaces de servicios Web, para acceder a aplicaciones de otros navegadores. Esto lo permite a las empresas crear servicios de negocio de los sistemas existentes, y aplicar con rapidez e incorporar nuevas funcionalidades. Uso de servicios Web, las empresas pueden empezar a crear una SOA, aprovechando las inversiones existentes y añadir nuevas funcionalidades gradualmente. SOA es la arquitectura que mejor permite a largo plazo debido a la agilidad de negocios que apoya la reutilización, y el rápido despliegue de la nueva solución.

BENEFICIOS DE SOA

Permitir la agilidad empresarial. SOA es la mejor manera "para la agilidad empresarial. Se maximiza el aprovechamiento de los recursos existentes y reducir al mínimo tiempo el costo de desplegar nuevas solicitudes. En lugar de desarrollo, las aplicaciones desde cero, las empresas pueden utilizar la funcionalidad de salir y crear nuevas soluciones mediante el ensamblaje de componentes de aplicaciones existentes y nuevas funcionalidades, este fin de agilizar el despliegue de nuevas soluciones.

Proporciona mayor retorno de la inversión. Empresas que definen la reutilización de servicios. Y crear o recapitulación de negocios como la funcionalidad estándar de servicio de maximizar sus inversiones en TI, a través de la reutilización y el apalancamiento de los activos existentes.

Permitir la agilidad de TI. Definiciones estándar de servicios puede proporcionar una capa de abstracción de los servicios empresariales. Un servicio puede funcionar en cualquier lugar y acceder a él desde cualquier lugar. Por lo tanto, una empresa puede fácilmente, cambiar la ubicación o la tecnología de código subyacente.

Reducir los costes de formación. Cada servicios pueden ser encapsulados y resumidos en una forma que hace fácil de utilizar y ensamblar los componentes en las aplicaciones con un mínimo de programación. Las empresas pueden utilizar más programadores expertos para crear las definiciones de funcionalidad y servicio, que luego pueden ser reutilizados por los programadores menos técnico y visual aplicación herramientas de montaje.

Reducir el costo de las pruebas y el fallo por el que se fijan. Cada servicio es como un cuadro negro que realiza una función específica y tiene una interfaz de publicación que acepte, define las entradas y salidas de productos definidos. Cada uno de los servicios pueden ser probados por separado, y luego reutilizarse una y otra vez. Pruebas de interfaz es bastante sencillo, y puede ser automatizado utilizando las herramientas de prueba.

Soporte de múltiples tipos de cliente y plataformas. La SOA ofrece una capa de abstracción de las plataformas. Esto hace posible para varios tipos de dispositivos de usuario final, incluyendo los navegadores y dispositivos móviles tales como beepers, teléfonos celulares, PDA y otros dispositivos especializados para utilizar la funcionalidad de la misma empresa y tienen la información comunicada a los diferentes dispositivos. Esta plataforma proporciona una gran independencia del ahorro para las grandes empresas que tienen una gran variedad de tecnologías en uso.

Velocidad de tiempo de desarrollo a través de un desarrollo paralelo. Diferentes programadores pueden trabajar independientemente de los distintos servicios, ya que cada servicio es independiente y no depende de la situación de otro ser hielo.

Mientras el servicio de interfaces bien definidas al inicio del proyecto, y los programadores saben qué esperar de otros servicios, pueden fácilmente crear y definir los servicios de forma independiente. Lo que solía decir que lo he pasado un cierto punto de añadir más a los programadores a un proyecto aumenta el tiempo de desarrollo. Esto ya no es cierto con SOA.

Aumentar la escalabilidad y disponibilidad. SOA ofrece la ubicación, porque la transparencia, existe la posibilidad de aumentar la escalabilidad, la adición de varias instancias de un servicio de balanceo de carga dinámica de la tecnología y encontrar la ruta adecuada a la solicitud de servicio ejemplo, del mismo modo, si hay varias instancias de un servicio en el red, y está disponible, el software puede transparente ruta la solicitud a otro ejemplo, proporcionando así una mejor disponibilidad. Esto es más el caso de nuevos servicios basados en servicios de aplicación, y no la funcionalidad que se ha envuelto en las interfaces de servicios web ..

En última instancia, SOA se convertirá en la forma en la mayoría de las organizaciones construir sus infraestructuras de TI, ya que es la mejor y única manera de proporcionar a largo plazo

CASO DE ESTUDIOLa mejora de Servicios Estudiantiles de Texas A&M

Texas A & M University ha sido un verdadero líder en la aplicación de la tecnología para apoyar la misión de la universidad. Como uno de los más grande del mundo, las instituciones educativas, mejorar los servicios a los alumnos-durante el registro de la especialidad sigue siendo una alta prioridad.

Una arquitectura orientada a servicios utilizan los servicios Web son muy adecuados para la mejora del registro y de los servicios auxiliares a los estudiantes que esperan más los servicios electrónicos y menos tiempo de pie en multas. Por lo tanto, se tomó la decisión de implementar un servicio en línea.

El departamento de TI de clase desarrollado su sistema de registro utilizando servicios Web y de dos funcionarios y fue capaz de ofrecer un sistema en tres meses. La mayoría de los servicios fue proporcionada por el actual Cobol y Natural de programas que están corriendo en el mainframe. Estaban atados juntos en los servicios Web utilizando EntireX Communicator. Se estima que la utilización de este enfoque y la tecnología se produjeron un ahorro de más del 50% en el tiempo de desarrollo en comparación con anteriores esfuerzos similares en el departamento.

Durante el registro, miles de estudiantes se sirven simultáneamente y de manera eficiente. El impacto fue a la universidad un mayor grado de satisfacción de los estudiantes y una reducción significativa en las llamadas telefónicas de la universidad personal.

Agilidad. No obstante, se tardará algún tiempo y la inversión para llegar. Hasta la fecha, la mayoría o la industria se ha centrado en la solución de los problemas de conectividad técnica considerable. Sin embargo, los obstáculos más grandes para permitir que realmente las empresas, a través de SOA son la agilidad en la definición, construcción y gestión de servicios empresariales reutilizables.

¿DEFINICIÓN DE SERVICIOS DE ABAJO-ARRIBA O DE ARRIBA HACIA ABAJO?

Para realizar el trabajo, tanto de abajo arriba y de arriba abajo, se necesitan métodos. El enfoque de arriba hacia abajo se obtiene un nivel de abstracción que es necesaria la creación de la agilidad empresarial. Sin embargo, en algún momento el modelo para satisfacer las necesidades de tecnología, y los servicios que tengan que desarrollarse como componentes o colecciones de componentes.

SERVICIO DE ORIENTACIÓN DE EVENTOS DE DISEÑO

La definición de requisito de negocio en términos de eventos de negocios ofrece una serie de ventajas.

En primer lugar, evento impulsado por la arquitectura orientada al servicio a la mayoría de sistemas ágiles.

En segundo lugar, eventos de negocios son una buena forma de servicios de diseño, ya que son fáciles para el usuario de negocios para entender, identificar y verificar a su diseño.

Por último, la definición de los eventos de negocios, el sistema de captura y responder a las define claramente los límites del sistema. Esto es esencial para garantizar el éxito y la rápida implementación.

ESPECIFICACIÓN DE INTEGRACIÓN DE SERVICIOS DE ARQUITECTURA Es un proceso iterativo, esta especificación

proporcionará directrices para la creación de servicios reutilizables.

Introducción

Esta especificación de SOA proporciona la arquitectura y el diseño de orientación para la aplicación de una arquitectura orientada a servicios para la integración. Este documento define los eventos, servicios y componentes. Es el diseño y especificación de arquitectura para el desarrollo de los servicios y componentes.

Ámbito de aplicación

El ámbito de aplicación de esta especificación se define por el alcance del proyecto. Los documentos de la arquitectura y el diseño de un enfoque SOA para una solución integrada. El ámbito de aplicación de esta especificación debe describir el alcance de la aplicación o sistema que se está diseñando.

Principales participantes

Esta sección debe definir las partes interesadas que la empresa puede verificar los eventos, servicios e interfaces; el equipo de desarrollo que ejecutará la aplicación de la concepción, y el equipo encargado de la arquitectura y el diseño. Todos los demás participantes o interesados también deben ser identificados, entre ellos sus funciones.

Eventos de Negocios

La sección de Eventos de Negocios define las actividades que el sistema debe apoyar. Un evento es algo que.

• Ocurre en el entorno empresarial. • Ocurre en dar un punto en el tiempo. • Debe ser respondido por el sistema.

Hay dos tipos de eventos: eventos de negocios y temporal evento.

Eventos de negocios, son actividades que ocurren en el negocio, y detectados por la definición de cada actividad dentro del ámbito de aplicación del sistema.

Temporal de los acontecimientos ocurren en un punto predeterminado en el tiempo. Eventos temporales existen porque la política de la empresa exige que ciertas actividades del sistema se producen en determinados momentos, o porque el sistema produce sus resultados en un tiempo de base.

Caso de Estudio

Delta Airlines-Gerente de Eventos de Negocios.Por el Delta del Sistema Nervioso El Delta del Sistema Nervioso (DNS), representa una inversión de $ 1 billón de dólares para entregar a tiempo los datos "a los clientes, empleados y socios." Sin embargo, no es la entrega de la información, pero el uso de que los datos en el manejo de eventos de negocios que se la gran ventaja del DNS. Por ejemplo, una solicitud inicial de que el sistema está dirigido a los manipuladores de equipaje y garantizar que tengan una idea exacta de la puerta y los retrasos de los vuelos cambios para que puedan planificar mejor el movimiento de equipajes y fuera de los aviones. El cambio en la situación de un vuelo es un evento que tiene repercusiones en todo el sistema de línea aérea. Siempre que ocurra un suceso, el cambio en la situación puede ser actuado por los principales participantes de este evento con la información y los servicios para responder a estos cambios .

El DNS se está convirtiendo en un delta en tiempo real de la empresa con la capacidad de servir a sus clientes. Sin embargo, también tiene un enorme generación de ingresos y de ahorro implicaciones. Por ejemplo, tener información en tiempo real permite Delta para aumentar el número de vuelos por día a los aviones se desplazan dentro y fuera más rápido. Horas extraordinarias del personal de tierra ociosas puede reducirse mediante una mejor planificación. Costos asociados con el mal manejo de las bolsas puede ser eliminado. Si bien la atención se centra en la información disponible, el valor será significativo en la identificación de eventos y, a continuación, tomar las medidas adecuadas como resultado de los acontecimientos. No es necesario que una empresa para crear una nueva fuente de información. Más bien, es importante crear una arquitectura que es capaz de actuar en eventos de negocios y los flujos de manera eficiente aunque el sistema como un servicio de Delta ha establecido un sistema de este tipo en el lugar con su DNS.

Servicios

El sistema de las respuestas se definen en el cuadro Eventos se utilizan para determinar los servicios esenciales que el sistema debe proporcionar. Algunos de estos servicios o funciones ya existen en otros sistemas, la funcionalidad y otros serán nuevos y deben ser desarrollados a continuación, integrados. El servicio de las descripciones de definir el alcance de la funcionalidad necesaria para llevar a cabo una empresa de servicios.

Número de evento Evento de Negocio

Descripcion de evento

Response

<Event number> <Name of event>

<Description of the event>

<List containing

descriptions of potential action>

E1 Para cliente Web

Este evento se inició por un

suceso externo,

cuando un cliente realiza una solicitud

de orden.

R1.2 Introduzca

nuevo cliente R1.3

Compruebe crédito

R1.4 Revise el inventario de existencias

E2 Orden es procesada

Es válido para garantizar una se coloca en el

sistema.

R2.1 ingresar cuentas por

pagar R2.2Cumplir

fin E3 El pedido sera

enviadoEste evento se inició cuando un pedido ha

sido procesado. Se

asegura de que el pedido está listo para

enviar.

R3.1 Seguimiento

número asignado

R3.2 E-mail de notificación al

cliente

E4 Orden se devuelve

Este evento se inició por un caso cuando

un cliente devuelve un pedido. Se asegura de

que la orden es procesada

regresado correctamente.

R4.1 Volver autorización expedida

R4.2 Crédito cuenta de

cliente R4.3 de

crédito de inventario

Tabla de Categoría de servicios

El Servicio Categoría cuadro recoge todas las respuestas a eventos de negocios, y define si la función ya existente en uno o varios sistemas, o si es una nueva funcionalidad. En el cuadro también se define la probabilidad de proporcionar los servicios de la funcionalidad. El servicio en este momento es mejor que la primera en los servicios de una definición y se perfeccionarán aún más en el próximo paso. La hora de definir los servicios, piense en módulos dentro de una aplicación existente que el desempeño del servicio o que módulos para el desarrollo.

Definición del Tabla de servicios

La definición de los servicios plenamente el cuadro describe cada uno de los servicios a un nivel suficiente para la creación de servicios Web u otros interfaces de integración. Cada servicio debe ser descrito en términos de sus funciones y el sistema utilizado para crear el servicio. En la creación de esta mesa, todas las funciones del grupo y las respuestas que juntos forman una coherente módulo. Por ejemplo, el servicio de gestión de un conjunto particular de datos, tales como la información de los clientes, o información sobre el producto, o debe realizar un servicio específico que pueda utilizarse en otras aplicaciones, tales como la verificación del crédito o de fijación de precios debe existir entre los servicios de enganche suelto. Cada servicio debe interactuar con cualquier otro servicio a través de la interfaz definida. Cambios en un servicio no debería influir el funcionamiento de otros servicios.

Servicio Funciones Descripción Existentes/nuevos sistemas

Mantenimiento de registros de clientes

Comprobar la existencia o añadir/eliminar/modificar

Resumen de servicios Web, bases de datos y búsquedas de las conexiones, maneja registros de clientes

Nuevo-servicio Web, con interfaces de gestión de clientes.

Verificación de crédito

Compruebe crédito Interfaz con el módulo de verificación de crédito del sistema ERP

Finanzas

Gestión de inventarios

De débito / crédito de inventario de existencias

Interfaz con el sistema de gestión de almacenes

Sistema de depósito

Cuentas por cobrar De crédito / débito cuenta de cliente

Interfaz con el A / R módulo del sistema ERP

Finanzas

Orden gestión Gestión del flujo de trabajo de un manual de servicio

Interfaz con el sistema de gestión de almacenes

Sistema de depósito

Envío de gestión Integración con el sistema de FedEx; enviar una notificación al cliente

FedEx integrar el seguimiento de servicios Web en la interfaz web del cliente, para crear e-mail de notificación componente

Nueva - FedEx servicio Web

Gestión de clientes Proceso de retorno; centro de llamadas de apoyo

Portal web para centro de llamadas, proporcionando interfaz unificada de los clientes y para información

Nueva - componente Web

Interfaz de Servicio del Cuadro Mientras que el servicio Web, norma define cómo

especificar una interfaz, no define los datos y la funcionalidad que la interfaz debe contener. La especificación de interfaz de servicios proporciona la información necesaria para la creación de servicios web u otra aplicación o componente interfaces. Usando la definición de los servicios de mesa, una lista de todos los insumos, productos, y los métodos que la interfaz a las necesidades de apoyo, y determinar la forma en que la interfaz se llevará a cabo.

Service Customer maintenance

Inputs Customer ID; name, telephone number; address; shipping information; e-mail; credit; discount.

Outputs Customer ID; name, telephone number; address; shipping information; e-mail; credit; discount

Methods MCRUD data operations

Implementation Portal based interface with data access service that controls connectivity to back-end data source. Will either build Web service or install vendor data connectivity solution.

El objetivo de la definición de interfaces estándar es para maximizar la agilidad empresarial. Permite que las aplicaciones y servicios basados en plataformas con diferentes idiomas y la tecnología para interoperar. Cada servicio que permite cambiar la funcionalidad interna y las normas o la tecnología subyacente sin afectar a otras aplicaciones o componentes, siempre que la interfaz sigue siendo la misma. Por lo tanto, obtener la interfaz de derecho es esencial para maximizar la reutilización y agilidad. Es muy recomendable crear un glosario de la terminología que es significativa y coherente con una cruz todas las partes interesadas. La Especificación de la interfaz es permitir que tales comentarios y diseño para describir la interfaz para que pueda ser aplicado correctamente y de forma óptima.

Diagrama de casos de uso y de Especificaciones

Un diagrama de caso de uso no se puede utilizarse para ilustrar las relaciones entre usuarios, eventos y servicios. Su final del rompecabezas de la especificación. Integra toda la información de las secciones anteriores.

Casos de uso definen los actores y la forma en que interactúan con el sistema de servicio. Representan los actores y el papel, y pueden ser los seres humanos, los otros equipos, piezas de hardware, o incluso a otros sistemas de software.

Se debe proporcionar estímulos para iniciar el caso de que a su vez, requiere de sistemas (o servicios).

Los casos de uso describen el comportamiento del sistema cuando uno de estos actores envía un estímulo especial que representa a la empresa y los sistemas de respuestas de los acontecimientos en términos de estímulo caso que pone en marcha el caso de las entradas y salidas a otros actores, los comportamientos que convierten los insumos a las salidas.

Los componentes básicos de los diagramas de caso de uso son el actor, el caso de uso, y la asociación. Un actor se representa mediante la figura palo y el papel del usuario que está escrito debajo del icono de los actores puede ser seres humanos, otras piezas de hardware de computadoras, o incluso a otros sistemas de software.

Un caso de uso se representa con una elipse, y el nombre del caso de uso está escrito adentro. Asociaciones son las líneas entre los actores y los casos de uso y que indican que un actor participa en el caso de uso.

Use Case Use Case 009 – Place an Order

Primary actors Customer

Abstract This use case allows the customer to create a purchase order using/updating existing customer. If the customer

has initiated a purchase order directly (without accessing an online catalog) he or she can select the

items from a product list for this use case.

Goal To allow customers to create and submit an order

Focus classes Customer, item configuration, purchase order, standard item

Preconditions Customer has user ID and valid password on customer extranet

Trigger User decides to place an order online.

General scenario 1. Customer clicks the “order” button - Initiating Event2. Screen appears displaying or requesting customer information (UC010 - Display Customer Information, UC011 – Customer not found)3. Customer complements purchase order information including payment type. “Bill to” and “Ship to” addresses.4. Customer selects item fro item list (UC017 – Order Standard Item from Product List)5. Customer selects item from online catalog (uc007 – Order Standard Item from Online Catalog)6. Customer clicks on “clear” button7. Customer clicks on “submit” button8. Customer clicks on “end” button – Post Condition (goal achieved)

Successful operation responses/output

1. User provided visual confirmation of order and confirmation number2. Order entry system updated with order

Extensions / alternative paths / unsuccessful operation responses / outputs

4a. This step may be omitted.7a. This step may be omitted.6a. This step may be omitted.

Variations None

Dependencies UC007 – Initiate Session

Requirements reference

Requirements 4.1, 4.2, 4.3, 4.7

Screen reference Screen 8

Backend reference Web Services 2, 7, 9

Notes None

Issues Need to verify how “product list” will be displayed, stored, and updated.Need to determine how to link submitting the PO when the customer is using the online catalog.

Conclusión y Comentario

Esta sección debe proporcionar las observaciones finales sobre el sistema, el diseño, o la utilización del sistema. Debe incluir los problemas conocidos, limitaciones, o la circunstancia que contribuyó a las decisiones, o podrían afectar el sistema en el futuro.