2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. .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.
9. 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.
10. 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.
11. Permitir la agilidad empresarial. SOA es la mejor
manera quot;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.
12. 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.
13. 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.
14. 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.
15. 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 ..
16. 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
17. La 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.
18. 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.
19. 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.
20. 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.
21. 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.
22. 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.
23. Á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.
24. 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.
25. 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.
26. 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 quot;a los clientes, empleados y socios.quot; 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 .
27. 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.
28. 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.
29. Número de evento Evento de Descripcion de Response
Negocio evento
<Event number> <Name of <Description of <List containing
event> the event> descriptions of
potential
action>
E1 Para cliente Este evento se R1.2 Introduzca
Web inició por un nuevo cliente
suceso externo, R1.3 Compruebe
cuando un crédito
cliente realiza R1.4 Revise el
una solicitud de inventario de
orden. existencias
E2 Orden es Es válido para R2.1 ingresar
procesada garantizar una se cuentas por
coloca en el pagar
sistema. R2.2Cumplir fin
E3 El pedido sera Este evento se R3.1
enviado inició cuando un Seguimiento
pedido ha sido número
procesado. Se asignado
asegura de que R3.2 E-mail de
el pedido está notificación al
listo para enviar. cliente
E4 Orden se Este evento se R4.1 Volver
devuelve inició por un autorización
caso cuando un expedida
cliente devuelve R4.2 Crédito
un pedido. Se cuenta de
asegura de que cliente
la orden es R4.3 de crédito
procesada de inventario
regresado
correctamente.
30. 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.
31. 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.
32. Servicio Funciones Descripción Existentes/nuev
os sistemas
Mantenimiento de Comprobar la existencia o Resumen de servicios Web, Nuevo-servicio
registros de clientes añadir/eliminar/modificar bases de datos y Web, con
búsquedas de las interfaces de
conexiones, maneja gestión de
registros de clientes clientes.
Verificación de crédito Compruebe crédito Interfaz con el módulo de Finanzas
verificación de crédito del
sistema ERP
Gestión de inventarios De débito / crédito de Interfaz con el sistema de Sistema de
inventario de existencias gestión de almacenes depósito
Cuentas por cobrar De crédito / débito cuenta de Interfaz con el A / R Finanzas
cliente módulo del sistema ERP
Orden gestión Gestión del flujo de trabajo de Interfaz con el sistema de Sistema de
un manual de servicio gestión de almacenes depósito
Envío de gestión Integración con el sistema de FedEx integrar el Nueva - FedEx
FedEx; enviar una notificación al seguimiento de servicios servicio Web
cliente Web en la interfaz web del
cliente, para crear e-mail
de notificación
componente
Gestión de clientes Proceso de retorno; centro de Portal web para centro de Nueva -
llamadas de apoyo llamadas, proporcionando componente
interfaz unificada de los Web
clientes y para
información
33. 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.
34. 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.
35. 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.
36. 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.
37. 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.
38. 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.
39. 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.
40. General scenario 1. Customer clicks the “order” button - Initiating Event
2. 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” button
7. Customer clicks on “submit” button
8. Customer clicks on “end” button – Post Condition (goal achieved)
Successful operation 1. User provided visual confirmation of order and confirmation number
responses/output 2. Order entry system updated with order
Extensions / 4a. This step may be omitted.
alternative paths / 7a. This step may be omitted.
unsuccessful operation 6a. This step may be omitted.
responses / outputs
Variations None
Dependencies UC007 – Initiate Session
Requirements Requirements 4.1, 4.2, 4.3, 4.7
reference
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.
41. 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.