Ingeniería de Sistemas - EPE Mag. Javier Lacherre Mag. Joel Moreno Sistemas Distribuidos...

Ingeniería de Sistemas - EPEIngeniería de Sistemas - EPE

Mag. Javier Lacherre

Mag. Joel Moreno

Sistemas DistribuidosSistemas DistribuidosIntroducción a la Arquitectura Empresarial

Diferencias….Diferencias….

BusinessLogic

Legacy ERP CRM Finance

BusinessLogic

BusinessLogic

BusinessLogic

BusinessLogic

Legacy ERP CRM Finance

BusinessLogic

BusinessLogic

BusinessLogic

New Business Processes

Business Services

Application, Asset Silos Service-oriented Applications, Assets

Business functionality buried in applications, asset silos … proprietary interfaces serving the silos (son mas aisladas, empresa tipicas, aplicaciones que tienen su propia base de dato)

Business functionality exposed as business services … standards-based, shared & reusable services

?

UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/232

ObjetivoObjetivo

Explique el concepto de Arquitectura Orientada a Servicio, sus componentes y los beneficios de la adopción de este paradigma arquitectónico al negocio


AgendaAgenda



AgendaAgenda


Definición de ArquitecturaDefinición de Arquitectura

Architecture: The fundamental organization of a system embodied in its components, their relationships to each other, and to the environment, and the principles guiding its design and evolution. (ANSI/IEEE 1471-2000:ISO/IEC 42010-2007)


Principios de diseñoPrincipios de diseño

Arquitectura de SoftwareArquitectura de Software

The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships between them. (http://en.wikipedia.org/wiki/Software_architecture)


Arquitectura EmpresarialArquitectura Empresarial

Enterprise architecture is a complete expression of the enterprise; a master plan which “acts as a collaboration force” between aspects of business planning such as goals, visions, strategies and governance principles; aspects of business operations such as business terms, organization structures, processes and data; aspects of automation such as information systems and databases; and the enabling technological infrastructure of the business such as computers, operating systems and networks (http://en.wikipedia.org/wiki/Enterprise_architecture)


Característica de diseñoCaracterística de diseño

Una característica de algo es simplemente un atributo o cualidad


Principio de diseñoPrincipio de diseño

Práctica aceptada por la industria


Paradigma de diseñoParadigma de diseñoUn paradigma de diseño dentro del contexto de la automatización de un negocio es considerado generalmente un enfoque de gobierno para el diseño lógico de la solución.

Es un conjunto complementario de reglas o principios que en conjunto definen el enfoque representado por el paradigma


Paradigma de diseñoParadigma de diseño


Más términosMás términosPatrón de Diseño

Un patrón de diseño describe un problema y su correspondiente solución (genérico)

Lenguaje de Patrones de Diseño

Colección de patrones relacionados

Estándar de Diseño

Son convenios de diseño personalizados para predeterminar consistentemente las características del diseño de una solución para soportar los objetivos de la organización y optimizarla para un ambiente empresarial especifico (Debe cumplirse)


Mejor práctica Mejor práctica

Una mejor práctica es generalmente considerada una técnica o enfoque para resolver o prevenir ciertos problemas

UPC - EPE - Ingeniería de Sistemas - Programa de Actualización Profesional 21/04/2315

Mapa ConceptualMapa Conceptual


Orientación a ServiciosOrientación a Servicios

Orientación a Servicios es un Paradigma de Diseño que abarca un conjunto específico de Principios de Diseño.

La aplicación de estos principios al diseño de la lógica de una solución resulta en una Solución Orientada a Servicios.

La unidad principal de una solución orientada a servicios es el Servicio.


AgendaAgenda


¿Que es un Servicio?¿Que es un Servicio?

Un servicio existe como una unidad de software independiente con características de diseño propias que apoyan el logro de los objetivos estratégicos del negocio

Cada servicio está asignado a su propio contexto funcional y abarca un conjunto de capacidades relacionadas con este contexto.

Estas capacidades están disponibles para su invocación por un programa cliente y son comúnmente expresadas a través de contrato de servicio publicado



Recurso A

Servicio

Recurso C Recurso D

Proveedores de Servicios

Consumidores de Servicios

Un Servicio ofrece una funcionalidad por la cual la necesidad del Consumidor es satisfecha por el Proveedor de Servicios

Desacopla los recursos utilizados por el Proveedor de aquellos usados por el Consumidor de Servicios

El Proveedor de Servicios tiene la capacidad para realizar los Servicios requeridos

El Proveedor de Servicios puede cambiar recursos sin impactar en el Consumidor

El Consumidor de Servicios requiere la funcionalidad ofrecida por el Servicio

Varios Consumidores pueden compartir un Servicio reduciendo el coste global y mejorando la coherencia

Recurso B



Se comunica usando mensajes que comparten esquemas no tecnología

Servicio

Consumidor de Servicios

Proveedorde

Servicios

Políticas &contratos

Recurso

Aplicación solicitante

Mensajes

EndpointServicio

DescripciónDescubri-miento


Servicio

Consumidor de Servicios

Proveedorde Servicios

Políticas &contratos

Recurso

Aplicación solicitante

EndpointServicio

¿Que es un Servicio Web?¿Que es un Servicio Web?Un Servicio Web es un Servicio diseñado conforme un conjunto de protocolos (WS) basados en XML que proporciona un mecanismo para la Descripción y Despliegue de Servicios.

22

Mesages

WSDL

Ej.: WS-Security

Ej.: SOAP

UDDI

Modelo de Servicios (Thomas Modelo de Servicios (Thomas Erl)Erl)

Los servicios se clasifican de acuerdo:El tipo de lógica que encapsulan

Medida del potencial reuso de esta lógica

Como esta lógica esta relacionada con los dominios dentro de la empresa


Entity ServicesEntity Services

Ejemplos: cliente, empleado, factura, reclamo.

Representa un servicio de negocio cuyo contexto funcional lo constituye una o más entidades del negocio

Es altamente reusable porque es agnóstico a la mayoría de los procesos


Composición e Inventario de Composición e Inventario de ServiciosServicios

Composición de servicios Un service composition es un conjunto de servicios coordinados. Un servicio puede participar en más de una composición

Inventario de servicios A service inventory es una colección independientemente estandarizada y gobernada de servicios con una frontera que representa una organización o un segmento importante de la organización.


Composición e Inventario de Composición e Inventario de ServiciosServicios


Task ServicesTask Services

Representa un servicio de negocio cuyo contexto funcional es una tarea o proceso principal del negocio

Tiende a ser menos reusable

Actúa como un controlador de otros servicios

Su alcance es más amplio que un servicio de tipo entidad. La entidad también contiene tareas pero su alcance está limitado a la entidad


Utility ServicesUtility Services

Conforman la capa de infraestructura y ejecutan tareas como manejo de excepciones, auditoría, seguridad, etc.


AgendaAgenda


Beneficio del concepto de Beneficio del concepto de servicio: SOA Incrementa la servicio: SOA Incrementa la cantidad de lógica agnósticacantidad de lógica agnóstica

Dentro de una solución orientada a servicios, las unidades lógicas (servicios) encapsulan funcionalidad que no es específica de una aplicación o proceso de negocio. Estos servicios son considerados agnósticos y activos de IT reusables.


Beneficio del concepto de servicio: Beneficio del concepto de servicio: Reduce la cantidad de lógica Reduce la cantidad de lógica específica de una aplicaciónespecífica de una aplicación

El incremento de la cantidad de lógica no específica de las aplicaciones disminuye la cantidad de lógica específica de una aplicación.


Beneficio del concepto de Beneficio del concepto de servicio: servicio: La cantidad total de lógica La cantidad total de lógica disminuyedisminuye


Beneficio del concepto de Beneficio del concepto de servicio: servicio: Interoperabilidad inherenteInteroperabilidad inherente


La necesidad de organizar los La necesidad de organizar los serviciosserviciosSin una arquitectura …

• Anarquía de Servicios

• JBOWS (just a bunch of web services)

Con una arquitectura …

• Alineamiento Negocio-IT

• Economias de escala (services compartidos, reutilización, repropósito)

• Flexibilidad, Calidad


AgendaAgenda


Arquitectura Orientada a Arquitectura Orientada a ServiciosServicios

Una Arquitectura Orientada a Servicios es la arquitectura diseñada para dar soporte a las Soluciones Orientadas a Servicios, las que incluyen tanto Servicios como Inventarios de Servicios diseñados conforme a la Orientación a Servicios

Plataforma Orientada a Servicios representa una nueva generación de plataforma distribuida. La plataforma incluye todo: paradigma, patrones, conceptos, frameworks y tecnología




Arquitectura Orientada a Arquitectura Orientada a Servicios (Thomas Erl)Servicios (Thomas Erl)

SOA establece un modelo de arquitectura que pretende incrementar la eficiencia, agilidad y productividad de una empresa posicionando los servicios como un mecanismo esencial para el logro de las metas estratégicas de la organización(SOA: Principles of Service Design by Thomas Erl)


Una colección de Servicios

Clasificada en tipos

Organizada en capas

Gobernada por patrones y políticas

Servicios

tipo tipo tipo

granularidad

dependencia

identificació

n





Los principios y la Los principios y la interoperabilidadinteroperabilidad1. Los contratos (descripción de un servicio) de los servicios

deben ser estandarizados para buscar una mayor interoperabilidad (Standarized Service Contract)

2. La reducción del grado de acoplamiento entre los servicios fomenta la interoperabilidad haciendo que los servicios sean menos dependientes unos de otros, y por tanto estén más abiertos para la invocación por diferentes consumidores (Service Loose Coupling)

3. La abstracción de los detalles sobre un servicio limita la interoperabilidad al contrato del servicio, incrementando la consistencia a largo plazo de la interoperabilidad permitiendo que la lógica del servicio evolucione de forma más independiente (Service Abstraction)


Los principios y la Los principios y la interoperabilidadinteroperabilidad4. El diseño de los servicios para su reuso implica

mayor interoperabilidad entre el servicio y la gran cantidad de consumidores potenciales del servicio (Service Reusability)

5. Mientras más autonomía tenga un servicio sobre su plataforma subyacente entonces su comportamiento será mas predecible, incrementando por tanto su potencial reuso y su nivel de interoperabilidad (Service Autonomy)


Los principios y la Los principios y la interoperabilidadinteroperabilidad6. Haciendo énfasis en el diseño sin estado, la

disponibilidad y la escalabilidad de los servicio, permite interoperar con más frecuencia y fiabilidad (Service Statelessness)

7. La capacidad de un servicio para ser descubierto permite a otros servicios ubicarlo fácilmente para interoperar con éste (Service Discoverability)

8. Finalmente para que los servicios puedan ser servicios compuestos estos tienen que ser interoperables (Service Composability)


Objetivos y Beneficios de Objetivos y Beneficios de adoptar SOAadoptar SOA


Objetivos que persigue la Objetivos que persigue la adopción de SOAadopción de SOAAumento de la Interoperabilidad

La interoperabilidad se refiere al intercambio de datos

Mayor interoperabilidad significa mayor facilidad para el intercambio de datos

Un objetivo de SOA es la interoperabilidad entre los servicios


Objetivos que persigue la Objetivos que persigue la adopción de SOAadopción de SOAAumento de la Federación

Un ambiente de IT federado es uno donde los recursos y las aplicaciones están unidas mientras mantiene su autonomía y su propio gobierno.

SOA apunta a incrementar la perspectiva federada en una empresa en la medida que pueda ser aplicada.

Esto puede ser llevado a la práctica a través de servicios donde cada uno encapsula una parte de la empresa


Objetivos que persigue la Objetivos que persigue la adopción de SOAadopción de SOAAumento de opciones de diversificación de

proveedores

Diversificación de proveedores se refiere a la posibilidad de la organización de seleccionar el mejor producto sin importar el proveedor

Para algunas organizaciones esto es necesariamente un beneficio pero siempre es bueno contar con la posibilidad de elegir libremente un proveedor


Objetivos que persigue la Objetivos que persigue la adopción de SOAadopción de SOAMejor alineamiento entre el negocio y los

proveedores

Estructurar los recursos de tecnología de la información según las necesidades del negocio.

Crear un ecosistema donde la organización y sus colaboradores compartan información, semántica y procesos


Beneficios de la Arquitectura Beneficios de la Arquitectura Orientada a ServiciosOrientada a Servicios

Portafolio ITReduce la multiplicidad de objetos

Reduce los costes de los recursos, licencias

Reduce mantenimiento de reglas de negocio a través de distintos sistemas

Mejorar el proceso ITHabilita la entrega mediante políticas y gobierno

Optimiza el uso de los recursos y el conocimiento

Reducción de CostesReduce el Ciclo de Vida de los sistemas

Aumenta la productividad a través de la reutilización de Servicios comunes


Beneficios de la Arquitectura Beneficios de la Arquitectura Orientada a ServiciosOrientada a Servicios

OrganizaciónEstructuración paralela de Negocio y TI: Ontología

Distribución de los componentes TI correspondientes a cada Dominio

Posibilita la Empresa Extendida: Interoperabilidad

Transformación EstructuralReducción de la complejidad: Estructuración de los Servicios

Mejora de la coherencia y calidad de los datos

Mejora en la exactitud y seguridad de la información

Facilita reemplazo de los costosos sistemas heredados

Facilita escoger las mejores fuentes de información para realizar la actividad

Posibilita la automatización de los procesosCapacidad de realizar cambios rápidos en Procesos de Negocio: Entrega Funcionalidad

Rapido ensamblaje de sistemas de apoyo a nuevos productos

Capacidad para trabajar con nuevos clientes y partners: Interoperabilidad


AgendaAgenda


Escenarios típicos de Escenarios típicos de Proyectos SOA Proyectos SOA

Madurez

IT Negocio

Proyecto

Organización

Driver

Alcance

Corta

Larga

Duración

Baja

Alta

Optimización de Procesos

Acceso de Clientes y Partners

Procesos y Coherencia de la Información

OutsourcingFuncionalidad

Común de Negocio

Integración Basada en Servicios

Provisión de Infraestructura

SOA

Planificación SOA

Racionalizacióndel Portfolio IT

Funcionalidad común de IT


SOA Escenario I – Optimización SOA Escenario I – Optimización de Procesos de Negociode Procesos de Negocio


SOA Escenario II - SOA Escenario II - IntegraciónIntegración


SOA Escenario III – SOA Escenario III – Mejora Estructural y Racionalización Mejora Estructural y Racionalización del Portafolio del Portafolio


SOA Escenario IV –SOA Escenario IV –Federación, Virtualización del Federación, Virtualización del Negocio Negocio


Business Cases: Escenarios Business Cases: Escenarios posibles de aplicación SOAposibles de aplicación SOA

SOA Escenario I – Optimización de Procesos de Negocio

SOA Escenario II - Integración

SOA Escenario III - Mejora Estructural y Racionalización del Portfolio SOA Escenario IV – Federación, Virtualización del Negocio

¿Cuáles son las necesidades en mi Sector, y que escenario

escogería?

¿Cómo puedo avanzar entre los distintos escenarios para

llegar a una adopción total de SOA?

¿Cuáles son las necesidades en mi Sector, y que escenario

escogería?

¿Cómo puedo avanzar entre los distintos escenarios para

llegar a una adopción total de SOA?UPC - EPE - Ingeniería de Sistemas – Sistemas Distribuidos 21/04/2357

AgendaAgenda


La Adopción de SOALa Adopción de SOA

Elaborar un Plan de Servicios:Identificar el Portafolio de Servicios

• La colección de servicios software requeridos

Diseñar una Arquitectura de Servicios• Clasificados por tipos y organizados por capas • Abarcando la especificación para el despliegue

Definir y adoptar Políticas • Que gobernarán como ha de proceder la Planificación

y Suministro de Servicios

Emitir un Plan de trabajo para la Adopción SOA


Enfoque del PlanEnfoque del Plan

Un Plan de Servicios depende del alcance del proyecto.

Un gran alcance –toda una organización- debe ser cubierto en varios incrementos.


Metodología adecuadaMetodología adecuada


Construcción de una Arquitectura de Construcción de una Arquitectura de Servicios: Servicios: El camino de Adopción SOAEl camino de Adopción SOAPlan de Servicios:

El camino a seguir en la construcción de una SOA, manejando Gestión de Procesos y Modelos semánticos para la interoperabilidad.

Identificar el Portfolio de Servicios

Diseñar una Arquitectura de Servicios

Definir y adoptar Políticas

Emitir un Plan de trabajo para la Adopción SOA

¿Soporta esta visión cualquier escenario de aplicación SOA?

¿Qué barreras encontrarían para adoptar un enfoque de este tipo?

¿Proporciona este camino un método de construcción de Arquitectura

Empresarial (Negocio + IT)?

¿Soporta esta visión cualquier escenario de aplicación SOA?

¿Qué barreras encontrarían para adoptar un enfoque de este tipo?

¿Proporciona este camino un método de construcción de Arquitectura

Empresarial (Negocio + IT)?


AgendaAgenda


Modelo de Capas de la Modelo de Capas de la Arquitectura de EspecificaciónArquitectura de Especificación

Procesos a implementar sobre BPM

Orquestación de Servicios

Servicios unitarios

Posibles conexiones a Legacy


Infraestructura OperacionalInfraestructura Operacional


Infraestructura Operacional: Infraestructura Operacional: ElementosElementos


Infraestructura para soportar Infraestructura para soportar el despliegue de SOAel despliegue de SOA

Modelador BPA

Motor BPM

Motor de Reglas

Motor Documental

Análisis BAM

Orquestador de Servicios

¿Qué criterios se deberían tomar en cuenta para la selección de estas herramientas?

¿Cómo y cuando, debería ir implantando y adquiriendo conocimiento en mi organización para la utilización de estas herramientas?

¿Qué criterios se deberían tomar en cuenta para la selección de estas herramientas?

¿Cómo y cuando, debería ir implantando y adquiriendo conocimiento en mi organización para la utilización de estas herramientas?

Enterprise Service Bus

Seguridad de Aplicación

Registro / Repositorio

Adaptadores

Framework de Desarrollo


AgendaAgenda


Madurez SOAMadurez SOA

Grado de preparación de la Organización para la adopción de SOA:Madurez Organizacional: Aceptación, Visión/Estrategia, Staff, Formación, …

Madurez Tecnológica: Estándares, Infraestructura, Seguridad, Monitorización, …

Madurez de Implementación: Servicios, Infraestructura, Proyectos, …

Madurez del Ciclo de Vida: CdV BPM, CdV SOA, Gestión Proyectos, …

Madurez en Gobierno: Gestión de Políticas, An. y Monit., Reg, y Repositorio, …

El Modelo de Madurez:Permite medir el estado actual de una Arquitectura Empresarial respecto a la utilización de SOA.

Permite establecer una ruta de evolución.

Habilita aprendizaje por capas incluyendo buenas prácticas

Forma la base para comunicar y extender capacidades.

Forma la base para crear una adopción incremental de SOA (Iterativa)


SOA Capability Maturity SOA Capability Maturity LevelsLevelsHigher the Level – Higher the Higher the Level – Higher the CapabilitiesCapabilities

NO SOA

- 0 -

Strategic Goals Tactical Plans

SOA not being pursued Investigate applicability of SOA

AD HOC

- 1 -

Experimenting with and learning SOA concepts

Get experience building, deploying, and consuming services

Focused on simple quick winprojects to demonstrate value

Apply SOA to simple integrationsSelect business-driven projects amenable to SOA (e.g. simple portals)Build confidence with business owners

OPPORTUNISTIC

- 2 -

SOA concepts consistently applied facilitating sharing and reuse

Standardize approach and productsDrive widespread adoptionEstablish governanceSYSTEMATIC

- 3 -

Processes and procedures quantitatively managed to drive

business value.

Establish key performance indicators and manage to those metricsLeverage BAM to improve business processes.

MANAGED

- 4 -

Able to support business initiatives in a timely and cost-effective manner.

Refine and improve standards and processesExploit new business opportunitiesenabled by SOA

OPTIMIZED

- 5 -


SOA Maturity Model DomainsSOA Maturity Model Domains Domain – A Collection Of Related Domain – A Collection Of Related CapabilitiesCapabilities

Governance

Business & Strategy

Organization

Projects , Portfolios &

Services

OrganizationalDiciplines

Operations , Administration

& Management

Information

Architecture

TechnologyDominated

Infrastructure


SOA Maturity ModelSOA Maturity ModelMeasures Maturity and AdoptionMeasures Maturity and Adoption

Exploring

Expanding

Exploiting

As-Is Phase-1 Phase-2

None ProjectLevel

ProgramLevel

DivisionLevel

CrossDivisional

EnterpriseWide

No SOA

Ad-Hoc

Opportunistic

Systematic

Managed

Optimized

SOA Adoption Level

SO

A M

atu

rity

Lev

el

Target Range

Either individual capabilities, ordomains

Outliers


SOA Maturity Model SOA Maturity Model Domains & MeasurementDomains & Measurement

Domains Measurement Model

• Eight capability domains – comprehensive coverage• Domain – A collection of related capabilities• Model measures maturity and adoption levels


Objetivos del Gobierno SOAObjetivos del Gobierno SOA

Asegurar que se alcanzan los resultados deseados de la Estrategia de Negocio, IT y SOA

Asegurar que se evitan los resultados no deseados y la anarquía de Servicios

Redución de riesgos

Fallos

Amenazas

Cumplimiento de las Normas

Ejercer la autoridad y el control

Asegurar que se siguen estándares y políticas

Mejorar la calidad

Arquitectura de Servicios

Coherencia de SOA en la organización

Mejora de los procesos IT

Reutilización

Consistencia

Adopción de la Gestión SOA

Facilitar la gestión del cambio

Control de Costes

Gestionar el aprovisionamiento de los Servicios

Asignación eficiente de recursos


SOA Governance: Un ejemplo SOA Governance: Un ejemplo ilustrativoilustrativo


Madurez y Gobierno: Conceptos Madurez y Gobierno: Conceptos básicos para la correcta básicos para la correcta organización de SOAorganización de SOA

Madurez:Medir el estado actual de SOA en la Organización Establecer ruta de evolución.Aprendizaje por capasBase para comunicar y extender capacidades.Base para la adopción incremental de SOA

¿Cuáles son las aristas sobre las cuales se debería medir la

Madurez de una Organización en la adopción de SOA?

¿Cómo y cuándo se debe implantar el concepto de

Gobierno en la adopción de una SOA?

¿Cuáles son las aristas sobre las cuales se debería medir la

Madurez de una Organización en la adopción de SOA?

¿Cómo y cuándo se debe implantar el concepto de

Gobierno en la adopción de una SOA?

Gobierno:Asegurar Resultados deseadosReducción de RiesgosAutoridad y ControlMejora de la CalidadFacilita la Adopcion SOAControl de Costes


AgendaAgenda


ConclusionesConclusiones

Retos introducidos por la Orientación a Servicios

SOA y su efecto de la Organización


Retos introducidos por la Retos introducidos por la Orientación a ServiciosOrientación a Servicios

Mayor complejidad en el diseño

Necesidad de Estándares de Diseño

Estrategia de diseño

Agilidad en la entrega de los servicios

Necesidad para gobierno SOA


Efectos de la Orientación a Efectos de la Orientación a Servicios en una Servicios en una OrganizaciónOrganización

La orientación a servicios y el concepto de aplicación



La orientación a servicios y el concepto de integración



Aplicación tradicional vs Composición de Servicios


Date post:	24-Jan-2016
Category:	Documents
Upload:	ignacio-medina-soriano
View:	216 times
Download:	0 times

Ingeniería de Sistemas - EPE Mag. Javier Lacherre Mag. Joel Moreno Sistemas Distribuidos...

Documents