Arquitectura Orientada a Servicios

(SOA)

Billy Reynoso
Universidad de Buenos Aires
billyr@microsoft.com.ar
Objetivos
Comprender el estilo de arquitectura más
adecuado para soluciones de integración
Caracterizar SOA (una iniciativa de industria) en
términos formales
Establecer relación con estilos arquitectónicos
de mayor grado de semejanza
Analizar puntualmente la relación entre SOA y
Web Services
SOA como arquitectura, WS como implementación
Identificar los recursos de estado de arte para la
realización de esta arquitectura
Suministrar referencias de utilidad académica
Agenda
SOA en la industria - Muestreo
Definiciones
Contexto de situación y antecedentes
Principales conceptos
SOA como Estilo de Arquitectura
Relaciones de SOA con Web Services
Diferencias con Objetos o Componentes distribuidos
Distintas concepciones: IBM, Rational, Sun, Microsoft,
REST
Perspectivas: SOA & Grid Computing - SOA & Semantic
Web
Recursos de SOA
Conclusiones, referencias y recursos
SOA en la industria - Muestreo
“La recompensa potencial [de SOA] es enorme para las
empresas que entiendan esta evolución y se muevan hacia
estas arquitecturas. ... La tecnología de computación
distribuida promete ser lo suficientemente flexible y elegante
para responder a las necesidades de negocios y proporcionar
la agilidad de negocios que las compañías han anhelado
tanto tiempo, pero siempre ha estado fuera de alcance”. [The
Rational Edge, 2004]
“La mejor solución a la integración de negocios...” [Annraí
O’Toole, Cape Clear]
“SOA ha surgido como la mejor manera de afrontar el desafío de
hacer más con menos recursos. Promete hacer la re-utilización y
la integración mucho más fáciles, ayudando a reducir el tiempo
de desarrollo y aumentando la agilidad organizacional. No
sorprendentemente, el 80% de las organizaciones de IT están
implementando aplicaciones usando SOA con web services
subyacentes. SOA proporciona mayor flexibilidad para afrontar
los cambios tanto en el ambiente de negocios como en la
infraestructura tecnológica”. [M7 Corporation]
SOA en la industria - Muestreo
“SOA es la próxima ola de desarrollo de aplicaciones. Es más
rápida, mejor y más barata” [Michael Pallos, 2001]
“Comprender el rol y el significado de SOA, más allá del hype
simplista, es imperativo para cualquier arquitecto de software
empresarial. ... Hacia 2008, SOA y Web Services serán
implementados juntos en más del 75% de los proyectos que utilicen
SOA y Web Services (probabilidad 0.7)” [Gartner, 2003]
“Hacia 2008, más del 75% de los paquetes de aplicación de ese
entonces serán nativamente SOA o expondrán interfaces SOA a
través de una capa de envoltura de interfaces (probabilidad 0.8)”
[Gartner, 2003]
“Hacia 2008, SOA será la práctica prevalente de ingeniería de
software, acabando con los 40 años de dominación de las
arquitecturas monolíticas (probabilidad 0.7)” [Gartner, 2003]
“Giga recomienda a los arquitectos considerar SOA como la
prioridad número uno en sus esfuerzos de planeamiento
arquitectónico” [Giga IT Trends 2003: Application architecture and
design]
Contexto de situación y
antecedentes
Evolución de la arquitectura:
Vertical Horizontal Ecosistema
Estructurado

Client/Server
Monolítico

Web Services
distribuidos

Componentes

Servicios
Objetos
N-Tier
3-Tier,

Abstracción
 Propiedades
  Programación Objetos Componentes Servicios
Estructurada

Granularidad Muy fina Fina Intermedia Gruesa

Contrato Definido Privado/Publico Publico Publicado

Reusabilidad Baja Baja Intermedia Alta

Acoplamiento Fuerte Fuerte Débil Muy débil

Tiempo de Tiempo de Tiempo de

Dependencias Compilación Compilación Compilación Run-Time

Ámbito de Intra- Intra- Inter-

Comunicación Aplicación Aplicación Aplicaciones Inter-Empresas
Historia
SOA no se deriva de una propuesta
académica
No hay technical reports de SOA en SEI
Service-oriented architecture fue descripta
por primera vez por Gartner en 1996
SSA Research Note SPA-401-068, 12 de
abril, “‘Service Oriented’ Architectures, Part
1” y SSA Research Note SPA-401-069, 12 de
abril, “‘Service Oriented’ Architectures, Part
2”
Web Services surgen con mayor fuerza
hacia el 2000.
Historia
XML Web Services®
SOA = XML+SOAP+WSDL+UDDI+Bus
SOAP 1.0 - Específico de
MS+Developmentor
XML + HTTP
SOAP 1.1 - MS+IBM+Lotus
Bindings de transporte para no-HTTP
SOAP 1.2 - W3C.org (ya no es más
acrónimo)
SOA - Definiciones
W3C: “Conjunto de componentes que pueden ser
invocados, cuyas descripciones de interfaces se
pueden publicar y descubrir”
CBDI rechaza esa definición:
Los componentes pueden no ser conjuntos
La definición sólo considera los componentes y no la
práctica o el arte de construir la arquitectura
CBDI: “Estilo resultante de políticas, prácticas y
frameworks que permiten que la funcionalidad de
una aplicación se pueda proveer y consumir como
conjuntos de servicios, con una granularidad
relevante para el consumidor. Los servicios pueden
invocarse, publicarse y descubrirse y están abstraídos
de su implementación utilizando una sola forma
estándar de interface”
SOA - Definiciones
“Infraestructura de alto nivel basada en best practices
y patrones para crear soluciones basadas en
servicios, de alta cohesión y bajo acoplamiento”
(Geniant®).
“Estilo arquitectónico apto para implementar bajo
acoplamiento entre agentes. Los agentes son
proveedores y consumidores de servicios, que son la
unidad de trabajo”. (Hao He).
“Una arquitectura de aplicación en la cual todas las
funciones se definen como servicios independientes
con interfaces invocables bien definidas, que pueden
ser llamadas en secuencias definidas para formar
procesos de negocios” (IBM).
SOA - Definiciones
MITRE:
Una aplicación SOA es una colección de servicios
Un servicio es la unidad atómica de una SOA
Los servicios encapsulan procesos de negocios
Los proveedores de servicios se registran solos
Un servicio involucra: Find, Bind, Execute
Las instancias más conocidas son los web services
Gartner:
“SOA es una arquitectura de software que comienza con una
definición de interface y construye toda la topología de la
aplicación como una topología de interfaces,
implementaciones y llamados a interfaces. Sería mejor
llamada “arquitectura orientada a interfaces”. SOA es una
relación de servicios y consumidores de servicios, ambos
suficientemente amplios para representar una función de
negocios completa”.
SOA como Estilo de
Arquitectura
Estilos de Flujo de Datos Estilos de Código Móvil
Tubería y filtros Arquitectura de Máquinas
Virtuales
Estilos Centrados en Datos
Estilos heterogéneos
Arquitecturas de Pizarra o
Sistemas de control de
Repositorio procesos
Estilos de Llamada y Arquitecturas Basadas en
Retorno Atributos
Model-View-Controller Estilos Peer-to-Peer
(MVC) Arquitecturas Basadas en
Arquitecturas en Capas Eventos
Arquitecturas Orientadas a
Arquitecturas Orientadas a Servicios
Objetos
Arquitecturas Basadas en
Arquitecturas Basadas en Recursos
Componentes
SOA como Estilo de
Arquitectura
Componente: Servicio
Conectores: Antes, RPC – Ahora, paso de
mensajes
Configuración: Distribuido
Constraint: Bajo acoplamiento,
independencia de modelo de programación,
independencia de plataforma, transporte y
protocolo por acuerdo de industria
Principales conceptos

CBDI - Perspectivas arquitectónicas

Aplicación - Servicio - Componente
 Implementaciones RPC
DCOM CORBA JAVA RMI WS
Protocolo RPC RPC IIOP IIOP o JRMP SOAP
Formato NDR CDR Java XML 1.0
mensaje Serialization Namespaces
Format
Descripción IDL OMG IDL Java WSDL
Descubrimiento Registry Naming Service RMI Registry o UDDI
JNDI
Marshalling Type Library Serialization
Marshaller

•WS no requiere despliegue
•WS no requiere clientes específicos, ni drivers
•SOA se redefine como paso de mensajes, no RPC
Componentes de SOA
Servicios: Entidades lógicas - Contratos definidos por una o más
interfaces públicas.
Service provider: Entidad de software que implementa una
especificación de servicio.
Service consumer (o requestor): Entidad de software que llama a un
service provider. Tradicionalmente se lo llama “cliente”. Puede ser
una aplicación final u otro servicio.
Service locator: Tipo específico de service provider que actúa como
registry y permite buscar interfaces de service
providers y sus ubicaciones.
Service broker: Tipo específico de service
provider que puede pasar requerimientos
de servicios a otros service providers.
Demo & Drilldown
SOA y Web Services
Web services: Diferentes definiciones en W3C Web
Services Architecture Working Group
W3C: “Una aplicación identificada por un URI, cuyas
interfaces y binding se pueden definir, describir y descubrir
mediante artefactos XML, que soporta interacciones usando
mensajes basados en XML via protocolos de web”
SOA es históricamente anterior (no por mucho)
Un web service es SOA si:
Las interfaces se basan en protocolos de web (HTTP, SMTP,
FTP)
A excepción de los attachments, los mensajes se basan en
XML
Dos estilos de web service: SOAP y REST
REST es anti-RPC (más sobre esto luego)
SOAP puede interpretarse en términos de mensajes o de
RPC (Don Box)
SOA y Web Services
CBDI:
SOA es más amplio. Los web services son
sólo una interface programática en
conformidad con los protocolos WS-*
Puede haber SOA sin WS (ej. REST)
Los web services proporcionan
independencia de plataforma, bajo
acoplamiento, auto-descripción y
descubrimiento
Los web services no son parte obligatoria
de SOA, pero son una implementación
adecuada
Estándares primarios - WSDL
XML que describe servicios
Propuesto por Microsoft e IBM y presentado
a W3C por 25 empresas (número máximo
admitido)
Define data types pasados en mensajes,
operaciones a realizar y mapeado de los
mensajes sobre transportes de red
Puede haber algunas discrepancias entre
diferentes implementaciones, debido a que
es extensible
Estándares SOA & Web
Services
http://WS-I.ORG
Framework de SOA

BPEL4WS – Reemplaza a XLANG (MS) y a lenguajes de workflow
de IBM
Estilo REST
REST - REpresentational State Transfer (Roy Fielding, 2000)
SOA sin Web Services, ni SOAP ni RPC
Arquitectura con modelo de datos (recursos, URIs y
representaciones XML)
Composición de diversos estilos: repositorio replicado, cache,
cliente-servidor, sistema en capas, sistema sin estado, máquina
virtual, código a demanda e interfaz uniforme
Modelo REST
Una aplicación REST transfiere representaciones
entre componentes usando conectores
Componentes: incluyen agentes de usuario (Mozilla,
cURL) y servidores de origen (Apache, IIS)
Los componentes de REST obedecen estas
restricciones:
las interaciones son stateless
los recursos se identifican mediante URIs
no hay tal cosa como servicios ni objetos, sólo recursos
no se permite el paso de cookies y se propone el reemplazo
de MIME (Multipurpose Internet Mail Extensions) por su discrepancia
arquitectónica con la semántica de HTTP
hypermedia es la máquina de estado de la aplicación
no hay necesidad de toolkits: sólo URIs y XML
SOAP versus REST
Polémica sobre el estilo dominante en SOA.
Abundancia de pullas:
“Give SOAP a REST” - “Otra vez SOAP” - “REST
could burst the SOAP bubble”, “Slippery
SOAP”
REST enfatiza el papel de los intermediarios:
caches, proxies, gateways, etc
REST es adecuado para transferencias y
transformaciones simples. Transacciones
complejas requieren sin duda SOAP.
No hay herramientas para implementar REST
rigurosamente; sí en cambio las hay para SOAP
RPC.
Idem en relación con middlewares
SOAP vs REST
80 implementaciones independientes de SOAP 1.1 en
2002 – Centenares a fines de 2005
ebXML adoptó SOAP como protocolo de base
SOAP incorporó ideas de ebXML a través de WS-*
Integridad de mensajes, no-repudio, mensajería confiable, flujo de
procesos de negocios, negociación de protocolos
SOAP puede alcanzar mejor performance porque puede
ser stateful y no tiene que trasmitir información de estado.
A la larga el comité de WSA en W3C no optó entre REST y
SOAP, sino que reformuló SOAP 1.2 adoptando ideas de
REST
“Intercambio asincrónico de documentos” ha ganado
mindshare a expensas de “RPC”
“Web services como objetos distribuidos” tiene cada vez
menos adeptos
DTD y tecnologías similares han sido eliminadas
SOA vs Objetos y Componentes
distribuidos
Los componentes ofrecían reutilización,
pero también acoplamiento relativamente
alto.
Las tecnologías seguían siendo propietarias.
“Aún cuando CORBA era un esfuerzo
ostensiblemente basado en estándares, en la
práctica se debía trabajar con una única
implementación comercial de la especificación”
[The Rational Edge]
El mercado de componentes no se
desarrolló como se había previsto
SOA vs Objetos y Componentes
distribuidos
Servicios APIs Beneficios
Pocas interacciones, de Muchas interacciones, Se requiere menos
grano grueso de grano fino comunicación y hay
menos sobrecarga
Cada interacción es la Cada interacción es Más fácil de
misma diferente implementar y
cambiar
Cada interacción es un Muchas interacciones Menos complejidad
paso en un proceso de para completar un cuando el consumidor
negocios. No hay proceso de negocios. o el proveedor deben
procesos o estados de Muchos procesos o cambiar. Sólo se
más bajo nivel. estados intermedios. requiere acordar
procesos o estados a
nivel de negocios.
Perspectiva académica :
SOA vs Objetos y Componentes distribuidos

Werner Vogels (Cornell University): Web Services y

SOA no son objetos distribuidos.
Los web services no requieren tecnología de
objetos distribuidos
El intercambio de documentos es un concepto
muy distinto a la instanciación de un objeto, la
invocación de un método de una instancia, la
recepción del resultado de la invocación y la
liberación final de la instancia.
Otros errores:
El debugging de web services es imposible...
Perspectiva académica :
SOA vs Objetos y Componentes distribuidos

Werner Vogels - Otros errores:

“Web services son sólo RPC para Internet”
En SOAP 1.2 RPC/encoded es opcional, y se
favorece document/literal
La interacción sincrónica en wide area no es
escalable, la coordinación de versiones será
siempre complicadísima
“Se requiere HTTP para tener servicios”
Soporte de protocolos diversos desde WSE y
en .NET Framework 2
Perspectiva académica :
SOA vs Objetos y Componentes distribuidos
Werner Vogels (cont.)
“Se requieren servidores de web para tener web
services”
“Web” debería haberse excluido, dejando
simplemente “services”
Hay herramientas que no requieren servidores de
web: Simon Fell’s PocketSoap, Systinet’s WASP,
IBM’s Emerging Technologies Toolkit, Microsoft’s
Web Services Enhancements (WSE).
Sistemas de integración de empresas como Artix y
DocSOAP proporcionan desarrollo de web services
que no requieren web servers
SOA & Grid Computing
Grid: Modelo de resolución de problemas usando
gran número de computadoras heterogéneas
organizadas en clusters
2003: alguna convergencia con web services
Open Grid Service Architecture (OGSA) implementa
fundamentalmente WSDL y SOAP (Globus Toolkit 3
framework)
Textos de Grid mencionan SOA como antecedente
Alchemi – Framework para Grid Computing en .NET,
utilizando .NET Remoting y web services
SOA & Grid Computing
SOA Standards Grid Standards
WSDL OGSI
UDDI Extensión de WSDL
BPEL WS-Resource
WS-Profile WS-ResourceLifetime
WS-ResourceProperties
WS-Security WS-RenewableReferences
WS-Choreography WS-ServiceGroup
WS-BaseFaults
Etcétera…
SOA & Semantic Web (1/3)

Semantic Web:
Propuesta por Sir Tim Berners-Lee
Creador del WWW en 1984 y el primer web site,
1991; fundador de W3C en el MIT. No royalties!!
Semántica comprensible para máquinas y
aplicaciones
Hay una semántica actualmente, pero en realidad
opera sobre correspondencias sintácticas (XML
Schemas)
SOA & Semantic Web (2/3)
Semantic web utiliza:
XML
XML Schema
RDF (Resource Description Framework)
Triplas de Sujeto + Predicado + Objeto
RDF Schema - Semántica de generalización y
jerarquía
OWL (Web Ontology Language)
Extensión de vocabulario de RDF
Cardinalidad, características,
equivalencias, relaciones
SOA & Semantic Web (3/3)

En curso: Integración de estándares de

industria con investigación académica
Desarrollos en proceso
DAML-S - (Darpa Agent Markup Language)
Agrega definiciones, pre-condiciones, pos-
condiciones etc a estándares usuales SOA
(Service Profile); también abstracciones de
proceso (Service Model) y aspectos técnicos
(Service Grounding)
SWOBIS = UDDI + ontología
Recursos de SOA en .NET

.NET Framework 1.0 (2000)

XML Schema 1.0, SOAP 1.1, WSDL 1.1, UDDI 1.0
(idem: J2EE1.4)
.NET Framework 1.1 (2002)
WS-Security, WS-Routing (HTTP, UDP, TCP), Direct
Internet Message Encapsulation (DIME: soporte
binario de cualquier tipo y tamaño en un solo
mensaje), WS-Attachments (en formato DIME)
Windows Server 2003
Device driver HTTP.SYS (modo kernel), UDDI
Server (registrar y publicar web services)
Innovaciones tecnológicas de
impacto arquitectónico:
Web Services Enhancements
Web Services Enhancements
No solamente web ni ASP.NET:
Las aplicaciones se pueden hostear en
múltiples ambientes
ASP.NET, .exe, NT Service, WinForms, etc.
Soporte para múltiples transportes
in-process communication (para testing)
TCP puro
HTTP
Soporte de operaciones prolongadas y
complejas
Drilldown: Mejoras en
seguridad
Políticas de seguridad basadas en
estándares de industria
Trust Issuing Framework (WS-Trust)
Secure Conversation (WS-
SecureConversation)
Autorización basada en roles
Policies de seguridad (WS-SecurityPolicy)
Trust

Relaciones e identidad: tokens de

seguridad con firma digital
¿Cómo pruebo quien soy?
¿Quién me puede avalar?
¿Cómo sabe usted que puede confiar en él?
WS-Trust define un protocolo para emitir y
obtener tokens de seguridad
Confianza (Trust) Token
Issuer
Diversos modelos para
emitir tokens
El cliente obtiene token Client Service
de una fuente bien
conocida
El servicio obtiene un
token para el cleinte
Etc… Token
Token Token Issuer
Issuer 1 Issuer 2

Client Service
Client Service
Conversación segura
WS-SecureConversation detalla la forma de
emitir un SecurityContextToken
En WSE, este token de peso ligero
reemplaza a los tokens que requieren
proceso intensivo
Requerimiento de SCT

SCT emitido al cliente Emisor del

Cliente Servicio
y el Token
Series de mensajes
firmados con el SCT emitido
Creando conversaciones
seguras
Los servicios pueden emitir sus propios
SCTs
Ya no hay necesidad de desplegar emisor
de SCT
Hay que tocar un elemento de configuración
<autoIssueSCT enabled=true />
Drilldown: Policy Driven Architecture
Más allá de WSDL ¿qué más se requiere para
describir un (web) service?
Requisitos de seguridad
Seguridades de mensaje confiable
Manejo de versiones de protocolo
Etc…
Estos y otros atributos de un servicio se pueden
describir con WS-Policy
Lenguaje basado en XML
Complejo: <Or>, <ExactlyOne>, etc…
WSE proporciona un Framework de Policy con
soporte del lado del que envía y del que recibe
Facilidades adicionales

Varios ejemplos
Security Settings Wizard
Standalone Config Editor
X509 Certificate Wizard para manejar los
certificados propios
Namespace
Viejo: Microsoft.Web.Services
Nuevo: Microsoft.Web.Service2
Recursos de SOA en Visual
Studio 2005
Team System
Engine de modelado y herramientas de
framework SOA en Visual Studio 2005
Resuelve el problema de roundtrip engineering
Incluye Distributed System Designers
Application Connection Designer
Class Designer
Logical Datacenter Designer
...
Desarrollo de SOA en Team
System
Application Connection Designer
Drag ExternalDatabase - Setear
propiedades
Exponer los datos via Web Service
Interface (Web Service Endpoint)
Drag ASP.NET web application
para generar interface visual
Listo...
Deployment de SOA
Logical Datacenter Designer
Definir IIS en Zone Desmilitarizada
(DMZ)
En la zona interior, un IIS
llamado AppServer y una
máquina que corre
SQL Server
Conectar mediante
Connection Tool
Agregar Restricciones a diagrama
lógico
Diseño con VS 2005 Class Designer
Sincronización de diagrama y código
Soporta diagramas similares a Class
Diagram de UML, pero con acceso a
métodos, propiedades, etc
Agregar diagrama de clase
Ver Class Details para ver y modificar interface
de la clase
También se pueden tratar clases de otros
assemblies referenciados
Conclusiones
SOA – El estilo de arquitectura más importante del
momento, en desarrollo simultáneo en la academia y la
industria
Cambio histórico en modelo de diseño, de programación y
de despliegue
Propiedad del código, control de la facturación por su uso
en ambientes de prueba y producción
Cambios sustanciales en modelo de negocios
Empresas ofrecen servicios a sus competidores
ISV ofrecen servicios a otros ISVs
Implementación posible de diversos modelos de
computación distribuida (Pizarra, agentes…)
Elaboración académica todavía pendiente
Recursos
Referencias
Referencias
Referencias
Referencias
Jason Bloomberg - “The role of the service-oriented
architect”. The Rational Edge,
http://www.therationaledge.com/may_03/f_bloomberg
.jsp
Marc Brooks (MITRE) - “Service Oriented Architecture
and Grid Computing”. http://web-
services.gov/Brooks32404.ppt
Ian Foster, Carl Kesselman, Jeffrey Nick, Steven Tuecke.
“Physiology of the grid”.
http://www.globus.org/research/papers/ogsa.pdf
Brian Randell, Rockford Lhotka - “Bridge the gap
between development and operation with Whitehorse”.
MSDN Magazine, Julio de 2004
Referencias
Werner Vogels - “Web services are not
distributed objects”.
Http://weblogs.cs.cornell.edu/AllThingsDistribut
ed/archives/000119.html - 2003
Luis Felipe Cabrera, Christopher Kurt, Don Box.
“An introduction to the Web Service Architecture
and its specifications”. MSDN Library, Setiembre
2004
Referencias
Roy Thomas Fielding. “Architectural styles and
the design of network-based software
architectures”. Tesis doctoral, University of
California, Irvine, 2000.
Kevin Mitchell. “A matter of style: Web Services
architectural patterns”. XML Conference &
Exposition 2002, Baltimore, 8 al 13 de
diciembre de 2002.
Http://www.ws-i.org
Billy Reynoso - Documentos de arquitectura en
http://www.microsoft.com/spanish/msdn/
arquitectura
¿Preguntas?
Billyr@microsoft.com.ar
http://www.microsoft.com/spanish/msdn/arquitectura