2. Disclaimer
El autor es responsable de toda la información
contenida en esta presentación, la cual no
refleja el punto de vista de toda la Línea de
Investigación de Ingeniería de Software.
Parte del material de esta presentación se ha
obtenido de diversas fuentes cada una de las
cuales tiene propiedad intelectual, por lo que en
esta presentación se tiene solamente algunos
derechos reservados.
3. Agenda
• Introducción
• SOA: una nueva piedra angular en el desarrollo
de software
• Caso Práctico
• Conclusiones
4. Software Hoy en Día
• Mito: los
programadores de
ahora ya no
programan como los
de antes.
• Herramientas más
fáciles y productivas
• El software es cada
día más complejo
9. Arquitectura Windows NT 5.0
Interfaces de Hardware(buses, Dispositivos de E/S , interrupcciones,
intervalos de temporizadores, DMA, control de memoria cache , etc.)
Sistema de Despachador de Sistemas
Admon- de Tareas
Explorer
SvcHost.Exe
WinMgt.Exe
SpoolSv.Exe
Servicio de
Control de
Gestión
LSASS
Manejadorde
Objetos
Windows
USER,
GDI
Cachédel
Sistemade
Archivos
Manejador E/S
Subistema de
Entornos
Aplicaciones de los
Usuarios
Subsistema de DLLs
Procesos del Sistema Servicios Aplicaciones
Hilos de
Sistemas
User
Mode
Kernel
Mode
NTDLL.DLL
Manejador del
Sistema de
Archivos y
Dispositivos
WinLogon
Manejador de
Sesiones
Services.Exe POSIX
Windows DLLs
Administrador
DePlugandPlay
Administrador
DeEnergía
Monitorde
Referencias
DeSeguridad
Memoria
Virtual
Procesose
Hilos
Llamadaa
Procesos
Locales
Manejador
de Gráficos
Kernel
Hardware Abstraction Layer (HAL)
(interfaces invocables en el modo kernel)
Administrador
DeConfiguración
(Registro)
OS/2
Windows
12. Arquitectura de Software
Servicios
(SOA)
Arquitecturas
Monolíticas
Antes 1950’s
hasta 1960’s
1970’s
mediados
1980’s
Mediados1990’s
Comienzo
2000’s
HoyFinales
1990’s
Subrutinas
/Llamadas a
Procedimient
os Remotos
Invocación de
Objetos
Remotos
Procesamient
o de
Mensajes
Web
1980’s
mediados
1990’s
Línea del Tiempo del Desarrollo de Arquitecturas
Mayor Flexibilidad
13. Motivación
“Casas de Perros”
Proyectos Escolares
SIN ARQUITECTURA
Poco $
Casas
Proyecto de PyMES
ARQUITECTURAS SIMPLES
Rentable $
Edificios
Grandes Corporativos
ARQUITECTURAS COMPLEJAS
Mucho $$$$
Desarrollo de Software en la Academia
18. Ejemplo de Servicios en SOA
Contabilidad
Proveedor
Servicios
Compartidos
Divisiones
Cliente
Proceso de Negocio de una Aplicación
19. ¿Qué es SOA?
• “Conjunto de componentes que pueden ser
invocados, cuyas descripciones de interfaces
se pueden publicar y descubrir”
• “SOA es un estilo de arquitectura que
promueve descomponer la lógica funcional de
una aplicación en unidades autónomas
denominadas servicios”
De acuerdo al W3C
20. Arquitectura de Servicios Web
Proveedor del
Servicio
Consumidor el
Servicio
Directorio de
Servicios
Publicación
del Servicio
Descubrimiento
del Servicio
Invocación y
respuesta
1
3
2
UDDI
4
SOAP
Definición
del Servicio
WSDL
21. Características de SOA
Sin SOA Con SOA
Orientado a Función Orientado a Procesos
Construido para Durar Construido para
Cambiar
Ciclo de Desarrollos
Largos
Ciclos de Desarrollo
Incrementales
Aplicaciones Aisladas Aplicaciones
Orquestadas
Fuerte Acoplamiento Bajo Acoplamiento
Orientada a Objetos Orientado a Mensajes
23. ¿Qué es SOA?
Servicios Reutilizables
Crédito Inversiones
CRM
Servicio
Historial
Servicio
de Acceso
Checa
Crédito
Detección
de Fraudes
DWH
Servicio
Clientes
Servicio
Datos
Internet
Historial
Adeudo
s Cheques
Fondo
Retiro
Fuentes de
Información
Cálculo de
Intereses
Checa
Inversiones
Bancos Finanzas
Acceso
Multiplataforma
Componetes
de Negocio
Reutilizables
24. ESBCliente
Administración de
servicios
Ruteo Transacción Orquestación Seguridad Auditoria Otros
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
ServiciosdeNegoc
Middleware de Servicios
25. Composición de Aplicaciones
Servicio A (Verificación de Crédito)
Portlet A
Servicio D
(Colocar una Orden)
Servicio B (Balance de Cuenta)
Servicio C (Verificación de Inventario)
Portlet B
Portlet C
Portlet D
26. Agenda
• Introducción
• SOA: una nueva piedra fundamental en el
desarrollo de software
• Caso Práctico
• Conclusiones
27. Arquitectura SOA de Oracle
Apps Bulk ELT
Adapters
Partners
B2B
RFID
SES
DB
Multi
Protocol Routing
XSLT
Transform
Enterprise Service Bus
Native
BPEL
Business
Rules
Human
Workflow
BPEL Process Manager
ROUTING & ORCHESTRATION
Messaging
UDDI
Policies
Security
Web Services
Manager
Registry
Events Analytics
Business
Monitoring System
Monitoring
EMBAM BI
App Dev
Framework
&
Web Center
JDeveloper
Analyst
Tools
BPA Suite
AIA Foundation PackAIA Foundation Pack
J2EE Application Server
ODI
Process Integration Packs
Enterprise Business
Service & Object Library
SOA Governance
SOA Reference
Architecture
SOA Programming
Model
30. Manages diverse
data and content in a
unified manner
Integrated
environment
for design
and creation
of solution
assets
Manage
and secure
services,
applications
&
resources
Facilitates better decision-making
with real-time business information
Enables collaboration
between people,
processes & information
Orchestrate and
automate business
processes
Connect with trading
partners
Build on a robust,
scaleable, and secure
services environment
Facilitates interactions
with existing information
and application assets
Optimizes throughput,
availability and performance
Arquitectura SOA de IBM
Business Innovation & Optimization Services
Development
Services
Interaction Services Process Services Information Services
Partner Services Business App Services Access Services
Enterprise Service Bus: Facilitates communication between services
ITService
Management
Infrastructure Services
31. Agenda
• Introducción
• SOA: una nueva piedra fundamental en el
desarrollo de software
• Caso Práctico
• Conclusiones
36. Parte Práctica
• Consumir/Construir Servicios Distintas
Plataformas
– Java
– .NET
– Office
• Composición de Servicios Web utilizando
NetBeans
– Hola Mundo
37. Agenda
• Introducción
• SOA: una nueva piedra fundamental en el
desarrollo de software
• Caso Práctico
• Conclusiones
38. Conclusiones
• SOA no es una moda, es un estilo
arquitectónico que tiene muchos años de
madurez.
• El desarrollo de software es un proceso socio-
tecnológico, por lo que para tener éxito
implantando una Arquitectura Orientada a
Servicios no sólo requiere de tecnologías sino
de personas.
• Se debe pensar en grande pero actuar en
pequeño.
39. Conclusiones
• Existen actualmente problemas de
interoperabilidad debido a las diferentes
implementaciones de la arquitectura.
• No hay un estándar “de jure” para SOA.
• Puede ser que en el futuro surjan nuevas
arquitecturas más poderosas.
• Se debe tener cuidado en crear arquitecturas
de tipo espagueti.
La arquitectura del software hace referencia a la estructura global del sistema, dicha estructura es jerárquica en forma de módulos.
La arquitectura de software debe ayudar a definir como interactúan los componentes de software entre sí y las estructuras de los datos.
La partición estructural de una arquitectura de software puede ser horizontal: datos, procesos y control; o bien vertical definiendo una jerarquía de módulos.
El concepto de Arquitectura de Software tiene mucho tiempo de antigüedad, pero no fue hasta la década de los 1990s que comenzó a utilizarse de manera formal.
Analizando los sistemas se puede observar que existen patrones que se repiten conformando lo que se conoce como estilos arquitectónicos.
Los módulos deben programarse de tal forma que los datos no estén accesibles por otros módulos.
Un estilo arquitectónico define un conjunto de familias de patrones de software con una determinada estructura y restricciones.
Generalmente los patrones de diseño y arquitectura definen soluciones para medios repetitivos.
La arquitectura de software es una abstracción del sistema que nos permite ver su estructura y su relaciones.
Para el desarrollo del Diseño Arquitectónico se recomiendan seguir los siguientes pasos:
Estructuración del sistema
Modelado de control
Descomposición modular
Existen diferentes estilos arquitectónicos que a continuación se mencionan.
La Arquitectura de Flujo de Datos parte del DFD para obtener una arquitectura del sistema:
Se establece el tipo de flujo de información
Se indican los límites del flujo
Se convierte el DFD en una estructura del programa
Se define la jerarquía de control mediante particionamiento.
Se refina la estructura resultante utilizando heurísticas de diseño.
La Arquitectura Centrada en Datos tiene como componente principal un repositorio, del cual surgen los demás componentes.
Se define la jerarquía de control mediante particionamiento.
Se refina la estructura resultante utilizando heurísticas de diseño.
La Arquitectura Centrada en Datos tiene como componente principal un repositorio, del cual surgen los demás componentes.
Las Arquitecturas Estratificadas son de las más utilizadas en la actualidad, dado que dividen las actividades y responsabilidades de sistemas por capas.
El software más elaborado como los sistemas operativos, software de base, sistemas distribuidos y otros maneja variantes de esta arquitectura.
El diseño se debe refinar realizando cada uno de los siguientes pasos:
Desarrollar una descripción del procedimiento para cada módulo.
Desarrollar una descripción de la interfaz para cada módulo.
Se definen las estructuras de datos generales y globales.
Se anotan todas las limitaciones/restricciones del sistema.
Se debe refinar el diseño hasta que esté completo. Se recomienda completar la arquitectura con el Diseño de Interfaces.
Fue mencionada por primera vez por Gartner en 1996
SSA Research Note SPA-401-068, 12 de abril, “‘Service Oriented’ Architectures, Part 1”
Empieza a sonar en el mercado en el año 2000
SOA es una arquitectura conceptual.
Organiza funciones de negocio como servicios interoperables.
Permite reutilización de servicios para dar cumplimiento a las necesidades del negocio.
SOA es basado en estándares.
Independencia de fabricantes.
SOA es una estrategia de IT, a nivel empresarial.
Extraída desde la presentación “Software Architecture and UML” de Grady Booch (Rational Software).
Es un componente / programa con el que interactuamos intercambiando mensajes.
En SOA un Sistema equivale a un conjunto de Servicios operando conjuntamente con algún fin específico.
SOA como Estilo de Arquitectura
Componente: Servicio
Conectores: RPC o Message Based
Configuración: Distribuido
Constraint: Bajo acoplamiento, independencia del modelo de programación, independencia de la plataforma, transporte y protocolos estándar.
SOA NO es un nuevo nombre para la Integración de Aplicaciones Empresariales (EAI).
Podemos integrar aplicaciones utilizando servicios pero esto NO inválida los patrones de integración existentes.
Use example service e.g. a Flight selection service
Bring the right services together based on the task at hand
A big myth is that a “Service” (a unint of business activity) needs to be automated to be part of an SOA.
In fact, MOST business services actually involve humans in their execution
And many business services are actually collaborations between a number of participants
The humans USE various IT services in the execution of their tasks
Portals make it possible to make the automated services that assist the accessible in structured ways
Create areas or sections of your portal targeted at specific tasks
SOA Enablement 301 – Introduce Orchestration
Orchestrate the users navigation through “task pages” by applying workflow technology to the management of process state
The Workflow technology can maintain state information about the process, and provide that state to the task pages
Process Integration and Execution
Connecting portals to business processes puts the right composition of services in front of the right users at the right time.
Provides users with a single destination for all their application access.
Ties portal based activity to business procedures
There are two things money cannot buy:
Love(Lennon/McCartney)
An SOA(Webber)
Our brands play across the various elements of the integration platform. It is our brands’ capabilities and products that deliver Integration.
Alta Fallecimiento Persona
El usuario ingresa los datos del fallecimiento
El sistema valida los datos ingresados por el usuario
El sistema verifica la existencia de vínculos y los da de baja
El sistema verifica la existencia de trámites pendientes y finaliza los mismos
El sistema verifica la existencia de relaciones laborales y finaliza las mismas
El sistema graba los datos del fallecimiento
Alta Fallecimiento Persona
Comenzar proceso de alta de fallecimiento
Cerrar los vínculos vigentes
Finalizar los trámites pendientes
Finalizar las relaciones laborales de la persona
Finalizar proceso de alta de fallecimiento
El contrato de uso de un servicio equivale a:
Las operaciones que expone
Los datos que recibe y que retorna cada operación
El contrato de datos determina los datos que mi servicio recibe y los datos que mi servicio retorna
No es orientado a objetos
Datos desnormalizados
Por posibles problemas de interoperabilidad, evitar el uso de tipos específicos de una plataforma por ej. listas, datasets, mapas, etc.
El modelo de dominio representa los datos que maneja internamente la implementación de mi servicio
Puede ser orientado a objetos
Es normalizado
SOA no es:
Tecnología, Webservices, BPM , ESB
SOA es:
Un estilo de arquitectura definido en términos de varios principios de diseño, los cuales buscan implementar unidades de negocio, información e infraestructura flexibles, reusables e interoperables.
Enfoque arquitectónico que busca alinear Negocio y Tecnología a través de piezas de negocio bajamente acopladas y reutilizables que se componen en procesos de negocio flexibles y medibles contra una estrategia de negocio.