Documentos de Académico
Documentos de Profesional
Documentos de Cultura
SOA, Una Perspectiva: Manuel J. Recena Soto Computación Orientada A Servicios Etsii Sevilla, 4 de Julio de 2007
SOA, Una Perspectiva: Manuel J. Recena Soto Computación Orientada A Servicios Etsii Sevilla, 4 de Julio de 2007
Presentado por:
Objetivos Una vision Cmo afrontar una implantacin Caso de estudio OpenESB, una solucin abierta basada en estndares Conclusiones Agradecimientos
02 Objetivos
Realizar una pequea aportacin a la asignatura C.O.S. Proporcionar una visin desde la experiencia profesional Compartir experiencias del da a da Acercar las arquitecturas orientadas a servicios
03 Una visin
Procesos: 0 veces Servicios: 0 veces Estratega: 0 veces Perspectiva: 0 veces Gobierno: 0 veces Integracin: 0 veces
04 Una visin
Nos suena?
Cliente pesado Cliente ligero Cliente pesado
APLICACIONES MONOLTICAS
NMINAS
MATRICULA
FACTURA
CONTENEDORES DE INFORMACIN
05 Una visin
Nos suena?
Aplicaciones .NET, J2EE, PHP, Ruby, Python, Visual Basic, Oracle Forms, Delphi, etc... Informacin en bases de datos, servicios de directorio, sistemas de ficheros, etc... Aplicaciones de escritorio, cliente-servidor, N-capas, etc...
06 Una visin
El gran objetivo:
INTEROPERABILIDAD Dnde te encuentras? Dnde te gustara encontrarte?
ACOPLAMIENTO
07 Una visin
APLICACIONES
PROCESOS
SERVICIOS
CONTENEDORES DE INFORMACIN
08 Una visin
Arquitectura Orientada a Servicios como alternativa, no como nico camino. Una nueva (De verdad es nueva?) perspectiva del mismo escenario. Una filosofa distinta para construir. Se proyecta una arquitectura y se promueve una infraestructura. El mirar desde esta perspectiva conlleva un cambio de estrategia.
09 Una visin
Dejamos en un segundo plano a los aplicativos para centrarnos en los procesos. Lo que ya tenemos lo adaptamos. Planteamiento de integracin.
Mala filosofa la de tirar y empezar de nuevo
10 Una visin
Beneficios:
Independencia entre los servicios y los consumidores Reutilizacin Una mayor adaptacin al cambio Integracin
11 Una visin
En el momento en el que se hace una puesta en comn y se centraliza una actividad necesitamos responder a:
Quin planifica? Quin dimensiona? Quin determina las directrices para la definicin de servicios?
12 Una visin
Gobierno SOA:
Funciones:
13 Una visin
Granularidad no unifirme en los servicios Mltiples caminos para realizar operaciones integradoras Carencia de un modelo de datos comn Sin unas directices, la reutilizacin sera complicada Registro de servicios
14 Una visin
15
Definir un piloto correctamente acotado La adopcin de SOA debe hacerse progresivamente, proyecto a proyecto. 2 o 3 aos para consolidar Despus de esos 2 o 3 aos, los problemas ms graves se centrarn en la sostenibilidad y mantenibilidad. La clave est en el gobierno.
Cuando tengas que elegir, pondera todo lo que puedas el uso de estndares.
16 Caso de estudio
Se desea implantar un conjunto de aplicaciones para satisfacer unas necesidades de distintas unidades orgnicas dentro de una universidad.
Todas estas aplicaciones tienen en comn la necesidad de tramitar ciertos procedimientos administrativos. La universidad cuenta con un motor de tramitacin:
WAR
Contenedor JSP/Servlet
El motor de tramitacin dispone de una herramienta de gestin con interfaz web Para la integracin del motor con nuevas aplicaciones se dispone de un API.
PL/SQL
17 Caso de estudio
motor-api.jar
otras.jar
motor-api.jar
otras.jar
WAR
Contenedor JSP/Servlet
PL/SQL
Oracle MySQL
18 Caso de estudio
Algunas notas:
Seguimos teniendo aplicaciones monolticas que comparten un API Dependencia del marco tecnolgico Integracin a nivel de compilacin Un cambio (nuevas funcionalidades, mejoras de rendimiento, errores) en la API... ejem ejem
19 Caso de estudio
otras.jar
Aplicacin 2 .NET
MySQL
WAR
WS
Contenedor JSP/Servlet
PL/SQL
Oracle
20 Caso de estudio
21
OpenESB 2.0 beta Lo encontramos dentro de Java Application Platform SDK Update 3 Preview 2
Herramientas disponibles:
22
Su arquitectura
23
Pieza clave:
24
Binding components
Email BC FTP BC HTTP BC HL7 BC JDBC BC LDAP BD etc...
Service engines
25 Conclusiones
En corporaciones, instituciones y administraciones Tienen relaciones horizontales y verticales y en sus actuaciones intervienen mltiples departamentos, centros directivos, etc. En definitiva, porque necesitan interoperar!
Por qu?
26 Conclusiones
Comn denominador en tus aplicaciones (gestin de la identidad, firma electrnica, gestin de procesos (grandes o pequeos), etc) Los sistemas actuales no satisfacen los requisitos funcionales de una forma usable. El nivel de integracin Cada vez que se solicita un cambio, el reponsable de desarrollo tiembla. Nos plateamos constantemente rehacer cosas. Existe multiplicidad de la informacin, tenemos que sincronizar ;(
SOA, una perspectiva - Manuel J. Recena Soto
27 Conclusiones
Al igual que xhtml y css permiten un casi desacoplamiento entre con contenido/informacin y la forma/representacin, SOA nos permite desacoplarnos de la tecnologa, de los contenedores de informacin, etc..
28 Conclusiones
Procesos: overflow veces Servicios: overflow veces Estratega: overflow veces Perspectiva: overflow veces Gobierno: overflow veces Integracin: overflow veces
29 Agradecimientos
A Jaime Cid por compartir sus conocimientos y experiencias A http://www.flickr.com/people/shuttersparks de donde he tomado la fotografa para la portada A Alberto Molpeceres por sus consejos A mi actual empresa (GMV SGI) por darme la oportunidad de adquirir experiencia y formacin