Presentación

SOA y estándares: una pareja inseparable
Javier Cámara
Coordinador del grupo de "SOA Infrastructure and Governance
practices", Software AG
SOA y estándares | 23/may/2007 | Seite 1
Software AG, ¿quiénes somos?
Una sólida compañía SW
¬ Segunda compañía europea de software
¬ 500 M € de facturación
¬ 38 años de experiencia en TI
¬ Más de 3.000 empleados, presencia en 70 países
¬ 700 empleados en España
¬ Líderes en tecnología para:
¬ Sistemas transaccionales empresariales
¬ Adabas, Natural, …
¬ Arquitecturas Orientadas a Servicios (SOA)
¬ Crossvision
¬ Inminente adquisición de webMethods
¬ Importante división de servicios profesionales
SOA y estándares | 23/may/2007 | Página 2
SOA
SO
A
SOA
A
SO
SO
A
SO
A
SOA
SOA everywhere
SOA
Pocos habrá que trabajen en informática y no hayan oído algo sobre SOA
Muchas organizaciones usuarias de TI están estudiando una “adopción de
SOA”, y virtualmente todos los fabricantes de software están alineando su
estrategia con SOA
Supone el cambio de mayor magnitud que está sufriendo el mercado de TI
hoy en día
SOA dominará el espacio de las TI durante los próximos años
Pero, ¿qué importancia tienen los estándares en SOA?
SOA y estándares | 23/may/2007 | Página 3
¿Qué es eso de SOA?
Service-Oriented Architecture (Arquitectura Orientada a Servicios)
Arquitectura (estructura general) de un sistema de información en la que la
funcionalidad se implementa en pequeños elementos separados, discretos y
reutilizables, llamados servicios
Servicio
Elemento de un sistema de información que ofrece una serie de
funcionalidades a través de unas interfaces programáticas bien definidas
Y eso, ¿para qué sirve?
Permite la reutilización de la funcionalidad existente
Eso, a su vez aumenta la agilidad empresarial
¿Y qué hay de nuevo en esto?
SOA y estándares | 23/may/2007 | Página 4
¿Qué tiene SOA de nuevo?
Principios, pocos:
¬ Modularidad
¬ Reutilización
¬ Bajo acoplamiento
¬ Separación de interfaz e implementación
¬ Independencia de la implementación
¬ Programación en base a contratos
¬ Lógica por un lado, en los servicios (M); presentación por otro (V y C)
Si son cosas tan manidas, ¿por qué está tan de moda ahora? ¿Por qué es algo
tan importante para las TIs ahora?
SOA y estándares | 23/may/2007 | Página 5
¿Por qué SOA ahora?
Para poder
Reutilizar
Para eso se
necesita
Independencia
algo, como mínimo hay que poder invocarlo
de la implementación
Incluyendo plataforma, herramienta, fabricante y ubicación en la red
Si no, cambios en la implementación afectan a sus consumidores y
limitan drásticamente esa reutilización
Eso requiere
Y eso es
realidad ahora
gracias a
Soporte
universal
de la tecnología utilizada para
implementar la SOA
(Al menos, tan “universal” como sea necesario en un
entorno dado)
Si no, dependes de que “el otro” utilice tecnología
compatible con la tuya, lo cual puede no ser cierto
HTTP, XML, SOAP, WSDL, …
SOA y estándares | 23/may/2007 | Página 6
¿Por qué SOA ahora?
Los principios de SOA son viejos, pero sólo ahora existen los estándares
soportados universalmente y que proporcionan la interoperabilidad
necesaria para que aquéllos puedan llevarse a cabo en la práctica
¬ WS-*
Anteriores tecnologías de componentes y similares sólo gozaban de un
soporte parcial por parte del mercado
¬ Lo cual limitaba en la práctica la interoperabilidad y, de ahí, todo lo
demás
SOA y estándares | 23/may/2007 | Página 7
Pero, entonces, ¿SOA es lo mismo que
servicios web?
NO
Desde el punto de vista conceptual, una SOA se puede implementar con
múltiples tecnologías
¬ MOM, POJOs, EJBs, DCOM, CORBA, COBOL, …
Aunque cuando se consigue realmente la máxima reutilización es cuando se
utilizan los estándares más ampliamente soportados
¬ Reutilización de funcionalidades por otros consumidores
¬ Reutilización de funcionalidades de otros servicios
¬ Aprovechamiento de otras herramientas, al poder interactuar con ellas
¬ Conocimiento del personal
¬ Capacidades ofrecidas por estándares adicionales
SOA y estándares | 23/may/2007 | Página 8
SOA es una abstracción del éxito de los servicios web
para integración de sistemas de información
Más abstracción
SOA
B2B
Servicios web
ESB
EAI
Middleware
SOA y estándares | 23/may/2007 | Página 9
Otras
tecnologías
¿Qué aportan las especificaciones WS-* a una SOA?
¬ Funcionalidad de infraestructura tecnológica
¬ Comunicaciones, seguridad, descubrimiento, gobierno operacional,
gestión, transacciones, …
¬ Implementación de infraestructura tecnológica
¬ Servidores de WS, ESBs, agentes, registros / repositorios,
administración, gobierno, …
¬ Sun, IBM, Microsoft, BEA, Oracle, SAP, Software AG, Apache,
ActiveEndpoints, Vordel, AmberPoint, webMethods, IONA, …
¬ Herramientas de desarrollo
¬ Sun, IBM, Microsoft, BEA, Oracle, Software AG, Eclipse,
ActiveEndpoints, …
SOA y estándares | 23/may/2007 | Página 10
¿Qué aportan las especificaciones WS-* a una SOA?
¬ Posibilidad de interoperar con sistemas de negocio
¬ SAP, Oracle (Siebel, PeopleSoft, Vantive), SalesForce, Microsoft
(Dynamics); iWay, SeeBurger, …
¬ Personal que los conozca (desarrollo y administración)
¬ Cada vez más
¬ Evolución en el futuro
¬ En general, aprovechamiento del trabajo del resto del mercado
SOA y estándares | 23/may/2007 | Página 11
Pues si hay estándares y mercado que los soporte, ¡una
SOA con servicios web debe ser algo muy sencillo!
Aprovisionamiento
Presentación
Construcción, orquestación, composición
Com. fiables
Transacciones
Recursos, eventos
Descubrimiento
Seguridad
Gestión de
datos
Descripción
Gestión operacional
Estructura general de las especificaciones WS-*
Mensajería
Cimientos
Extensiones
SOA y estándares | 23/may/2007 | Página 12
Desarrollo
Gestión
Fuente: Burton Group
¡Parece que las especificaciones WS-* crecen
en los árboles!
SOAP
BPEL
SAML
UDDI
WSDL
¬ Decenas de estándares y especificaciones
¬
HTTP, HTTPS, XML, XML Namespaces, SOAP, RPC-document-encoded-literal, SOAP con
anexos, WS-I Profiles, WSDL, XML Schema, UDDI, WS-BPEL, WS-Addressing, WSReliableMessaging, WS-Transaction, WS-Policy, WS-Security, SAML, WS Resource
Framework, WS-Notification, XOP, MTOM, XML Infoset, WS-MetadataExchange, WSDiscovery, XPath, XSL-T, XQuery, DOM, SAX, StAX, … y hay más cosas a las que
un
desarrollador en WS-* puede tener que enfrentarse
¬ La curva de aprendizaje parece una escalada
¬ Y no sólo hay demasiados, sino que además:
¬ Tienen un nivel de adopción muy variable (entre “nadie” y “todos”)
¬ A veces la especificación es mala o complicada, resultando en soporte
parcial y problemas de interoperabilidad
¬ A menudo la implementación es inmadura
SOA y estándares | 23/may/2007 | Página 13
Y encima, hay competidores de WS-*
¬ En el ámbito de la informática empresarial, todo el mundo soporta WS-*
¬ Si bien en un grado muy variable
¬ Pero en el ámbito de Internet y Web 2.0, es bastante menos popular
¬ REST tiene cierta adopción
¬ Aunque le faltan muchísimas cosas que sí ofrece (u ofrecerá) WS-*
¬ Incluso JSON, que no es ni XML, goza de cierto éxito
SOA y estándares | 23/may/2007 | Página 14
Pero sin estándares, no hay interoperabilidad,
ni reutilización, ni SOA
¬ ¿Por qué hablamos de Arquitecturas Orientadas a Servicios, y no de
Arquitecturas Orientadas a Objetos?
¬ Porque ningún estándar de comunicaciones orientado a objetos fue
adoptado por todo el mundo
¬ CORBA, DCOM, RMI: usando uno, nunca llegabas a todo el mundo
¬ Sin adopción universal no hay interoperabilidad, y sin eso no hay nada
¬ OO sólo ha tenido éxito a nivel de programa, no de arquitectura
¬ HTTP y XML es lo único que todo el mundo soporta
¬ Gracias a ello existe interoperabilidad, reutilización y agilidad
¬ Pero para poder aprovechar realmente todas las promesas de la SOA, es
necesario soportar muchos más estándares de forma universal
SOA y estándares | 23/may/2007 | Página 15
Software AG.
Bright ideas, everywhere.
SOA y estándares | 23/may/2007 | Seite 16