Capítulo 4

Orientación a Servicios
4.1 Introducción a la Orientación a Servicios
4.2 Problemas resueltos por la Orientación a Servicios
4.3 Retos introducidos por la Orientación a Servicios
4.4 consideraciones adicionales
4.5 Efectos de la Orientación a Servicios a la empresa
4.6 Orígenes e influencias de la Orientación a Servicios
4.7 Antecedentes Estudio de caso
 H espués de haber cubierto algunos de los elementos básicos de la computación orientada a

servicios, nosotros ahora estrechar nuestro enfoque en la voluntad de servicio. El siguiente

conjunto de secciones establecer el paradigma de la orientación a servicios y explicar cómo
está cambiando la cara del distribuida
informática.

4.1 Introducción a la Orientación a Servicios

En el mundo todos los días a nuestro alrededor,los servicios son y han sido frecuentes
durante el tiempo que ha existido la historia civilizada. Cualquier persona que lleva a
cabo una tarea distinta en apoyo de OTH-ers está proporcionando un servicio (Figura
4.1). Cualquier grupo de individuos que realizan colectivamente una tarea también
está demostrando la entrega de un servicio.

Figura 4.1
Tres individuos, cada uno capaz de proporcionar una clara
Servicio.

similar,una organización que lleva a cabo las tareas asociadas con su propósito o
negocio también está proporcionando un servicio. Mientras la tarea o función que se
está proporcionado es bien definidos y pueden ser relativamente aislados de otras
tareas asociadas, que puede ser claramente clasificado como un servicio (Figura 4.2).
Existen ciertos requisitos básicos para que un grupo de proveedores de servicios
individuales para colaborar con el fin de ofrecer un servicio de mayor colectivamente.
Figura 4.2, por ejemplo,dis-juega un grupo de empleados que cada proporcionar un
servicio de entrega para ABC. A pesar de que cada individuo aporta un servicio
distinto, para que la empresa funcione de manera eficaz, su personal también debe
tener fundamental, características comunes, tales como la disponibilidad,
confiabilidad,y la capacidad de comunicarse utilizando el mismo lenguaje. Con todo
esto en su sitio,estas personas pueden estar compuestos en un equipo de trabajo
productivo. El establecimiento de este tipo de requisitos de referencia es un objetivo
clave de la orientación a servicios.
4.1 Introducción a la Orientación a Servicios
Figura 4.2
Una empresa que emplea a estas tres personas pueden componer
sus capacidades para llevar a cabo sus negocios.

Servicios de automatización de negocios

En el mundo de SOA y la voluntad de servicio, el termino “Servicio”No es genérico.
Tiene connotaciones SPE-CIFIC que se relacionan con una combinación única de
características de diseño. Cuando la lógica solución se construye constantemente
como servicios y cuando los servicios están diseñados consistentemente con estas
características comunes, la voluntad de servicio se realiza con éxito en todo un
entorno.
Por ejemplo,una de las características de diseño de servicio primaria exploradas como
parte de este estudio de la orientación a servicios es la reutilización. Un fuerte énfasis
en la producción de lógica resolutiva en el formato de los servicios que se posiciona
como recursos introducir con premios muy genérico y reutilizable tránsito gradual de
una organización a un estado en el que más y más de su lógica solución se vuelve
menos dependiente y más agnóstica a cualquier propósito o proceso de negocio.
fomentar repetidamente esta característica dentro de los servicios eventualmente
resulta en el potencial de reutilización de amplia difusión.
Consistentemente darse cuenta características específicas de diseño requiere un conjunto
de principios rectores.
Esto es lo que el paradigma de diseño de la voluntad de servicio se trata.

Los servicios son colecciones de Capacidades

Cuando se habla de servicios,es importante recordar que un solo servicio puede
proporcionar un conjunto de capacidades. Se agrupan juntos porque se refieren a un
funcional
70 Capítulo 4: Orientación a
Servicios

contexto establecido por el servicio. El contexto funcional del servicio ilustra en la

Figura 4.3, por ejemplo, es el de “envío.” Por lo tanto, este servicio en particular
proporciona un conjunto de capacidades asociadas con el procesamiento de los
envíos.

Figura 4.3
Al igual que un ser humano, un servicio automatizado
pueden proporcionar múltiples capacidades.

Un servicio puede actuar esencialmente como un contenedor de las capacidades

relacionadas. Se compone de un cuerpo de la lógica diseñada para llevar a cabo
estas funciones y un contrato de servicio que expresa cuál de sus capacidades se
ponen a disposición para la invocación pública.
Las referencias a las capacidades de servicio en este libro se centran
específicamente en los que se define en el contrato de servicio. Para una discusión de
cómo las capacidades de servicio se-guido DISTIN de operaciones de servicios Web
y métodos de componentes, consulte la sección Principios y servicio de
implementación de Medios en el Capítulo 5.

Orientación a Servicios como un paradigma de diseño

Según lo establecido en el Capítulo 3,un paradigma de diseño es un enfoque para el
diseño de la lógica solución. Cuando la construcción de la lógica solución
distribuida,enfoques de diseño giran en torno a una teoría de la ingeniería de software
conocida como la separación de las preocupaciones. En una palabra,este la-ory
establece que un problema mayor se resuelve de manera más eficaz cuando se
descompone en un conjunto de problemas o preocupaciones más pequeñas. Esto nos
da la opción de la lógica solución de partición en las capacidades,cada una diseñada
para resolver una preocupación individual. capacidades relacionadas se pueden
agrupar en unidades de lógica solución.
El beneficio fundamental para resolver los problemas de esta manera es que un
número de las unidades lógicas de la solución puede ser diseñado para resolver los
problemas inmediatos sin dejar de ser agnóstico a la mayor problema. Esto
proporciona la oportunidad constante para nosotros volver a utilizar las capacidades
dentro de esas unidades para resolver otros problemas también.
Existen diferentes paradigmas de diseño para la lógica de solución distribuida. Lo que
distingue serv-hielo-orientación es la manera en que se lleva a cabo la separación de
las preocupaciones y cómo se da forma a las unidades individuales de la lógica
solución. La aplicación de la voluntad de servicio a una media-ingful medida los
resultados en la lógica de la solución que se pueden clasificar de forma segura
como“orientada al servicio”
4.1 Introducción a la Orientación a Servicios

y las unidades que califican como “servicios.” Para entender exactamente lo que
significa que requiere una apreciación de los objetivos estratégicos que comprende el
Capítulo 3 combinado con el conocimiento de los principios de diseño asociados
documentados en la Parte II.
Por ahora, dejar's introducir brevemente cada uno de estos principios:

Contrato de servicio estandarizada

Servicios expresan su propósito y capacidades a través de un contrato de servicios. El
principio de diseño estandarizado de contrato de servicio es quizás la parte más
fundamental de la orientación a servicios, ya que requiere esencialmente que se tengan en
cuenta las consideraciones específicas en el diseño de un servicio's interfaz técnica
pública y la evaluación de la naturaleza y cantidad de contenido que se publica como parte
de un servicio's contrato oficial.
Un gran énfasis se coloca en aspectos específicos del diseño de los contratos,
incluyendo la forma en que los servicios funcionalidad expreso, ¿Cómo se definen los
tipos de datos y modelos de datos,y cómo se afirman y se fijan las políticas. Hay un
enfoque constante en asegurar que los contratos de servicio son optimizados,
apropiadamente granular, y Stan-dardized para asegurar que los criterios de
valoración establecidos por los servicios son consistentes, de confianza, y gobernable.
El capítulo 6 está dedicado a explorar este principio de diseño en detalle.

Servicio de Acoplamiento
El acoplamiento se refiere a una conexión o relación entre dos cosas. Una medida de
COU-pling es comparable a un nivel de dependencia. Este principio aboga por la
creación de un tipo específico de relación dentro y fuera de los límites del servicio, con
un énfasis constante en la reducción de (“aflojamiento”) Las dependencias entre el
contrato de servicio, su implementación, y sus consumidores de servicios.
El principio de servicio Acoplamiento promueve el diseño independiente y Evolu-ción
de un servicio's lógica y aplicación al mismo tiempo garantizar la interoperabilidad de
línea de base, la capacidad de los consumidores que han llegado a confiar en el
servicio's capacidades. Existen numerosos tipos de acoplamiento que intervienen en
el diseño de un servicio,cada uno de los cuales pueden afectar el contenido y la
granularidad de su contrato. Lograr el nivel adecuado de acoplamiento requiere que
las consideraciones prácticas equilibrarse contra diversas preferencias de diseño de
servicio.
El capítulo 7 proporciona una exploración en profundidad de este principio e introduce
relacionados pat-charranes y conceptos.
72 Capítulo 4: Orientación a
Servicios

servicio de abstracción
lazos de abstracción en muchos aspectos de la voluntad de servicio. En un nivel
fundamental,este principio hace hincapié en la necesidad de ocultar tanto de los
detalles subyacentes de un servicio como sea posible. Si lo hace, directamente
habilita y mantiene la relación libremente declarado COU-previamente descrito.
Servicio de abstracción también juega un papel importante en el posicionamiento y el
diseño de composiciones de servicios.
Varias formas de meta datos entran en la imagen cuando la evaluación de los niveles
de Abstrac-ción adecuadas. El grado de abstracción aplicada puede afectar contrato
de servicio granularidad y puede influir aún más el costo y el esfuerzo de gobernar el
último servicio.
Capítulo 8 se refiere a varios aspectos de la aplicación de la abstracción a diferentes
tipos de datos del servicio de meta, junto con los procesos y enfoques asociado con
ocultación de información.

Reutilización de servicios
Reutilización está fuertemente defendido dentro de la orientación a servicios; tanto
así, que se convierte en una parte central de análisis típicas de servicio y los procesos
de diseño,y también constituye la base de modelos de servicios clave. La llegada de
la madurez, La tecnología del servicio no propietaria ha pro-RESPETA la oportunidad
de maximizar el potencial de reutilización de la lógica de usos múltiples en un nivel sin
precedentes.
El principio de servicio Reutilización hace hincapié en el posicionamiento de los
servicios como recursos de la empresa con los contextos funcionales agnósticos.
Numerosas consideraciones de diseño son criados para garantizar que las
capacidades de servicio individuales están apropiadamente definen en relación a un
contexto de servicio agnóstico, y garantizar que puedan facilitar la reutilización de
requisitos necesarios.
Las variaciones y los niveles de los modelos de servicio agnóstico asociados
reutilización y están cubiertos en el Capítulo 9, junto con un estudio de los enfoques
de diseño de productos comerciales de cómo han influido en este principio.

Autonomía servicio
Para los servicios para llevar a cabo sus funciones de manera consistente y fiable ,su
lógica subyacente solución tiene que tener un grado significativo de control sobre su medio
ambiente y sus recursos. El principio de la autonomía de servicio soporta la medida en que
otros principios de diseño se pueden realizar con eficacia en entornos de producción del
mundo real mediante el fomento de las características de diseño que aumentan un
servicio's fiabilidad y la previsibilidad del comportamiento.
4.1 Introducción a la Orientación a Servicios

Este principio plantea diversas cuestiones que se refieren al diseño de lógica de

servicio, así como el servicio's entorno de ejecución real. Niveles de aislamiento y las
consideraciones normales-ización de servicios se tienen en cuenta para lograr una
medida adecuada de la autonomía, especialmente para los servicios reutilizables que
se comparten con frecuencia.
El capítulo 10 se señalan los problemas de diseño y desafíos relacionados con la
consecución de mayores niveles de autonomía de servicios, y clasifica más diferentes
formas de autonomía y pone de relieve los riesgos asociados.

apatridia servicio
La gestión de la información de estado excesivo puede comprometer la disponibilidad
de un servicio y socavar su potencial de escalabilidad. Los servicios son, por tanto,
idealmente diseñados para permanecer con estado sólo cuando sea necesario.
Aplicando el principio de servicio apatridia requiere que se evaluarán las medidas de
apatridia las posibilidades concretas, basado en la adecuación de la arquitectura de la
tecnología que rodea a proporcionar opciones de gestión del estado del-egation y
aplazamiento.
Capítulo 11 explora las opciones y los impactos de la incorporación de diseño sin
estado carac-terísticas en las arquitecturas de servicios.

Discoverability servicio
Para los servicios que se posicionan como los activos de TI con el retorno de la
inversión repetible que necesitan para ser fácilmente iden-tificado y entendidos
cuando las oportunidades de reutilización se presentan. Por lo tanto, el diseño de
servicios tiene que tomar la“calidad de las comunicaciones” del servicio y sus
capacidades indi-viduales en cuenta, independientemente de si un mecanismo de
descubrimiento (por ejemplo, un registro de servicios) es una parte inmediata del
medio ambiente.
La aplicación de este principio, así como una explicación de cómo la visibilidad se refiere a
interpretabilidad y el proceso de descubrimiento de servicio en general, están cubiertos en
el Capítulo 12.

Compuestabilidad servicio
A medida que la sofisticación de las soluciones orientadas a servicios sigue
creciendo,también lo hace la com-plejidad de configuraciones de composición de
servicios subyacentes. La capacidad para efectivamente com-pose servicios es un
requisito fundamental para lograr algunos de los objetivos más fundamentales de la
computación orientada a servicios.
74 Capítulo 4: Orientación a
Servicios

Complejas composiciones de servicios en lugar exigencias de diseño de servicios que

deben estar Antici-ciparon para evitar esfuerzos masivos de readaptación. Se espera
que los servicios sean capaces de par-ticipan como miembros efectivos de
composición,independientemente de si tienen que ser reclutados inmediatamente en
una composición. El principio de servicio Compuestabilidad aborda este requisito al
asegurar que una variedad de consideraciones se tienen en cuenta.
Cómo la aplicación de este principio de diseño ayuda a preparar a los servicios para
el mundo de las composiciones com-Plex se describe en el capítulo 13.

Orientación a Servicios e Interoperabilidad

Un elemento que puede parecer ausente de la lista anterior es un principio en la línea
de “Servicios son interoperables.” La razón de esto no existe como un principio
separado se debe a que la interoperabilidad es fundamental para cada uno de los
principios que acabamos de describir. Por lo tanto, en relación con computación
orientada a servicios,indicando que los servicios deben ser interoperables es casi tan
básico como que indica que los servicios deben existir. Cada uno de los ocho prin-
cipios soportes o contribuye a la interoperabilidad de alguna manera.
Éstos son sólo algunos ejemplos:

• Los contratos de servicio están estandarizados para garantizar una medida de

referencia de interoperabilidad-capacidad asociada con la armonización de los
modelos de datos.
• Reduciendo el grado de acoplamiento de servicio fomenta la interoperabilidad
haciendo que los servicios indi-viduo menos dependiente de los demás y por lo
tanto más abierto para la invocación por diferentes consumidores del servicio.
• Abstraer detalles sobre el servicio limita toda la interoperación a la contra-tracto
servicio, aumentar la consistencia a largo plazo de la interoperabilidad
permitiendo lógica de servicio subyacen-ing para evolucionar de manera más
independiente.
• El diseño de servicios para su reutilización implica un alto nivel de
interoperabilidad necesaria entre el servicio y numerosos consumidores
potenciales del servicio.
 • Al elevar un servicio's autonomía individual, su comportamiento se vuelve más
consis-tently predecible, aumentando su potencial de reutilización y por lo tanto
su nivel posible de interoperabilidad.
• A través de un énfasis en el diseño sin estado, la disponibilidad y escalabilidad
de aumento Serv-hielos, lo que les permite interoperar con más frecuencia y de
forma fiable.
4.2 Problemas que resuelve la Orientación a Servicios

• Servicio Discoverability simplemente permite que los servicios sean más

fácilmente localizados por los que quieren interactuar potencialmente con ellos.
• Finalmente,para que los servicios sean efectivamente componibles que deben ser
interoperables. El éxito del cumplimiento de los requisitos componibilidad a menudo
se vincula directamente con el grado en que los servicios están estandarizados y el
intercambio de datos entre servicios está optimizado.
Un objetivo fundamental de la aplicación de la orientación a servicios es para la
interoperabilidad para convertirse en un sub-producto natural,Lo ideal sería que en la
medida en que un nivel de interoperabilidad intrínseca se estab-ció como una
característica de diseño de servicio común y esperado. Dependiendo de la estrategia
archi-tectural siendo empleado, esta medida puede o no puede estar limitada a un
inventario de servicios específicos.
Por supuesto, Al igual que con cualquier otra característica de diseño,hay niveles de
interoperabilidad de un servicio puede alcanzar. La última medida se determina
generalmente por el grado en que los principios de orientación a servicios han sido
consistentemente y con éxito dado cuenta (además, por supuesto, factores ambientales
tales como la compatibilidad de los protocolos de alambre, el nivel de madurez de la
plataforma tecnológica subyacente, y la adhesión a los estándares de tecnología).

NOTA
El aumento de la interoperabilidad intrínseca es uno de los objetivos
estratégicos clave Associ-ado con computación orientada a servicios
(según lo establecido originalmente en el Capítulo 3). Para obtener
información más detallada acerca de cómo los principios de orientación a
servicios apoyan directamente este y otros objetivos estratégicos, véase
el capítulo 16.

Resumen de puntos clave

• El paradigma de la orientación a servicios consiste en ocho principios de
diseño distintos, cada uno de los cuales fomenta características
 fundamentales de diseño, tales como interoperabilidad-capacidad. Estos
principios se exploran de forma individual en los capítulos siguientes.

• La interoperabilidad es un subproducto natural de la aplicación de los

principios de diseño de orientación a servicios.

4.2 Problemas que resuelve la Orientación a Servicios

Para apreciar mejor la razón por la voluntad de servicio ha surgido y cómo está
destinada a mejorar el diseño de los sistemas de automatización,tenemos que
comparar antes y después de per-perspec-. Mediante el estudio de algunos de los
problemas comunes que han afectado históricamente, podemos empezar a entender
las soluciones propuestas por este paradigma de diseño.
76 Capítulo 4: Orientación a
Servicios

NOTA
Este libro reconoce plenamente que últimos paradigmas de diseño tienen
principios similares ADVO-cado y los objetivos estratégicos como la
voluntad de servicio. Varios de estos enfoques de diseño, de hecho,
directamente inspirada o influenciados serv-hielo-orientación (tal como se
explica adicionalmente en los orígenes e influencias de la sección Ser-
vice-Orientación de este capítulo). En la siguiente sección se centra
específicamente en una comparación con el enfoque de diseño basado
en silos porque ha persistido como el medio más común por el cual se
entregan Applica-ciones.

La vida antes de la Orientación a Servicios

En el mundo de los negocios que hace una gran dosis de sentido para ofrecer
soluciones capaces de automatizar la ejecución de tareas de negocios. En el
transcurso de TI's historia, la mayoría de estas soluciones se han creado con un
enfoque común de la identificación de las tareas de la empresa para ser
automatizado, definir sus requisitos de negocio, y luego la construcción de la lógica
solución cor-responder (Figura 4.4).

Figura 4.4
Una proporción de una solicitud para cada nuevo conjunto de requisitos de
automatización ha sido común.
Este ha sido un enfoque aceptado y comprobado para lograr beneficios tangibles a
través del uso de la tecnología y ha tenido éxito en proporcionar un retorno
relativamente predecible de pre-inversión (Figura 4.5).
4.2 Problemas que resuelve la Orientación a Servicios

Figura 4.5
Una fórmula de ejemplo para el cálculo de ROI se basa en una
la inversión predeterminada con un rendimiento predecible.

La capacidad de obtener cualquier valor más lejos de estas aplicaciones suele ser
inhibido debido a que sus capacidades están vinculados a los requisitos específicos
del negocio y procesos (algunos de los cuales incluso tienen una vida útil limitada).
Cuando los nuevos requisitos y procesos en nuestro camino, nos vemos obligados a
bien hacer cambios significativos a lo que ya tenemos, o puede que tenga que
construir una nueva aplicación por completo.
En este último caso, A pesar de que en repetidas ocasiones la construcción
“aplicaciones desechables” no es el enfoque por-fect,que ha demostrado ser un
medio legítimo de la automatización de negocio. Dejar's explorar algunas de las
lecciones aprendidas por primera centrarse en lo positivo.
• Las soluciones pueden ser construidos de manera eficiente, ya que sólo tienen
que preocuparse con el cumplimiento de un conjunto limitado de requisitos
asociados con un conjunto limitado de procesos Busi-ness.
• El esfuerzo de análisis de negocios implicado con la definición del proceso a
automatizar es sencillo. Los analistas se centran sólo en un proceso a la vez y
por lo tanto sólo se preocupan por las entidades empresariales y dominios
asociados a que un proceso.
• diseños de soluciones se centran tácticamente. Aunque a veces se requieren
soluciones de automatización complejas y sofisticadas,con el único propósito de
cada uno es para auto-compañero de sólo uno o un conjunto específico de
procesos de negocio. Este alcance funcional predefinido simplifica el diseño de
la solución global, así como la arquitectura de la aplicación subyacente.
78 Capítulo 4: Orientación a
Servicios

• El ciclo de vida de la entrega del proyecto para cada solución es más sencillo y
relativamente pre-predecible. Aunque los proyectos de TI son conocidos por ser
los esfuerzos complejos, plagado de desafíos imprevistos, cuando está bien
definido el alcance de entrega (y doesn'cambio t), el proceso y la ejecución de
las fases de entrega tienen una buena oportunidad de ser llevado a cabo como
se esperaba.
• La construcción de nuevos sistemas a partir de cero permite a las organizaciones
aprovechar los últimos avances tecnológicos. El mercado de las tecnologías
avanza cada año en la medida en que nosotros plena confianza en la tecnología
que utilizamos para construir la lógica solución que hoy sea diferente y mejor
mañana. Como resultado, organizaciones que construyen aplicaciones repetidas
ocasiones desechables pueden aprovechar las últimas innovaciones tecnológicas
con cada nuevo proyecto.
Estas y otras características comunes de la entrega de soluciones tradicionales
proporcionan una buena indicación de por qué este enfoque ha sido tan popular. A
pesar de su aceptación, aunque, se ha hecho evidente que todavía hay mucho
espacio para la mejora.

Puede ser altamente derrochador

La creación de nueva lógica solución en una empresa dada comúnmente resulta en
una cantidad signifi-cant de funcionalidad redundante (Figura 4.6). Por lo tanto, el
esfuerzo y los gastos necesarios para la construcción de esta lógica es también
redundante.
 Figura 4.6
Diferentes aplicaciones desarrolladas de forma independiente puede dar lugar
a cantidades significativas de funcionalidad redundante. Las aplicaciones
mostradas fueron entregados con varios niveles de la lógica solución que, de
alguna forma, ya existían.

4.2 Problemas que resuelve la Orientación a Servicios

No es tan eficiente como aparece

Debido al enfoque táctico en la entrega de soluciones para las necesidades
específicas del proceso,el alcance de los proyectos de desarrollo se apunta
altamente. Por lo tanto,existe la constante per-cepción de que los requisitos de
negocio se cumplan en el menor tiempo posible. Sin embargo, mediante la
construcción continua y la reconstrucción de la lógica que ya existe en otros lugares ,
el proceso no es tan eficiente como podría ser si la creación de la lógica redundante
podría evitarse (Figura 4.7).

Figura 4.7
Una aplicación fue entregado por un conjunto específico de los
requerimientos del negocio. Debido a que un subconjunto de estos
requisitos de negocio ya había sido ful - lleno otra parte, el volumen de
suministro de Aplicación A es mayor de lo que tiene que ser.

Es una Empresa Bloats

Cada aplicación nueva o ampliada se suma a la mayor parte de un entorno de
TI'inventario del sistema s (Figura 4.8). El alojamiento en constante expansión,
mantenimiento, y las demandas de administración pueden inflar un departamento de
TI en el presupuesto, recursos, y el tamaño en la medida en que se convierte en una
merma importante de la organización en general.
Figura 4.8
Este diagrama simple retrata un entorno de empresa que contiene solicitu
des-cationes con funcionalidad redundante. El efecto neto es una
empresa más grande.
80 Capítulo 4: Orientación a
Servicios

Puede dar lugar a infraestructuras complejas y complicada Enterprise Architectures

Tener que albergar numerosas aplicaciones construidas a partir de diferentes
generaciones de tecnologías y tal vez incluso diferentes plataformas tecnológicas a
menudo requiere que cada uno imponer requisitos arquitectónicos únicos. La
disparidad a través de estos“silos” aplicaciones pueden dar lugar a un entorno de
contra-federados (Figura 4.9), haciendo difícil planificar la evolución de una empresa y
escalar su infraestructura en respuesta a esa evolución.

Figura 4.9
Diferentes entornos de aplicación dentro de la misma empresa pueden
introducir plataformas de tiempo de ejecución incompatibles como se indica
por las zonas sombreadas.

La integración se convierte en un desafío constante

Las aplicaciones creadas sólo con la automatización de procesos de negocio
específicos en mente por lo general no están diseñados para dar cabida a otros
requisitos de interoperabilidad. Hacer estos tipos de datos compartir aplicaciones en
algunos resultados punto posterior en una selva de arquitecturas de integración
convo-cementada mantenidas juntas principalmente a través de patchwork punto-a-
punto (Figura 4.10) o que requieren la introducción de capas de middleware grandes.
4.2 Problemas que resuelve la
Orientación a Servicios 81

Figura 4.10
Una empresa independiente del proveedor diverso puede introducir una
variedad de desafíos de integración, según lo expresado por los pequeños
relámpagos que ponen de relieve los puntos de preocupación cuando se
trata de tender un puente sobre entornos propri-etario.

La Necesidad de la Orientación a Servicios

Después de repetidas generaciones de soluciones distribuidas tradicionales,la
gravedad de los problemas Previ-ormente descrito se ha amplificado. Esta es la razón
por la voluntad de servicio fue con-concebido. Representa mucho más que un estado
evolutivo en la historia de TI, ya que combina elementos de diseño de éxito de los
enfoques anteriores con nuevos elementos de diseño que aprovechan la innovación
conceptual y la tecnología.
La aplicación coherente de los ocho principios de diseño que figuran los resultados
anteriores en la proliferación de amplia difusión de las características de diseño
correspondientes:
• aumento de la consistencia en cómo se representa la funcionalidad y datos
• dependencias reducidos entre las unidades de la lógica solución
• reducción de la conciencia de la lógica subyacente solución de diseño e
implementación detalles
• aumento de las oportunidades de utilizar una pieza de la lógica solución para
múltiples propósitos

• aumento de las oportunidades para combinar unidades de lógica

solución en diferentes configuraciones
82 Capítulo 4: Orientación a
Servicios

• aumento de la previsibilidad del comportamiento

• mayor disponibilidad y escalabilidad
• una mayor conciencia de la lógica solución disponible
Cuando estas características existen como partes reales de los servicios
implementados,establecen una sinergia común. Como resultado, la complexión de la
empresa cambia como las siguientes calidades distintas se promueve
constantemente:

Agnóstico mayores cantidades de solución lógica

Dentro de una solución orientada a servicios,unidades de la lógica (servicios)
encapsulan funcionalidad no específica para cualquier aplicación o negocio proceso
(Figura 4.11). Estos servicios son no-plano clasificados como activos de TI agnósticos
y reutilizables.

Figura 4.11
Los procesos de negocio están automatizados mediante una serie de servicios
específicos de los procesos de negocio (capa superior) que comparten un conjunto de
servicios de procesos de negocio agnóstica (capa inferior). Estas capas corresponden a
los modelos de tarea, entidad y de servicios públicos descritos en el Capítulo 3.

Las cantidades reducidas de lógica específica de la aplicación

Aumentar la cantidad de lógica solución no específica a cualquier proceso de una
aplicación o de negocios disminuye la cantidad de la lógica específica de la aplicación
requerida (Figura 4.12). Este difumina las líneas entre entornos de aplicación
independiente mediante la reducción de la cantidad global de aplicaciones
independientes. (Véase también la Orientación a Servicios y el concepto de la sección
“Aplicación” más adelante en este capítulo).
4.2 Problemas que resuelve la Orientación a Servicios 83

Figura 4.12
Business Process A puede ser automatizado por cualquiera de Aplicación A o
composición de servicios A. La entrega de Aplicación A puede resultar en un
cuerpo de la lógica solución que es específico de y adaptado para el proceso de
negocio. Servicio de Composición A sería diseñado para automatizar el proceso
con una combinación de servicios agnóstico y 40% de la lógica adicional
específica para el proceso de negocio.

El volumen reducido de la lógica general

La cantidad global de la lógica solución se reduce debido a que la misma lógica
solución es compartida y reutilizada para automatizar múltiples procesos de negocio,
como se muestra en la Figura 4.13.
Figura 4.13
La cantidad de la lógica solución se encoge como
una empresa transiciones hacia una Normaliza-
inventario de servicios dardized compuesta de
servicios “normalizados”.
84 Capítulo 4: Orientación a
Servicios

La interoperabilidad inherente
características de diseño común aplicada consistentemente resultado en la lógica
solución que es naturalmente alineado. Cuando esto se traslada a la estandarización
de los contratos de servicios y sus modelos de datos subyacentes, un nivel de base
de la interoperabilidad automática se logra a través de servicios,como se ilustra en la
Figura 4.14. (Véase también la Orientación a Servicios y el concepto de la sección
“Integración” más adelante en este capítulo).

Figura 4.14
Los servicios de diferentes partes de un inventario de servicios se pueden combinar en
nuevas composiciones. Si estos servicios están diseñados para ser intrínsecamente
interoperable, el esfuerzo para ensamblarlas en nuevas configuraciones de composición
se reduce significativamente.

Resumen de puntos clave

• El enfoque tradicional basado en silos de aplicaciones edificio ha sido Suc-
cessful a proporcionar beneficios tangibles y medibles retornos de la
inversión.

• Este enfoque también ha causado su cuota de problemas, sobre todo un

aumento de la complejidad de la integración y un aumento en el tamaño y la
carga ADMINISTRA-tivo de las empresas de TI.
 • La voluntad de servicio establece un paradigma de diseño que aprovecha y se
basa en los enfoques anteriores y propone una forma de evitar problemas
aso-ciados con la entrega de aplicaciones basado en silos.
4.3 Desafíos introducidas por la Orientación a Servicios

4.3 Desafíos introducidas por la Orientación a Servicios

Por más que la voluntad de servicio puede resolver algunos de los más importantes
histórico prob-blemas en TI,su aplicación en el mundo real puede hacer que algunas
imposiciones graves. Es nec-Essary a tener en cuenta estos desafíos antes de tiempo
debido a que está preparando es clave para superarlos.

diseño Complejidad
Con un énfasis constante en la reutilización, un porcentaje significativo de un
inventario de servicios en última instancia, puede estar compuesta de los servicios
agnósticos capaces de cumplir los requisitos para programas de consumo potencial
de servicio mul-tiple.
Aunque esto puede establecer una arquitectura altamente normalizado y simplificado,
También puede introducir un mayor nivel de complejidad, tanto para la arquitectura,
así como diseños de servicios individ-ual.
Ejemplos incluyen:

• aumento de las necesidades de rendimiento resultantes de la mayor reutilización

de los servicios agnósticos
• problemas de fiabilidad de los servicios en tiempos de uso y los problemas de
disponibilidad de los servicios concurrentes pico fuera del horario
• punto único de problemas de errores introducida por la reutilización excesivo de
los servicios agnósticos (y que puede requerir la necesidad de implementaciones
redundantes para mitigar los riesgos)

• una mayor demanda de servicios de alojamiento ambientes para acomodar las

preferencias relacionadas con la autonomía
• servicio de los problemas de versiones del contrato y el impacto de los contratos
de servicio potencialmente redundantes
problemas de diseño de este tipo pueden ser dirigidas por una combinación de la
tecnología de sonido diseño de la arquitectura, moderna tecnología de plataforma de
ejecución proveedor,y la aplicación coherente de los principios de diseño de
orientación a servicios. Solución de problemas y la fiabilidad del servicio per-formance
en particular, son objetivos principales de esos principios de diseño más centrado en
la lógica de servicio subyacente, como servicio Autonomía, apatridia servicio, y
Servicio Compuestabilidad.
86 Capítulo 4: Orientación a
Servicios

La necesidad de estándares de diseño

Las normas de diseño puede ser saludable para una empresa en la que se “pre-
solve” problemas al hacer varias decisiones para arquitectos y desarrolladores de
antemano,de este modo Increas-ing la consistencia y compatibilidad de los diseños de
soluciones. Su uso se requiere con el fin de darse cuenta de la propagación exitosa
de la voluntad de servicio.
A pesar de que puede ser un proceso fácil para crear estas normas,incorporándolos
en una cultura (no estandarizado) de TI se haya definido en sus formas puede ser
exigente para decir lo menos. El uso de estándares de diseño puede introducir la
necesidad de hacer valer su com-pliance,un papel de policía que puede encontrar
resistencia. Adicionalmente, arquitectos y debuta de Ircops veces sienten que las
normas de diseño inhiben su creatividad y capacidad de innovación.
Una circunstancia que tiende a facilitar la realización a gran escala de la normalización es
cuando la iniciativa SOA es defendido por un gerente ejecutivo,tal como un CIO. Cuando
un indi-viduo o un órgano de gobierno tiene la autoridad para esencialmente“ser
autoritario,”muchas de estas cuestiones culturales se resuelven con mayor rapidez. sin
embargo, dentro de las organizaciones basadas en las estructuras departamentales a nivel
de pares (que son más comunes en el sector público), la aceptación de las normas de
diseño puede requerir la negociación y el compromiso.
La mejor arma para superar la resistencia cultural a los estándares del diseño es
communica-ción y la educación. Esos esfuerzos de normalización que resisten son
más propensos a convertirse en seguidores después de obtener una apreciación de la
importancia estratégica y beneficios finales de la adopción y respetando la necesidad
de normas de diseño.

Requisitos de arriba hacia abajo

Una estrategia preferida para la prestación de servicios es conceptualizar un primer
inventario de servicios mediante la definición de un modelo de todos los servicios
previstos, sus relaciones, límites,y modelos de servicio indi-viduo. Este enfoque está
muy asociada con una estrategia de entrega de arriba hacia abajo, ya que puede
imponer una cantidad significativa de esfuerzo de análisis por adelantado la
participación de muchos miembros de análisis de negocio y de tecnología de grupos
de arquitectura.
aunque prefiere,la consecución de un plan integral antes de servicios de construcción
a menudo no es factible. Es común que las organizaciones se enfrentan a limitaciones
de tiempo y presupuesto y las prioridades tácticas que simplemente ganaron't lo
permiten. Como resultado,hay por etapas y de resultados iter-ativa que permiten que
los servicios sean producidos anteriormente. Estas, sin embargo,a menudo vienen
con ventajas y desventajas en cuanto que pueden requerir los servicios de diseños
debería examinar y modificar en un momento posterior. Si bien esto puede introducir
riesgos asociados con
4.3 Desafíos introducidas por la Orientación a Servicios

la implementación de diseños de servicios prematuros, A menudo se considera un

compromiso aceptable.
Los principios de la orientación a servicios se pueden aplicar a los servicios sobre una
base individual,permitiendo un grado razonable de la voluntad de servicio que deben
alcanzarse independientemente del enfoque. sin embargo, la calidad real de los
diseños de servicio resultantes es típicamente ligada a la cantidad de trabajo de
análisis de arriba hacia abajo se completó antes de su entrega.

MEJORES PRÁCTICAS
Se recomienda que, como mínimo, un modelo inventario de servicios de alto nivel
siempre puede ser definido antes de la creación de contratos de servicio físicas. Esto
establece una importante perspectiva “más amplia” en apoyo de análisis orientada a
servicios y procesos de modelado de servicios y, en última instancia, resulta en
diseños de servicios más fuertes y más duraderas.

Counter-ágil prestación de servicios en apoyo a la solución ágil de entrega

Independientemente de los posibles esfuerzos de arriba hacia abajo necesarios para
algunos proyectos SOA, las consideraciones de diseño adi-cional necesarios para
implementar una medida significativa de cada uno de los ocho principios de diseño
aumenta tanto el tiempo y el coste de entregar lógica de servicio.
Esto puede parecer contrario a la atención SOA ha recibido por su capacidad para
aumentar la agilidad. Para alcanzar el estado de agilidad de la organización se
describe en el capítulo 3 requiere que la voluntad de servicio ya aplicarse con éxito.
Esto es lo que establece un entorno en el que la entrega de soluciones es mucho más
ágil.
sin embargo, teniendo en cuenta que se necesita un esfuerzo más inicial para diseñar
y construir los servicios que lo hace para construir una cantidad correspondiente de la
lógica que no está orientada a servicios,el proceso de entrega de servicios en apoyo
de SOA en realidad puede ser contraproducente ágil. Esto puede causar problemas
para una organización que tiene requerimientos tácticos o debe ser reactivo, mientras
que la acumulación de ing un inventario de servicios.

MEJORES PRÁCTICAS
Un enfoque eficaz, cuando se dispone de recursos suficientes, es permitir que las
iniciativas de SOA que se entregarán junto con los proyectos de desarrollo y
mantenimiento legado existentes. De esta manera, los requerimientos tácticos puede
seguir cumpliéndose por aplicaciones tradicionales, mientras que la empresa trabaja
hacia una transición gradual hacia la computación orientada a servicios.
Apéndice B proporciona una cobertura adicional de las estrategias de ejecución SOA
que abordan tacti en calorías en comparación con las necesidades estratégicas de
prestación de servicios.
88 Capítulo 4: Orientación a
Servicios

las exigencias de administración

La existencia eventual de uno o varios inventarios de servicios representa el último
deliv-erable de la iniciativa típica SOA a gran escala. Un inventario de servicio
establece una reserva de energía ful de la lógica solución estandarizada,un alto
porcentaje de los cuales, idealmente, ser clasificado como agnóstico o reutilizables.
Con posterioridad a su puesta en práctica, aunque, el hombre-agement y la evolución
de estos servicios agnósticos pueden ser responsables de algunos de los cambios
más profundos impuestas por la voluntad de servicio.
En el pasado,una aplicación independiente se desarrolla normalmente por un solo
equipo de proyecto. Los miembros de este equipo a menudo terminaban
restante“adjunto” a la aplicación para actualizaciones sub-secuente, mantenimiento,y
extensiones. Este modelo de propiedad funcionó porque la aplicación's propósito
general y el alcance siguió centrada en las tareas de la empresa que fue construido
originalmente para automatizar.
El cuerpo de la lógica solución representada por servicios agnóstico, sin embargo,está
colocado intencionadamente para no pertenecer a cualquier proceso de un solo negocio.
Aunque estos servicios pueden haber sido entregado por un equipo de proyecto, ese
mismo equipo puede no continuará en poder de la lógica de servicio, ya que se utiliza en
repetidas ocasiones por otras soluciones, procesos, y composiciones.
Por lo tanto,Se requiere una estructura de gobierno especial. Esto puede introducir nuevos
recursos, papeles, procesos,e incluso nuevos grupos o departamentos. Por último, cuando
estas cuestiones están bajo control y el propio entorno de TI ha adaptado con éxito a los
cambios requeridos,los muchos beneficios asociados con esta nueva plataforma de
computación están ahí para tomar. sin embargo, el proceso de pasar a este nuevo modelo
de gobierno puede desafiar a los enfoques tradicionales y el tiempo de la demanda,
gastos, y una gran dosis de paciencia.

Resumen de puntos clave

• La aplicación de la voluntad de servicio a gran escala puede introducir una
mayor complejidad del diseño y la necesidad de un nivel constante de
normalización.

• La construcción de los servicios puede ser costoso y consume mucho

tiempo,-presen tación del ciclo de vida de un proyecto de entrega más
 gravosa, agravado aún más por algunos de los requisitos de análisis top-
down comunes que puede que tenga que estar en su lugar antes de los
servicios pueden ser construidos.

• requerimientos de control de inventario de servicios pueden imponer

cambios significativos que pueden sacudir la estructura organizativa de un
departamento de TI.
4.4 Consideraciones adicionales

4.4 Consideraciones adicionales

Para complementar los beneficios y retos acabamos de cubrir, esta sección se
discuten algunos aspectos de pieles-tros de la voluntad de servicio.

No es un paradigma revolucionario
La voluntad de servicio no es un nuevo paradigma marca que apunta a reemplazar
todo lo que le precedió. Eso, de hecho, incorpora y se basa en elementos probados y
exitosos de los paradigmas del pasado y las combina con enfoques de diseño en
forma de aprovechar las últimas innovaciones tecnología-logía.
Es por esto que no nos referimos a SOA como un modelo revolucionario en la historia de
la misma. Es sim capas de la siguiente etapa de un ciclo evolutivo que se inició con la
aplicación de modular-dad a pequeña escala (mediante la organización de rutinas de
programación simples en módulos compartidos por ejemplo) y ahora se ha extendido a la
modularización potencial de la empresa.

La normalización de toda la empresa no se requiere

Hay una percepción errónea de que a menos que la estandarización del diseño se
logra Glob-aliado a lo largo de toda la empresa,SOA no tendrá éxito. Aunque el diseño
estándar-ización es un factor crítico de éxito para los proyectos de SOA que se logra
de manera ideal en toda la empresa, sólo necesita ser realizada en una medida
significativa para la orientación a servicios resulte en beneficio estratégico.
Por ejemplo,la voluntad de servicio hace hincapié en la necesidad de estandarizar los
modelos de datos de servicios para evitar la transformación de datos innecesarios y
otras cuestiones problemáticas que pueden comprometer la interoperabilidad. La
medida en que la normalización modelo de datos se consigue determina la medida en
que se pueden evitar estos problemas.
El objetivo no es siempre para eliminar por completo los problemas ya que puede ser un
objetivo poco realista,especialmente en las grandes empresas. Por lo tanto, el objetivo es
a veces sólo problemas mini-Mize, tomando en cuenta consideraciones especiales durante
el diseño del servicio.
En apoyo de este enfoque,Existen patrones de diseño para la organización de la
división de un premio entrar en los dominios más manejables. normalización de los
datos se alcanza generalmente más fácilmente dentro de cada dominio,y la
transformación es entonces sólo requiere datos a través de estos dominios cuando
exchang-ción. A pesar de que este no lograr un modelo de datos global, todavía
puede ayudar a establecer un nivel muy significativo de la interoperabilidad.
90 Capítulo 4: Orientación a
Servicios

La reutilización no es un requisito absoluto

El aumento de la reutilización de la lógica solución es un objetivo fundamental de la
orientación a servicios,y la reutilización es claramente uno de los beneficios más
asociados de SOA. Como resultado, organizaciones que han tenido un éxito limitado
con las iniciativas de reutilización últimos, o con la preocupación de que cantidades
significativas de reutilización no se pueden alcanzar dentro de su empresa, son a
menudo reticentes acerca de SOA en general.
mientras reutilización, en especial a través del tiempo, puede ser una de las partes
más gratificantes de la inversión en SOA,no es el único beneficio primario. Tal vez
incluso más fundamental para la orientación a servicios de fomento de la reutilización
está fomentando la interoperabilidad. Activación de una empresa para conectar los
sistemas anteriormente dispares o para hacer interconectividad una cualidad
intrínseca de nueva lógica solución es extremadamente potente.
Se podía pasar por alto el principio de servicio Reutilización de diseños de servicio y
aún así lograr un retorno significativo de la inversión basadas exclusivamente en
incrementar el nivel de interoperabilidad en toda la empresa.

NOTA
Se podría argumentar que la reutilización y la interoperabilidad están muy
estrechamente relacionados en que si dos servicios son interoperables,
siempre existe la oportunidad para su reutilización. Sin embargo, las
perspectivas tradicionales de la lógica solución reutilizable se centran en
la naturaleza de la lógica misma. Un servicio que está diseñado para ser
específi-camente agnóstico para procesos de negocio y transversal para
abordar las preocupaciones multi-PLE tendrá un contexto funcional
particular asociado con él. Por lo tanto, la reutilización puede ser visto
como una característica de diseño independiente que se apoya y se basa
en la interoperabilidad. Véase el capítulo 9 para más detalles.

Resumen de puntos clave

• La voluntad de servicio tiene raíces profundas en varias plataformas
informáticas y enfoques de diseño pasado, y por lo tanto no se considera
un paradigma de diseño revolucionario.

• La estandarización global dentro de una empresa no es un requisito para la

creación de empresas orientadas al servicio porque los inventarios de
 servicios individuales se pueden establecer (y por separado estandarizado)
dentro de diferentes dominios empresariales.

• Aunque fundamental para gran parte de la voluntad de servicio, si la

reutilización fuese omitido como una característica de diseño, significativos
beneficios relacionados con la interoperabilidad, todavía sería posible.
4.5 Efectos de la Orientación a Servicios a la empresa

4.5 Efectos de la Orientación a Servicios a la empresa

Hay buenas razones para tener altas expectativas de la orientación a servicios para-
digma. Pero, al mismo tiempo,hay mucho que aprender y comprender antes de que se
pueden aplicar Suc-cessfully. Las secciones siguientes exploran algunos de los ejemplos
más comunes.

Orientación a Servicios y el concepto de “aplicación”

Habiendo declaró que la reutilización no es un requisito absoluto,es importante
ACKNOWL-Edge el hecho de que la voluntad de servicio no poner un énfasis sin
precedentes en la reutilización. Mediante el establecimiento de un inventario de
servicios con un alto porcentaje de Serv-hielos reutilizables y agnósticos, ahora
estamos posicionando dichos servicios como el principal (o única) medios por los que
la lógica solución que representan puede y debe accederse.
Como resultado,hacemos un movimiento muy deliberada de distancia de los silos de
aplicaciones existentes anteriormente. Porque queremos compartir la lógica
reutilizable siempre que sea posible, nos auto-compañero existente, nuevo,y
aumentada procesos de negocio a través de la composición de servicios. Esto se
traduce en un cambio cuando se cumplan los requisitos cada vez más negocios no
mediante la construcción o la ampliación de las aplicaciones, sino simplemente la
composición de los servicios existentes en nuevas configuraciones de composición.
Cuando las composiciones se vuelven más comunes, el concepto tradicional de una
aplicación, un sistema, o una solución realmente comienza a desvanecerse,junto con
los silos que los contienen. Las aplicaciones ya no consisten en cuerpos autónomos
de la lógica de programación responsa-ble para la automatización de un conjunto
específico de tareas (Figura 4.15). Lo que era una aplicación es ahora más que otra
composición de servicios. y'composición sa compuestos de servicios que muy
probablemente participan en otras composiciones (Figura 4.16).
Figura 4.15
La aplicación tradicional, entregado para automatizar la lógica específica de procesos de
negocio.
92 Capítulo 4: Orientación a
Servicios

Figura 4.16
La composición de servicios, destinado a cumplir el papel de la aplicación tradicional mediante el
aprovechamiento de los servicios agnósticos y no agnóstico de un inventario de servicios. Esto establece
esencialmente una “aplicación compuesta.”

Una aplicación en este entorno pierde su individualidad. Se podría argumentar que

una aplicación serv-orientado de hielo en realidad no existe, ya que es, de hecho,sólo
una de las muchas composiciones de servicios. sin embargo, después de una
reflexión más cerca,podemos ver que algunos de los serv-hielos en realidad no son
negocio proceso de agnóstico. El servicio de tareas, por ejemplo, intención aliado
representa la lógica que se dedica a la automatización de una sola tarea negocio y
por lo tanto no es necesariamente reutilizable.
Lo que esto indica es que los servicios no agnósticos todavía pueden estar asociados
con la noción de una aplicación. sin embargo, dentro de computación orientada a
servicios, el significado de este término puede cambiar para reflejar el hecho de que
un potencialmente gran parte de la lógica de la aplicación ya no es exclusivo de la
aplicación.

Orientación a Servicios y el concepto de “integración”

Cuando volvamos a la idea de un inventario de servicios que consta de servicios que
tienen, de acuerdo con nuestros principios de orientación a servicios, ha formado en
unidades reutilizables estandarizados y (en su mayor parte) de la lógica solución,
podemos ver que esto puede desafiar el tradicional per-cepción de “integración.”
En el pasado,integrando algo implícita la conexión de dos o más aplicaciones o pro-
gramas que pueden o no pueden haber sido compatible (Figura 4.17). Tal vez
estaban basadas en diferentes plataformas tecnológicas o tal vez nunca fueron
diseñados para conectar con cualquier cosa fuera de su propio límite interno. La
creciente necesidad de conectar piezas dis-dispares de software para establecer un
nivel de intercambio de datos fiable es lo que resultó integración en un importante,
parte alta perfil de la industria de TI.
4.5 Efectos de la
Orientación a
Servicios a la
empresa 93

Figura 4.17
La arquitectura de integración tradicional, compuesta de dos o más
aplicaciones conectadas en diferentes formas para alcanzar un nuevo
conjunto de requisitos de automatización (según lo dictado por el nuevo
proceso de negocio G).

Servicios diseñados para ser “intrínsecamente interoperable” están construidos con la

plena conciencia de que van a necesitar para interactuar potencialmente con una
amplia gama de consumidores de servicios,mayoría de los cuales será desconocida
en el momento de su entrega inicial. Si una parte significativa de nuestra lógica
solución empresarial está representado por un inventario de los servicios
interoperables intrínsecamente, que nos da el poder con la libertad de mezclar y
combinar estos servicios en configuraciones infinitas composición para cumplir con lo
requisitos de automatización se cruzan en nuestro camino.
Como resultado,el concepto de integración comienza a desvanecerse. El intercambio de
datos entre diferentes unidades de lógica solución se convierte en una característica de
diseño natural y secundaria (Figura 4.18). De nuevo, aunque, esto es algo que sólo puede
ocurrir cuando un substancial por-centaje de una organización'lógica resolutiva s está
representado por un inventario de servicios de calidad.
94 Capítulo 4: Orientación a
Servicios

Mientras se trabaja hacia el logro de este entorno, es probable que haya muchos
requieren-mentos para la integración tradicional entre los sistemas existentes y
también entre los sistemas heredados y estos servicios.

Figura 4.18
Una nueva combinación de servicios se compone en
conjunto para cumplir con el papel de las aplicaciones
integradas tradicionales.

La composición de servicios
aplicaciones, aplicaciones integradas, soluciones, sistemas,todos estos términos y lo
que han representado tradicionalmente se puede asociar directamente con el servicio
de composi-ción (Figura 4.19). sin embargo, dado el hecho de que muchas
implementaciones de SOA consisten en una mezcla de ambientes y servicios
heredados, estos términos están seguros de sobrevivir durante bastante tiempo.
De hecho, como iniciativas de transición SOA siguen progresando dentro de una
empresa, puede ser útil hacer una clara distinción entre una aplicación tradicional (uno
que puede residir junto a una implementación de SOA o que puede estar encapsulado
en realidad por un servicio) y las composiciones de servicios que con el tiempo cada
vez más frecuentes.
4.5 Efectos de la Orientación a Servicios a la empresa

Figura 4.19
A orientada al servicio solución, la aplicación o sistema
es el equiva-prestado de una composición servicio. Si
tuviéramos que construir un Empresa-
amplia SOA desde el principio, es probable que se compone de
numerosas composiciones servicio que debe cumplir el tradicional
roles asociados con estos términos.

Aplicaciones, integración y arquitecturas empresariales

Dado que las aplicaciones han existido durante tanto tiempo como TI, cuando la
arquitectura de tecnología como una profesión y perspectiva dentro de la empresa se
produjo, Tiene perfecto sentido para tener vistas arquitectónicas separadas dedicadas
a aplicaciones individuales, integrados solicitu des-cationes, y la empresa en su
conjunto.
Cuando la estandarización de la orientación a servicios,la manera en que se
documenta la arquitectura Technol-gía también está en un cambio. La perspectiva a
nivel de empresa se convierte en pre-dominante, ya que representa una vista maestra
del inventario de servicios. Todavía puede abarcar las partes tradicionales de una
arquitectura formal, incluyendo vistas conceptuales, vistas físicas, y el apoyo a las
tecnologías y plataformas de gobierno, pero todos estos puntos de vista es probable
que ahora se asocian con el inventario de servicios.
Un nuevo tipo de especificación técnica que gana protagonismo en el servicio
orientado a introducir iniciativas-premio es la arquitectura de la composición de
servicios. A pesar de que hablamos de la sim-plicidad de combinar los servicios en
nuevas configuraciones de composición sobre la demanda,que de ninguna manera es
un proceso fácil. Es un ejercicio de diseño que requiere el detalle de la documenta-
ción de la arquitectura de la composición prevista.
Por ejemplo, cada servicio tiene que ser evaluada en cuanto a su capacidad para cumplir
con su papel como miembro composición, y los escenarios de actividad de servicio
previsibles necesitan ser trazado.
96 Capítulo 4: Orientación a
Servicios

diseños de mensajes, rutas de mensajería, manejo de excepciones, transacciones

cruzada de servicios, políticas, y muchos más consideraciones entran la fabricación
de una composición capaz de automatizar su proceso de negocio designado.

MEJORES PRÁCTICAS
Aunque la estructura y el contenido de especificaciones de la arquitectura tradicional de
aplicaciones se aumentan cuando se documentan las arquitecturas de composición,
todavía puede haber una tendencia natural para referirse a estos documentos como
especificaciones de la arquitectura de aplicaciones.
Mientras que una organización está experimentando una transición hacia SOA, puede
ser útil hacer una distinción clara entre una aplicación que consiste en una composición
de servicios y aplicaciones independientes, o de legado tradi-cional.
Un enfoque consiste en calificar sistemáticamente el término “aplicación”. Por ejemplo,
puede tener el prefijo “compuesto”, “independiente”, o “orientada al servicio” “legado”.
Otra opción es la de limitar simplemente el uso del término “aplicación” para referirse a
sólo-ciones Solu compuestos de no-servicio.
Además, un servicio compuesto que encapsula una aplicación heredada puede ser
docu-mentado en las especificaciones separadas: una especificación de arquitectura
composición que identifica el servicio y puntos para una especificación de arquitectura
de la aplicación que define la aplicación corre-pondiente.

Resumen de puntos clave

• El concepto tradicional de una aplicación puede cambiar a medida que
los servicios más agnósticos se convierten en partes establecidas de
la empresa.

• El concepto tradicional de la integración puede cambiar a medida que

la proliferación de servicios interoperables estandarizados intrínsecas,
aumenta.

• vistas arquitectónicas del turno de la empresa en respuesta a la

adopción de la orientación a servicios. Principalmente, la perspectiva
de la empresa se vuelve cada vez más prominente.

4.6 Orígenes e Influencias de la Orientación a Servicios

A menudo se dice que la mejor manera de entender algo es el conocimiento de su his-
toria. La orientación a servicios, de ninguna manera,es un paradigma de diseño que acaba
de salir de la nada. Es en gran medida una representación de la evolución de las TI y por
lo tanto tiene muchos
4.6 Orígenes e Influencias de la Orientación a Servicios

raíces en paradigmas y tecnologías (Figura 4.20) anteriores. Al mismo tiempo, se

encuentra todavía en un estado de evolución en sí y por lo tanto está sujeta a las
influencias de las actuales tendencias y movimientos.

Figura 4.20
Las principales influencias de la orientación a servicios también destacan sus múltiples
orígenes.

Las secciones siguientes describen algunos de los orígenes más importantes y por lo
tanto ayudan a aclarar cómo la voluntad de servicio puede relacionarse con e incluso
ayudar aún más a algunos de los objetivos de los paradigmas del pasado.

La orientación a objetos
En la década de 1990 la comunidad de TI abrazado una filosofía de diseño que
llevaría a la forma en la definición de cómo se iban a construir soluciones distribuidas.
Este paradigma fue objeto-orien-tación, y que venía con su propio conjunto de
principios,la aplicación de que ayudó a asegurar la consistencia a través de
numerosos entornos. Estos principios definen un tipo específico de relación entre las
unidades de la lógica solución clasificados como objetos, lo que resultó en un conjunto
pre-predecible de la dinámica que corría a través de soluciones enteras.
La voluntad de servicio se compara con frecuencia a la orientación a objetos,y con
razón. Los principios y patrones detrás de análisis y diseño orientado a objetos
representan una de las más importantes fuentes de inspiración de este paradigma.
De hecho, un subconjunto de los principios de orientación a servicios (Reutilización de
servicio, Servicio Abstrac-ción, y Compuestabilidad Servicio,por ejemplo) puede ser
rastreado homólogos de nuevo orientado a objetos para. Lo que distingue a la
voluntad de servicio, aunque,son las partes de la escuela orientada a objetos del
pensamiento que quedaron fuera y los demás principios que se han añadido. Véase el
Capítulo 14 para un análisis comparativo de los principios y conceptos asociados con
estos dos enfoques de diseño.
98 Capítulo 4: Orientación a
Servicios

Servicios web
A pesar de que la orientación a servicios como paradigma y SOA como una
arquitectura de tecnología son cada implementación neutral, su asociación con los
servicios Web se ha convertido en un lugar común, tanto es así que los vendedores
SOA primarias han dado forma a sus respectivas formas de plat torno a la utilización
de la tecnología de servicios Web.
A pesar de la voluntad de servicio sigue siendo un paradigma totalmente abstracta,es
uno que ha su-tóricamente sido influenciado por las plataformas SOA y hojas de ruta
producidos por estos dors-Ven. Como resultado, el marco de servicios web ha influido
y ha promovido varios principios de orientación a servicios, incluyendo el servicio de la
abstracción, Servicio de Acoplamiento, y Servicio Compuestabilidad.

Business Process Management (BPM)

BPM pone un énfasis significativo en los procesos de negocio dentro de la empresa
tanto en términos de racionalización lógica de proceso para mejorar la eficiencia y
también para establecer procesos que son adaptables y extensibles para que puedan
ser aumentados en respuesta a los cambios empresariales.
La capa de procesos de negocios representa una parte esencial de cualquier
arquitectura orientada al servicio. Desde una perspectiva de la composición,por lo
general asume el papel del regulador de posición com servicio de los padres. El
advenimiento de la tecnología orquestación reafirmó este papel desde una
perspectiva de implementación.
Un objetivo principal de la voluntad de servicio es establecer un sistema de
automatización medio ambiente se altamente ágil totalmente capaz de adaptarse al
cambio. Este objetivo se puede conseguir mediante la abstracción lógica de proceso
neg-dad en su propia capa, aliviando de ese modo otros servicios de tener que lógica
de proceso incrustar repetidamente.
Si bien la voluntad de servicio en sí no es tan preocupados con la reingeniería de
procesos de negocio, que es totalmente compatible con la optimización de procesos
como una fuente primaria de cambio para el cual los servicios se pueden recomponer.

Enterprise Application Integration (EAI)

La integración se convirtió en un punto focal principal en la tarde del 90's,y muchas
organizaciones se prepararon mal por ello. Numerosos sistemas fueron construidos
con poco pensamiento dado a cómo los datos podrían compartirse fuera de los límites
del sistema. Como resultado, punto-a-punto de integración
4.6 Orígenes e Influencias de la Orientación a Servicios

canales se crean a menudo cuando surgieron los requisitos de intercambio de datos.

Esto dio lugar a problemas bien conocidos asociados con una falta de estabilidad,
extensibilidad, y la insuficiencia de los marcos de interoperabilidad.
plataformas EAI introdujeron middleware que permite a la producción de aplicaciones
propietarias a través del uso de adaptadores, corredores,y motores de orquestación. Las
arquitecturas de integración de Resultados-ción eran, de hecho,más robusto y extensible.
sin embargo, También se hicieron conocidos por ser abrumadoramente complejo y
costoso, además de requerir compromisos a largo plazo con el proveedor de middleware's
plataforma y la hoja de ruta.
El advenimiento del marco de servicios web abierta y su capacidad para la tecnología
totalmente abstracta propri-etario cambiaron la cara de middleware de integración.
lazos de los proveedores podrían ser bro-ken mediante la inversión en servicios
móviles a diferencia de las plataformas propietarias, y organizaciones ganaron más
control sobre la evolución de sus arquitecturas de integración.
Varias innovaciones que se popularizó durante la era EAI fueron reconocidos como útiles
para los objetivos generales relacionados con la construcción de SOA utilizando servicios
Web. Un ejemplo es el componente del intermediario,que permite servicios utilizando
diferentes esquemas que representan el mismo tipo de datos que todavía comunicarse a
través de tiempo de ejecución Transforma-ción. El otro es el motor de orquestación ,que en
realidad puede ser posicionado para representar una capa de servicio entero dentro de las
implementaciones de SOA más grandes. Estas partes de la plataforma de apoyo EAI
varios principios de orientación a servicios, incluyendo el servicio de la abstracción,
apatridia servicio, Servicio de Acoplamiento, y Servicio Compuestabilidad.

Programación Orientada a Aspectos (AOP)

Un objetivo principal de la AOP es acercarse a la separación de las preocupaciones con la
intención de preocupaciones específicas iden-tificar que son comunes a varias
aplicaciones o automatización SCE-narios. Estas preocupaciones se clasifican
como“transversal,” y la lógica de solución correspondiente desarrollado para
preocupaciones transversales se convierte naturalmente reutilizable.
Aspecto orientación surgió de la orientación a objetos basándose en los objetivos
originales de establecimiento de objetos reutilizables. Aunque no es un factor de
influencia principal de servicio orien-tación,AOP sí demuestra un objetivo común en
destacar la importancia de invertir-ción en unidades de lógica resolutiva que son
agnósticos a los procesos de negocio y aplicaciones y por lo tanto altamente
reutilizables. Promueve un mayor desarrollo basado en roles, permitiendo que debuta
de Ircops con diferentes áreas de experiencia para colaborar.
100 Capítulo 4: Orientación a
Servicios

NOTA
Los acontecimientos reales y línea de tiempo asociados con la aparición
de SOA están documentados en el capítulo 4 del libro Arquitectura
Orientada a Servicios: Conceptos, Tecnología y Diseño.

Resumen de puntos clave

• La voluntad de servicio representa un paradigma de diseño que tiene sus
raíces en varios orígenes. Se hace hincapié en los enfoques exitosos y
probados y los complementa con los nuevos principios que aprovechan
reciente innovación conceptual y la tecnología.

• La orientación a servicios, como un paradigma de diseño, es

comparable con la orientación a objetos. De hecho, varios principios
fundamentales orientados a objetos han persistido en la voluntad de
servicio.

• La plataforma de tecnología de servicios Web es el principal responsable de

la popular-dad de SOA y por lo tanto es también una influencia significativa en
la voluntad de servicio. Por el contrario, el aumento de la computación
orientada a servicios se ha reposicionado y formalizado la tecnología de
servicios Web fijar de su encarnación original.
 ESTUDIO Antecedentes 4.7 CASE
Cutit's prioridad inmediata es racionalizar su proceso de cadena de suministro
interno. El proceso de la orden en particular, necesita ser apoyado por los
servicios planificados de manera que las órdenes y copia de las órdenes
pueden ser cumplidas tan pronto como sea posible.
A continuación se presentan breves descripciones de los candidatos de servicio
que se muestran en la Figura 4.21 en rela-ción a la forma en que se relacionan
entre sí en función de sus contextos funcionales entidad centrada en:
• Todo se origina con la fabricación de palas de cadenas en el laboratorio
Cutit, lo que requiere el uso de materiales específicos que se aplican como
por fórmulas PREDE-multados.
• El conjunto de cadenas de resultados en los productos que se añade
a su inventario general.
• sierras y kits son elementos compras Cutit de diferentes fabricantes a com-
plemento sus modelos de cadena.
• Notificaciones necesitar ser emitida cuando los niveles de las acciones caen
por debajo de ciertos niveles o si se producen otras condiciones urgentes.
Antecedentes 4.7 Estudio de caso
 • Finalmente, un barrido de patente periódica se lleva a cabo la
búsqueda de patentes recientemente emitidas con similitudes con
Cutit's diseños cadena planificadas.
Tenga en cuenta que todos los servicios que se muestran son los servicios de la
entidad, con la excepción de barrido de Patentes y Notificaciones,que se basan
en el modelo de servicio público. Una tarea serv-hielo se añade en la Parte II.

Figura 4.21
El conjunto inicial de servicios planificados para apoyar los siguientes tipos de procesos: Hacer un
seguimiento de los pedidos y realizar copias de pedidos, la fabricación en cadena, el seguimiento
de los materiales de fabricación necesarios, y de gestión de inventario de productos fabri-rado y
comprados. Todos los servicios que se muestran se basan en el modelo de servicio de la entidad,
a excepción de los dos inferiores, que son los servicios públicos.
Esta página se ha dejado intencionadamente en
blanco