IBM Software Group

Arquitectura de Procesos de Negocio

Arquitectura de Software y Orientacin a Servicio

2007 IBM Corporation

Arquitectura de Software
Arquitectura de software consiste en las decisiones ms importantes sobre la organizacin de una solucin de software: Seleccin de los elementos estructurales y sus interfaces que componen el sistema Especificacin del comportamiento del sistema como la colaboracin entre los elementos Redaccin de estos elementos estructurales y de comportamiento en subsistemas ms grandes La aplicacin de un estilo arquitectnico que gua esta organizacin

Arquitectura, Diseo y Construccin

Arquitectura implica un conjunto de decisiones estratgicas de diseo, reglas o pautas que limitan el diseo detallado y la construccin.
arquitectura diseo implementacin CDIGO

Las decisiones de arquitectura son las decisiones ms fundamentals, y tienen importantes repercuciones.
3

El Propsito de la Arquitectura
La Arquitectura es til para:
Entender
Simplifica mediante la abstraccin. Proporciona modelos para la solucin. Revela oportunidades de reutilizacin. Expone las reas de riesgo.

Comunicar

Se comunica la informacin clave. Proporciona diferentes puntos de vista o perspectivas. Captura las preocupaciones de todas las partes interesadas. Hace todas las decisiones de diseo explcito y trazable.
Breaks down the work and allows for team development Prescribes all development work to be done Helps establish and maintain consistent style Guides team development
4

Gerenciar

Partes interesadas y Preocupaciones

La Arquitectura proporciona diferentes perspectivas para abordar las preocupaciones de los diferentes grupos de inters
Usuario final Facil integracin Funcional Cliente Venta y Soporte Tcnico Facil uso Facil personalizacin Confiabilidad
Gerente de Desarrollo Precio

Arquitecto

Costos de desarrollo Entrega a tiempo

Mantenimiento

Desarrollador

Funcionamiento y rendimiento Estabilidad y mantenibilidad Facil diagnstico de problemas

Administrador del Sistema

Facil introduccin de modificaciones Testeabilidad y trazabilidad Estructura y dependencia entre partes Facil instalacin
5

Importancia de la Arquitectura OJO TRADUCCION Un enfoque insuficiente en la arquitectura puede llevar a:

Dificultades de Desarrollo
Choque de equipos y falta de coordinacin. La comunicacin es difcil y a menudo, ambigua.

Soluciones de baja calidad

Frgil. Difcil de mantener. De bajo rendimiento. Complejidad abrumadora.

Errores comunes
Los siguientes son los conceptos errneos acerca de la arquitectura:
La arquitectura La arquitectura La arquitectura La arquitectura La arquitectura La arquitectura La arquitectura suficiente. es diseo. es infraestructura. es slo estructura. no puede ser medida o validada. es arte puro. es ciencia pura. es modelo, y un modelo es

Concepto errneo: Arquitectura = Diseo

Diseo es uno de los aspectos de la arquitectura, centrndose en:
Los elementos que son estructuralmente importantes. Los elementos que tienen un impacto duradero en rendimiento, fiabilidad, coste, capacidad de adaptacin, y as sucesivamente..

La arquitectura captura un conjunto importante de las decisiones de diseo. La arquitectura no se preocupa del diseo detallado de los elementos individuales.
8

Concepto errneo: Arquitectura = Infraestructura

Aqui hay ms arquitectura que solo infraestructura La infraestructura es una parte integral e importante de la arquitectura
El aspecto operativo.

La arquitectura tambin define la aplicacin que se ejecuta en la parte superior de la infraestructura

El aspecto funcional

Arquitectura define la interoperabilidad entre la infraestructura y los componentes de la aplicacin.

9

Concepto errneo: Arquitectura = Estructura

La arquitectura es mas que solo estructura
Aspectos dinmicos Justificacin Ajustar al contexto
Contexto de negocios Contexto de desarrollo

La arquitectura tambin incluye la descomposicin, las interfaces, y as sucesivamente.

10

Concepto errneo: Architecture es modelo

La arquitectura es modelo slo en casos muy triviales. La arquitectura tiene muchas dimensiones que representan mltiples preocupaciones de las mltiples partes interesadas. Cuando se utiliza un nico modelo para representar a todos (o la mayora) de estas dimensiones, conducen a la sobrecarga semntica o incompleta. La arquitectura requiere mltiples vistas.

11

Concepto errneo: La arquitectura no se puede medir ni validar

La arquitectura no es un alto nivel de diseo esquemtico, con papel y lpiz Las arquitecturas pueden ser evaluadas sistemticamente contra requisitos funcionales y de calidad, con los riesgos y con los atributos clave del sistema (propiedades del sistema).
Revisin de los artefactos de arquitectura Prueba de prototipos de la arquitectura

12

Concepto errneo: Arquitectura es arte o ciencia

Ciencia Ni uno, ni otro y ni ambos Arte Los mtodos de anlisis son difciles de aplicar Espacio de un problema muy grande con unos criterios de seleccin cuantitativos Buenos arquitectos copian soluciones que han funcionado antes y se renen con modestas mejoras incrementales. El proceso arquitectnico tiene pasos definidos y artefactos prescritos. Un cuerpo de conocimiento est comenzando a ser codificado.

Patrones, marcos, servicios, heurstica, ...

La intuicin y creatividad todava cuentan

13

Estilo arquitectnico
Las arquitecturas evolucionan de estilos arquitectnicos
Un conjunto de supuestos fundamentales o principios rectores. Estilo Definido mediante un Arquitectnico conjunto de patrones de arquitectura. Patrones

Beneficios de estilos arquitectnicos y patrones

Permitir la reutilizacin. Enriquecer el vocabulario arquitectnico.

de Arquitectura

Arquitecturas

14

Patrones Arquitectnicos
Un patrn es una solucin general repetible a un problema que ocurre comnmente en el diseo de software.
Codifica el conocimiento recogido de la experiencia en un dominio. Representa experiencia reutilizable depurada. Simplifica la aceleracin de la arquitectura y el diseo. Reduce el riesgo. Facilita la comunicacin entre los profesionales.
15

Diferentes tipos de patrones

Los sistemas bien estructurados contienen muchos patrones en los diferentes niveles
Idiomas
Nivel de cdigo (lenguaje de programacin)

Analisis y diseo de patrones

Nivel de clase

Patrones arquitectnicos
Nivel de component y subsistema

Patrones a nivel de empresa

Nivel de dominio y de negocios

16

Tpico Patrn de Descripcin

Nombre Contexto Problema
Aspectos problemticos que deben ser considerados. Fuerzas que conforman el problema e influyen en la solucin.

Solucin
Justificacin. Resultando contexto. Ejemplo(s).
17

Los Patrones son Combinados

Los patrones no se utilizan en el aislamiento. Los patrones se producen dentro y fuera de los niveles de abstraccin. Los patrones seleccionados a niveles ms altos restringen las opciones en los niveles inferiores. Los patrones tambin pueden tener dependencia y la exclusividad impacto.
18

Arquitectura Orientada a Servicios (SOA)

SOA es un estilo arquitectnico y un principio de diseo para el desarrollo de aplicaciones e integracin.
Desplaza el foco a la asamblea de las solicitudes de servicios y lejos de los detalles de implementacin.

SOA incluye:
Un conjunto de principios y patrones arquitectnicos Estndares abiertos que representan los activos de software como servicios Abre protocolos de comunicacin estndar para la integracin de aplicaciones y fuentes de informacin
19

SOA como estilo arquitectnico El estilo arquitectnico SOA describe un conjunto de patrones y directrices para la creacin de acoplamiento flexible, de servicios alineados al negocio. En SOA, los servicios de TI son:
Negocios alineados para cumplir con los objetivos y procesos del negocio. Coreografa en las aplicaciones compuestas. Invoca el uso de protocolos estndar.

SOA separa preocupaciones:

Descripcin del servicio. Implementacin. Enlace del servicio.
20

Arquitectura en la Arquitectura Orientada a Servicios

SOA por s sola no resuelve todas las decisiones arquitectnicas. El arquitecto todava tiene que decidir:
Que constituye un servicio Que granularidad tiene un servicio Cuando usar un servicio de estado inferior frente a un servicio de estado completo. Que mensajes de semantica transmitidos entre servicios deben teners. Como asociar y agregar servicios. Que servicios debe exponer y que debe ocultar a los diferentes clientes. Y as sucesivamente.
21

Usando la Abstraccin en SOA

Las arquitecturas basadas en SOA pueden utilizar los siguientes niveles de abstraccin:
Negocios: los objetivos del negocio, proporcionan la base para los requisitos. Anlisis: las capacidades del sistema, funcionales y no funcionales. Diseo: elementos estructurales y de comportamiento de gran importancia arquitectnica, y cmo deben llevarse a cabo. Implementacin: la abstraccin a nivel de cdigo, la realizacin del diseo.
22

Negocios

Anlisis

Diseo

Implementacin

Caractersticas clave de la arquitectura de SOA En esencia, SOA define una interaccin entre tres partes:
Servicio de Proveedor Servicio de Cliente Service de Registro

23

Conjunto de soluciones SOA

Modelo de referencia de IBM que representa la visin conceptual de una solucin SOA
Capas funcionales y no funcionales
Canal Consumers layer
Integration (Enterprise Service Bus) Servicio Cliente Servicio Proveedor

B2B
QoS layer (security, management and monitoring infrastructure services)

Information architecture layer (metadata and business intelligence)

Business process layer Composition; choreography; business state machines

Governance layer

Services layer Atomic and composite Service components layer

Paquete de Aplicacin Aplicacin Personalizada Aplicacin OO

Operational layer

24

Conjunto de soluciones SOA: Capas No Funcionales

Integracin: Mediar, enrutar y transportar los servicios requeridos del servicio del proveedor correcto Calidad de Servicio: Direcciones de requerimientos no funcionales Informacin de la arquitectura: Soporte de datos, metadata, e inteligencia de negocios Governaza: Soporte operacional en la gestin del negocio en el ciclo de vida SOA
Governance layer
Information architecture layer (metadata and business intelligence) QoS layer (security, management and monitoring infrastructure services) Integration (Enterprise Service Bus)
25

Enfoques de desarrollo SOA De arriba hacia abajo

Disear nuevos servicios de los requerimientos del negocio

De abajo hacia arriba

Crear servicios que exponen a las aplicaciones existentes

Al Centro
Combina los dos enfoques anteriores Enfoque recomendado

26

Modelado del Servicio El modelado del servicio implica las interfaces de servicios y las interacciones entre los servicios.
El modelado del servicio se complementa con el modelado tradicional OO.

La creacin de un modelo de servicio consiste en tcnicas de anlisis y diseo Modelado

Encapsular la funcionalidad de negocio para proporcionar las capacidades y la versatilidad necesarias
27

Servicio

Diseo de Componentes (CBD)

Modelado OO

El Modelo de Servicio
Mensaje
Order Order Service

Servicio

Header

Body

Politica

Interacin
Ordering p: Purchaser o: Order Service

Composicin
p: Purchaser

o: Order Service

28

Alcance del Modelo de Servicio

Dependiendo de cmo se debe utilizar el modelo de servicio, ste puede estar al alcance en los siguientes niveles: Servicio: Un solo servicio empaquetado para reutilizacin. rea funcional : Conjunto de servicios en un rea funcional de negocio en particular. Proyecto: Conjunto de servicios que son especficos de un proyecto o solucin. Empresa: Una cartera de los servicios de una empresa. Un SOA puede tener varios modelos de servicios asociados

29