Sei sulla pagina 1di 39

Universidad de San Martín de Porres

Facultad de Ingeniería y Arquitectura

Diseño e Implementación de Sistemas

Análisis y Diseño II

Sesión: 05

Mg. Géner Zambrano L.

gzambranol@usmp.pe
gzambrano@usmp.edu.pe

Semestre: 2011_I
Objetivos:

• Conocer la arquitectura orientada a servicios SOA


• Entender la gobernabilidad de los servicios
• Conocer los riesgos de implementar SOA
• Conocer las mejores prácticas de SOA
• Ejemplo de aplicación de Diseño con RUP
Imperativos del Negocio

Presiones Competitivas

Presiones Regulatorias

Poder del Cliente

Sobrecarga de Información

La Fuerza
Cambiante de Trabajo
Imperativos del Negocio, continua…

Presiones Competitivas
SOA
Presiones Regulatorias Ambientes de
Desarrollo
Orientados al
Poder del Cliente Negocio

Web 2.0/
Sobrecarga de Información Rápido Desarrollo de
Aplicaciones
La Fuerza Cómputo
Cambiante de Trabajo Social
Metadatos/
Semántica
La Evolución de la Industria del
Software

Foco en TI
Construir Comprar Componer

Infraestructura de
Sistemas Centrales Negocio
• Pagos corporativos •Automatización de
• Manejo de Quejas Procesos
• Sistema de facturación •SOA y Gobernabilidad
Sistemas de Soporte •Integración
• RH •Modernización
• Nómina • Servicios Web
• CRM • Integración

1960 1970 1980 1990 2000 2010 2020


Definiendo SOA

¿Qué es un Servicio?

¿Cómo lo Obtengo?

¿Qué es lo importante?

– Capacidades distribuidas
– Granular, realizar una unidad de trabajo
– Confiabilidad y calidad de servicio
– Acoplada libremente – ninguna suposición acerca de las necesidades de la otra parte
– Facilidad de uso basada en minimizar las dependencias artificiales
¿Qué es un Servicio?

‰ Un servicio es un componente que provee un conjunto de


funciones de negocios.

‰ Un servicio es una unidad de trabajo realizado por un


proveedor de servicios para alcanzar los resultados finales
deseados para un consumidor de servicios. Tanto el
proveedor como el consumidor son papeles desempeñados
por agentes de software en representación de sus
propietarios”. “
Elementos de SOA
SOA está diseñada para soportar lógica orientada a servicios
compuesta de servicios y composiciones de servicios,
agrupados en un inventario global de servicios.
SOA y Web Services
Los Servicios Web juegan un papel importante en una
arquitectura SOA, ya que brindan mecanismos
independientes de la plataforma para exponer,
descubrir e invocar servicios.

SOA requiere que un servicio:

•Sea descubrible e invocable dinámicamente. UDDI,


WSDL, SOAP.
•Tenga una definición del contrato independiente de
plataforma. XML.
•Pueda interoperar con otros servicios. HTTP.
Arquitectura Orientada a Servicios (SOA)

• Una composición de servicios está formada por servicios que se


asocian para proporcionar funcionalidad requerida para automatizar
un proceso o tarea de negocio específicos.

• La orientación a servicios define los servicios como “recursos


empresariales agnósticos”, lo que implica que un servicio puede ser
invocado por múltiples consumidores, involucrando incluso al
servicio en diferentes composiciones.

• Una colección de servicios estandarizados es la base para el


inventario de servicios que puede ser administrado
independientemente en un ambiente aislado.

• Se pueden automatizar múltiples procesos de negocio creando


composiciones que usan servicios agnósticos tomados del
inventario.

• Un inventario de servicios establece un pool de servicios, muchos


de los cuales serán diseñados deliberadamente para reusarse en
múltiples composiciones.
Ventajas Operativas de SOA

Business
Business Models and
Business analyst Architect Architect
Analyst requirements
Architect interprets business
Business analyst hands over models and requirements and
Business documentation designs business automation
Traditional projects to architect system.
SOA projects

Business
Business Models and Business
Analyst requirements Analyst Architect
Architect finalizes
Business analyst and architect define Physical design
conceptual design together to ensure
accurate representation of business
logic
Restricciones Arquitectónicas de SOA
‰ Un conjunto pequeño de interfaces simples y ubicuas
‰ Las interfaces deberían estar universalmente disponibles
para todos los proveedores y consumidores
‰ Únicamente se encuentra codificada la semántica genérica
en la interface – la semántica específica de las aplicaciones
en los mensajes
‰ Mensajes descriptivos, es decir, los mensajes no prescriben
ningún comportamiento del sistema , o sólo lo hacen en
forma mínima
‰ Un esquema limita el formato, el vocabulario y la estructura
de los mensajes
‰ Un esquema extensivo permite nuevas versiones de los
servicios que serán introducidos sin romper los servicios
existentes
Definición de SOA
SOA es un estilo arquitectónico cuyo objetivo es lograr un
acoplamiento libre entre los agentes de software
interactuantes.

Consumidor

Servicio Consumidor
Proveedor

Consumidor
SOA: Fundamento de una Arquitectura

Administración y Control

Mainframe SOA

Dependiente Interdependiente

Servicios Web Punto a Punto Servidor de Aplicaciones Web


Codependiente Independiente
Agilidad y Libertad
¿Por qué SOA es tan valioso para los
Negocios?

‰ Se generan resultados y se construyen


capacidades que crean el máximo valor para los
Valor elementos constitutivos del negocio.

‰ Se gasta menos en materiales y mano de obra


Costo y se maximiza el ROI directo.

‰ Se llega más rápido al objetivo; se reducen los


costos de oportunidad y se genera un nuevo
Tiempo
valor más pronto.

‰ Se reutiliza todo aquello que sea útil; no se


Desperdicio pierde nada del valor; se apalancan los activos
existentes.
¿Por qué SOA?
¾ Permite que el área de IT
satisfaga más ágilmente las
necesidades del negocio,
cerrando cada vez más la
brecha entre la evolución del
negocio y el soporte
tecnológico.

¾ Crea servicios basados en


estándares, interoperables e
independientes de un
proveedor específico.

¾ Reutilización de servicios para


la creación de nuevas
aplicaciones o funcionalidades
que apoyan los procesos de
negocio.
¿Por qué SOA?, continua…

SOA
SOAabarca
abarca99
de
delas
las10
10
Principales
Principales
Prioridades
Prioridadesdede
la
la
Administración
Administración
de
deTITI
Generación de valor con SOA

‰ Eficiencia a través de la automatización y la coordinación


mejorada

‰ Eficiencia centrándose en la creación de valor

‰ Agilidad de negocio – implementación del cambio al


momento del negocio

‰ Productividad de TI – desde el sostenimiento hasta las


nuevas capacidades
Generación de valor con SOA, continua…

‰ Transparencia operacional mejorada

‰ Productividad y satisfacción mejoradas del trabajador

‰ Apalancamiento en capacidades existentes

‰ Desarrollo de una cultura orientada al desempeño y la


mejora

‰ Desarrollo de una organización alineada

‰ Facilitan los negocios


Arquitectura de Referencia SOA

Conceptual: Modelo de Referencia


Neutral en SOA
Tecnología

Arquitectura de Frameworks
Dependiente de Referencia SOA
Tecnología.
Reutilizable Patrones de Diseño
entre Proyectos.

Instancia
Arquitectura
de Referencia. Arquitectura Concreta
Específica de
cada Proyecto.
Arquitectura: Servicios de Negocio
Presentation Business Resources

Session
Facade

Front
Session EIS
Controller
Facade

Session LDAP
Facade

Servicios de Negocio: Web Services, EJBs.


Arquitectura: Servicios de Negocio y
Persistencia
Presentation Business Integration Resources

Composite
Session Entity
Facade

Front Composite
Session
Controller Entity
Facade

Session LDAP
Facade

Servicios de Negocio y Persistencia: Web Services, EJBs.


Arquitectura:
Orquestación y Procesos de Negocio
Presentation Business

Session
Facade

Front
Session
Controller
Facade

Process Orchestration

Session
Facade

Servicios de Negocio: Web Services, EJBs.


Arquitectura:
Orquestación y Procesos de Negocio, continua…

Business Process Business Logic Integration Resources

Composite
Session Entity
Facade

Composite
Session
Entity
Facade

Process Orchestration

Session LDAP
Facade

Servicios de Negocio y Persistencia: Web Services, EJBs.


Ruta de Implementación a SOA
• Evaluar grado de madurez SOA y definir grados de madurez
que la organización quiere alcanzar en el tiempo.

• Implementar un proyecto piloto utilizando SOA con servicios


simples que impacten más de un área de negocio.

• Para el caso de sistemas legados habilitar funciones de negocio


requeridas por el proyecto piloto como servicios.

Nivel 6 SOA optimizado

Evolución SOA
Nivel 5 Adopción empresarial de SOA Explotación

Nivel 4 SOA repetible


Nivel 3 Enfoque SOA definido Expansión

Nivel 2 Adopción Ad Hoc de SOA


Nivel 1 Ninguna adopción de SOA Exploración
Plataforma de Servicios
Empresarial
Estrategia

Definir estrategia de IT
alineada con objetivos y
Arquitectura metas organizacionales
Empresarial
Gerencia

Definir arquitectura general


Arquitectura de para los proyectos de la
IT

Referencia SOA organización

Mentoring de Workshop de
Proyectos

Arquitectura y Arquitectura Definir arquitectura


Diseño
para un proyecto
IT

específico
Valoración de
Arquitectura
Rational
Unified
Process ©

RUP
for
SOA
¿Por qué Gobernabilidad?
Problemas:

•Los ERPs se dividen


en partes
Legacy CRM Cadena Finanzas
de •Las aplicaciones
Sumi- previas se convierten
nistro en Servicios

•Los sistemas
complejos se rompen
en piezas de servicio

•Los módulos se
conectan de acuerdo a
las necesidades del
negocio
¡SOA no administrado es demasiado complejo!
Fuente: Seminario Básico de BPM - SOA
Gobernabilidad
La Gobernabilidad proporciona:
ƒ Autoridades y responsabilidades
ƒ Reglas claras y refuerzo de reglas
ƒ Transparencia organizacional y técnica

La Gobernabilidad SOA permite:


ƒ Dominar la complejidad de TI
ƒ Soportar el cambio del proceso del negocio

La Gobernabilidad SOA ahorra tiempo y dinero a los


negocios
El Concepto SOA

Dominio de los
Aplicaciones

Analistas de
Compuestas

Negocio
Procesos de Obtener Verificar Capturar Revisar Aprobar Iniciar
Negocio Datos Detalles Pedido Pedido Pedido Envío

Administración de Pedidos

Orquestación MONITOREO & ANÁLISIS


de Servicio
de Negocio Información del Administración de Compensación de
Cliente Pedidos Pedidos

GOBERNABILIDAD

Desarrolladores

Dominio de los
Arquitectos y
Integración Datos del
Cliente
Interacción
del Cliente
Historia del
Pedido
Polìtica de
Pedidos
Envío
de Legados

Datos del Cliente CRM ERP Pedidos Logística


Las 10 Mejores prácticas de SOA

1. Entender el Proceso

2. Entender sus datos

3. ¡Gobernar primero!

4. Solicitar la validación de terceros

5. Construir un caso de negocio enfocado al valor

6. No (siempre) llamarlo SOA

7. Foco en el negocio y en el suceso urgente

8. La reutilización no es el único beneficio

9. Empezar con poco….pensar en grande

10. Promover una cultura de compartir


Los 10 riesgos de SOA
1. El Enfoque Escopeta/Exhuberancia Irracional

2. No poder planear; planear para fallar

3. Dictadura para combatir la anarquía

4. Ignorar la seguridad

5. No estandarizar SOA

6. No pedir ayuda

7. El tamaño cuenta

8. Ignorar la inversión

9. Ignorar su madurez

10. Ejecutar SOA de abajo hacia arriba


Ingeniería de Métodos en SOA

Ingeniero de métodos

Proyecto
Metodología / Método
Repositorio

Desarrollador

Metodólogo

Fuente: Copyright © César González Pérez 1999-2006 33


Modelando metodologías

proyecto
proyecto

Desarrollador

método
método

Ingeniero Metodólogo
de métodos
metamodelo
metamodelo

Fuente: Copyright © César González Pérez 1999-2006 34


Modelando metodologías, continua…

• ¿Qué? Trabajo. Verbo.


• ¿A qué? Productos. Objeto directo.
• ¿Cuándo? Tiempo. Complementos.
• ¿Quién? Personas. Sujeto.
• ¿Con qué? Herramientas. Complementos.

El equipo de desarrollo determina los requisitos del sistema antes


de definir la arquitectura del mismo, habitualmente mediante
entrevistas, cuestionarios y otras técnicas.

Fuente: Copyright © César González Pérez 1999-2006 35


El Repositorio

Repositorio Nombre: Determinar Requisitos


Propósito: Obtener y documentar
los requisitos del sistema……

Nombre: Escribir Código


Propósito: Crear el código fuente
que implementa…

Especificaci Nombre: Documento de


de tarea Especificación de Requisitos
Soporte: papel

Especificación
de producto
Nombre: Código Fuente
Soporte: digital

Fuente: Copyright © César González Pérez 1999-2006 36


La Metodología

Nombre: Determinar Requisitos Nombre: Escribir Código


Propósito: Obtener y documentar Propósito: Crear el código fuente
los requisitos del sistema…… que implementa…

lee
crea

crea
Nombre: Documento de
Especificación de Requisitos
Soporte: papel

Nombre: Código Fuente


Soporte: digital

Fuente: Copyright © César González Pérez 1999-2006 37


Revisar:

DIS_S_05_SOA_GOVERNANCE_RAM_2011_
I.pdf
Revisar:

DIS_S_05_CASO_2011_I.pdf

Potrebbero piacerti anche