SOA y Web Services: Fundamentos y Arquitectura

SOA y Web
Services
Óliver Centeno Álvarez
Junio 2011

Junio 2011 SOA y Web Services 1

Objetivos
 Conocer la arquitectura SOA, su función, ventajas y
diseño
 Mostrar los lenguajes y protocolos implicados en la
arquitectura SOA
 Mostrar una panorámica de las distintas
aproximaciones tecnológicas a SOA
 Demostrar la creación y consumo de Web Services
existentes mediante las tecnologías más extendidas


Requisitos
 Conocimientos previos:
 Experiencia
en desarrollo con Java
 Conocimientos de Arquitecturas o Ingeniería de
Software
 Requisitos técnicos:
 VirtualPC2007
 Al menos 1GB de memoria RAM (recomendado
2GB)


Contenidos
I. Fundamentos
II. Arquitectura SOA
III. XML Web Services
IV. Implementando XML Web Services
V. RESTful Web Services
VI. Interoperabilidad
VII. Arquitectura ESB


Contenidos
I. Fundamentos


I. Fundamentos
1. Motivación
2. Arquitecturas de Software
3. Necesidad del Contrato
4. Modelado de Componentes
5. Retos


1. Motivación
 Intercambio de información
 Procesamiento
 Sinintervención del usuario
 Acelerando tiempos de respuesta
 Normalización
 Entre plataformas
 Entre lenguajes
 Entre sistemas operativos


1. Motivación
 Buenas prácticas
 Reutilización
 Modularidad y encapsulamiento
 Nuevos retos
 Portabilidad
 Interoperabilidad
 Computación distribuida
 Internet


I. Fundamentos
1. Motivación
5. Retos


 Formas de organizar las partes que componen un sistema
software
 A nivel físico (cliente, servidor, consumidor,…)
 A nivel lógico (capas, módulos, subsistemas,…)
 Permiten separar las partes que componen un sistema
complejo de manera adecuada
 Aumenta la modularidad y la reutilización
 Aumenta el entendimiento del sistema
 Mejora el mantenimiento
 Mejora la validación y verificación


 Evolución histórica


 MVC
 Modelo
 Vista
 Controlador

 Utilizado en aplicaciones
gráficas y Web


 DAO y 3+1 capas
 Separa el acceso a datos Presentación
(DAO) de los datos (Modelo) M
Negocio o
 Permite utilizar el modelo en d
todas las capas e
 Permite reemplazar DAO sin Persistencia l
o
afectar al resto DAO

BD


I. Fundamentos
1. Motivación
5. Retos


 Las arquitecturas de software permiten estructurar un
sistema
 Pero, ¿cómo se ensamblan las partes?
 Principio de desarrollo
 Maximizar la cohesión
 Minimizar el acoplamiento
 En otras palabras
 Que cada parte sea autosuficiente
 Y que dependa lo mínimo de las demás partes


 Las arquitecturas no garantizan esto
 Necesitamos conceptualizar más cada parte

 Cuestiones:
 El puerto USB sirve para muchas cosas pero…
 ¿Cómo funciona un puerto USB?
 ¿Cómo funciona un dispositivo USB?
 ¿Por qué funciona un dispositivo USB?


 Contrato (Especificación):
 Acuerdo entre las partes para cumplir una serie de especificaciones
enumeradas
 Requisitos…
 ¿Programación?

 Interfaz:
 Conjunto de métodos especificados que debe proporcionar una clase de
implementación
 Importa el QUÉ y no el CÓMO
 NO ES HERENCIA MÚLTIPLE


 Programación Bajo Contrato
 Definir siempre las interfaces de especificación de cada
subsistema (interfaz proporcionada)
 Implementar cada módulo utilizando las interfaces
proporcionadas de los subsistemas asociados (interfaz
requerida)
 Se apoya en el polimorfismo: utilizar objetos que son a la
vez de distintos tipos
 Permite construir partes dependientes de otras sin que estas
estén terminadas


 Ejemplo: Interfaz
public interface Tabla{
public void conectar();
public void desconectar();
public boolean insertar();
}

 Importa poder conectar y desconectar
 Importa poder insertar
 No importa qué base de datos
 No importa qué tabla ni qué columnas


 Ejemplo: Lógica
public class GestorBD{
private Tabla tabla;
public GestorDB(Tabla t){
tabla = t;
}
public boolean añadir(){
tabla.conectar();
boolean resultado = tabla.insertar();
tabla.desconectar();
return resultado;
}
}


 Ejemplo: Implementación
public class TablaOracle implements Tabla{
public void conectar(){ … }
public void desconectar() { … }
public boolean insertar() { … }
}

public class Programa{
public static void main(String[] args){
Tabla t = new TablaOracle();
GestorDB g = new GestorDB(t);
g.añadir();
}
}


I. Fundamentos
1. Motivación
5. Retos


 Interfaz:
 Colección de operaciones que especifican un servicio proporcionado
(implementado) o solicitado (utilizado) por una clase o componente.

 Componente:
 Parte lógica y reemplazable del sistema.
 Conforma y proporciona la realización de un conjunto de interfaces.
 Cumple los principios de modularidad y encapsulamiento.
 Son bloques de construcción, “ladrillos”.


 Diagrama de Componentes
 Ilustran las piezas del software, controladores embebidos,
etc. que conformarán un sistema.
 Con un nivel de abstracción más alto que un diagrama de
clase.
 Eventualmente un componente puede comprender una gran
porción de un sistema.
 Se descompone el sistema en base a interfaces que
representan las líneas de separación entre subsistemas.


 Representación UML

Componentes

Componente

componente

Interfaz requerida Interfaz proporcionada


 Ejemplo
 Buscador de citas por Internet
 Un Controlador requiere una interfaz Servicio para invocar a
buscaAfines() y buscaIdeal()
 Esta interfaz la implementa ServicioParejas que, a su vez
requiere poder trabajar contra una Base de Datos
PersonaDaoOracle
Controlador ServicioParejas
s : Servicio dao : DAO insertar()
buscar() buscarAfines() actualizar()
buscarIdeal() eliminar()
buscar()
DAO listar()
Servicio insertar()
actualizar()
buscarAfines()
eliminar()
buscarIdeal()
buscar()
listar()


 Principios del desarrollo basado en componentes
 Encapsulación e Interfaces:
 Si un módulo cambia internamente sin modificar su interfaz, dicho cambio
no provocará cambios en otras partes del sistema
 Abstracción:
 Un usuario del componente no necesita saber como esta implementado el
modulo para comprender la funcionalidad ofertada
 Arquitectura del sistema
 Cómo se organizan los componentes
 Conectividad entre componentes
 Centra y prioriza las decisiones del desarrollo


4.Modelado de
Componentes
Veamos un Ejemplo


I. Fundamentos
1. Motivación
5. Retos


5. Retos
 Computación Distribuida
 Poder realizar un conjunto de operaciones de
cálculo de manera cooperativa entre varias
máquinas
 Las máquinas se conectan mediante una red
 El resultado se compone a partir de los resultados
parciales


5. Retos
 Interoperabilidad
 Poder comunicar máquinas distintas y software
distinto para realizar computación distribuida
 Poder invocar aplicaciones creadas para una
plataforma desde otra totalmente distinta


5. Retos
 Integración
 De datos, de aplicaciones, de componentes, de
negocio (EAI)
 Síncrona o asíncrona
 Mediante sockets, RPC, RMI, colas, DCOM, ETL,
…
 ¿Sistemas heredados?


5. Retos
 Computación en Internet
 Poder llevar los conceptos de computación
distribuida a Internet
 Aplicando medidas de seguridad pertinentes
 Atravesando cortafuegos
 Utilizando estándares de facto


Contenidos
I. Fundamentos


1. Tecnologías de Integración
2. Problemas
3. ¿Qué es SOA?
4. Servicios, Web Services y SOA
5. Ejemplos de Aplicación


 Existen muchas propuestas para integrar aplicaciones
distribuidas
 Objetivo:
 Comunicar máquinas remotas
 Ejecutar tareas de manera cooperativa
 Integrar sistemas heterogéneos
 Integrar aplicaciones “legadas”
 Distinciones:
 Caso de Aplicaciones compatibles (homogéneas)
 Caso de Aplicaciones incompatibles (heterogéneas)


 DCOM
 Distributed Component Object Model
 Tecnología de Microsoft para programación con objetos distribuidos
 Problema: Sólo disponible para Windows lo que limita la
interoperabilidad
 Java RMI
 Remote Method Invocation
 Distribución de objetos “Java-to-Java”
 Problema: No es independiente del lenguaje ya que exige utilizar Java


 CORBA
 Common Object Request Broker Architecture by OMG
 Estándar para comunicar objetos distribuidos independiente del
lenguaje utilizado
 Problema: hay problemas de interoperabilidad porque no garantiza que
los participantes implementen la especificación completa
 RMI sobre IIOP
 Java RMI que utilizar IIOP de CORBA para la comunicación
 Utilizado para acceder a EJBs (Enterprise JavaBeans)
 Problema: Depende de CORBA para la comunicación y de Java para
la implementación


2. Problemas
3. ¿Qué es SOA?


2. Problemas
 Rendimiento y escalabilidad
 Gestión
 Cumplir la falta de acoplamiento
 Transaccionalidad, seguridad, estado
 Conversión de protocolos
 Versionado
 Firewalls y otros elementos de seguridad
 Ancho de banda
 Evaluación de la causa raíz de los problemas
 Coste de desarrollo, integración y pruebas


2. Problemas
3. ¿Qué es SOA?


3. ¿Qué es SOA?
 Arquitectura Orientada a Servicios
 N-capas
 Importa el servicio ofrecido

Cliente
Seguridad
Gestión
Cliente
Servidor
Cliente Validación


3. ¿Qué es SOA?
 Arquitectura que utiliza servicios como bloques de
construcción para facilitar la integración y reutilización de
componentes empresariales a través de un bajo acoplamiento
 ¿Cómo?
 Utilizar servicios para implementar las capas
 Los servicios NO SON LIBRERÍAS pero se parecen
 Tienen funcionalidad pero esperan a ser invocados
 No importa el lenguaje de programación ni el entorno, sólo que
cumplan con su cometido


3. ¿Qué es SOA?
 Ventajas
 Aprovecha los estándares abiertos para representar los servicios
 Permite ver los servicios como bloques de construcción que pueden ser
reutilizados en el desarrollo de otros aplicaciones
 Permite centrarse en ensamblar bloques en vez de en los detalles de
implementación
 Se puede utilizar internamente para crear nuevas aplicaciones a partir
de componentes existentes
 Puede utilizarse externamente al integrarse con las aplicaciones fuera
de la empresa


3. ¿Qué es SOA?
 Terminología utilizada en SOA
 Servicio
 Funcionalidad publicada
 Orquestación y coreografía
 Coordinación de servicios para implementar una lógica
determinada
 En la orquestación hay un director, en la coreografía no
 Sin estado
 Los servicios no dependen unos de otros y se pueden orquestar de
distintas maneras
 Proveedor
 Consumidor


3. ¿Qué es SOA?
 Exige un cambio de mentalidad
 Los servicios NO SON LIBRERÍAS
 NO SIRVEN PARA TODO
 NO SON RÁPIDOS
 ESTÁN PENSADOS PARA SISTEMAS HOMOGÉNEOS
 Servicios poco acoplados pero altamente interoperables
 Basados en una definición independiente de plataforma
 Alta reusabilidad
 Poco sensible a cambios
 Permite modelos de
 Consumo de terceros
 Colaboración
 Integración de tecnologías


3. ¿Qué es SOA?
 Ciclo de Vida de SOA
 Modelado
 Capturar, analizar, simular y optimizar modelos
 Reducir el riesgo y aumentar la flexibilidad
 Ensamblado
 De componentes nuevos y antiguos
 Para ejecutar y gestionar procesos de negocio
 Despliegue
 Gestión
 Análisis de la información de negocio derivada
 Para tomar acciones coordinadas y “a tiempo”


3. ¿Qué es SOA?
 Capas SOA
 Aplicaciones básicas (SD)
 Sistemas geográficamente dispersos
 Exposición de funcionalidad (WS)
 Como Web Service para su consumo
 Integración de servicios (ESB)
 Facilitando el intercambio de datos empresariales
 Composición de procesos (BPM)
 Modelando un proceso en términos del negocio y sus necesidades
 Entrega
 Desplegando los servicios para el usuario final


2. Problemas
3. ¿Qué es SOA?


 Servicio
 Funcionalidad empaquetada como un componente
reutilizable en procesos de negocio
 Expuesto mediante una interfaz bien definida
 Que aparece como una función autocontenida
 Que utiliza mensajes para ocultar la implementación
 Por tanto no importa cómo se ha desarrollado
 Que no depende del estado de otros servicios
 Que proporciona información o realiza modificaciones en
los datos de negocio


 XML Web Service
 Servicio identificado por una URI
 Definido, descrito y descubierto mediante XML
 Que utiliza XML como soporte de sus mensajes
 Cuyos protocolos de mensajes están basados en Internet
 Que no almacena estado
 RESTful WebService
 Servicio identificado por una URI
 Cuyos protocolos de mensajes están basados en Internet
 Que no almacena estado


 SOA es una arquitectura basada en servicios
 Se centra en la disposición de los servicios al crear
aplicaciones
 Los Web Services son un caso particular de servicio
 Pueden utilizarse para crear una SOA
 Pero no tiene estado
 Cada petición debe ser autocontenida
 No podemos valernos de la información del servidor
 No podemos utilizar variables de sesión
 No debemos utilizar cookies


2. Problemas
3. ¿Qué es SOA?


 Transporte
 Ofertar precios realistas se hace difícil cuando los envíos viajan a través
de múltiples operadores
 Banca
 Necesidad de proporcionar servicios bancarios a múltiples clientes
 Necesidad de integrar un gran número de aplicaciones internas
 Gobierno
 Necesita compartir y acceder a datos a través de
distintas agencias
 Internet
 Necesidad de realizar búsquedas rápidas de distintos contenidos


 Interoperabilidad entre sistemas heterogéneos
 Interacciones B2B
 La encapsulación de los sistemas heredados
 Aislamiento de la evolución de los sistemas
 Empresa normalización de los servicios
 Integración de paquetes de terceros
 Coordinación de procesos
 Desarrollo de portales


Contenidos
I. Fundamentos


III.XML Web Services
1. Definiciones
2. El protocolo SOAP
3. Documentos WSDL
4. Registros UDDI


1. Definiciones
 ¿Qué es un Servicio Web?
 Según Wikipedia:
“… es un conjunto de protocolos y estándares que sirven para intercambiar
datos entre aplicaciones.”

 De otra forma:
“A través de una interfaz estándar … permite el funcionamiento de una serie
de sistemas heterogéneos como un conjunto integrado.”

 Simplificando:
“Cada uno de los componentes de un sistema diseñado para soportar
interoperabilidad entre máquinas sobre Internet.”


1. Definiciones
 ¿Qué es un Servicio Web XML?
 Según Microsoft:
“… es una entidad programable que proporciona un elemento
de funcionalidad determinado, como lógica de aplicación …
(accesible) mediante estándares de Internet … como XML y
HTTP.”

 Según Sun:
“… es un componente software con las siguientes
características: 1) Es accesible a través del interfaz SOAP, 2)
Su interfaz se describe en un documento WSDL.”


1. Definiciones

 Simplificando más:
 Interfazaccesible a través de Internet
 Alojada en un Servidor Web
 Que permite invocación remota de procesos
 Autocontenido, Autodescrito, Modular e Independiente de
Plataforma
 Estándares (XML, SOAP, HTTP)
 Modelo de Proxy


1. Definiciones
 Fundamentos:
 Intercambio de información
 Normalización
 Entre plataformas
 Entre lenguajes
 Entre sistemas operativos
 Escenarios:
 Simple
 Publicación de información
 Integración de Aplicaciones
 Permite realizar tareas remotas
 Soluciones de Flujo de Trabajo (Workflow)
 Integrados con BizTalk, Sun ONE, ServiceMix,…


1. Definiciones
 Modelo de Proxy:
 Componentes ubicados en servidores diferentes que deben comunicarse
de manera transparente.
 Un Proxy “se hace pasar por el objeto remoto”
 El objeto cliente usa el Proxy como si no hubiera una red

Objeto Objeto
Cliente referencia remota Remoto

Proxy Referencia Remota
RED TCP


1. Definiciones

 Infraestructura


1. Definiciones

 Estándares:
 XML
 XSD

 HTTP

 SOAP

 WSDL

 UDDI


1. Definiciones
3. Documentos WSDL
4. Registros UDDI


 Simple Object Access Protocol
 Invocación remota basada en XML
 Mensaje estructurado en XML con posibilidad de
implementar múltiples formatos, seguridad etc.
 Microsoft (1.0), IBM (1.1), Sun
 Contiene llamadas y respuestas de procedimientos
 Trata de sustituir a formatos propietario


 SOAP Message
 Un mensaje SOAP es un elemento Envelope con una cabecera opcional
y un cuerpo obligatorio

<soap:Envelope>
<soap:Header> ... </soap:Header>
<soap:Body>
<metodo>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</metodo>
</soap:Body>
</soap:Envelope>


 SOAP Message
 Mensaje de Respuesta

<soap:Envelope>
<soap:Header> ... </soap:Header>
<soap:Body>
<metodoResponse>
<metodoReturn>
El producto es 25.0
</metodoReturn>
</ metodoResponse>
</soap:Body>
</soap:Envelope>


 Permite separar meta-información del mensaje
 Información de enrutado
 Información de expiración
 …
 Define
 Un modelo de proceso
 Un mecanismo para manejar errores
 Un mecanismo para representar datos
 Un convenio para RPC
 Un marco para vincular protocolos


 Ventajas:
 XML plano --> ubicuidad de componentes
 Comunicación HTTP --> no cortafuegos
 IPSec o SSL proporcionan seguridad
 Escalable a conjuntos de servidores


 Motores SOAP
 Framework que se utiliza en servidores y clientes para
facilitar
 La serialización de objetos a SOAP
 La deserialización de mensajes SOAP a objetos
 La validación de la estructura de los mensajes
 SOAPpy
 Implementado en Python y Axis


 Motores SOAP


 Mensajes de error
 SOAP Fault XML <Fault>
 <faultcode>
ID del error
 <faultstring>

Descripción breve
 <detail>

Detalles del error


1. Definiciones
3. Documentos WSDL
4. Registros UDDI


3. Documentos WSDL
 Web Services Description Language
 Lenguaje de descripción del Servicio Web
 Describir interfaces de Servicios Web
 Independiente de la implementación
 Métodos disponibles, parámetros y retorno
 Mapeado a SOAP de manera unívoca


3. Documentos WSDL
 Web Services Description Language
 Define una o varias operaciones
 Incluyendo los mensajes que reciben
 Y los mensajes que devuelven
 Descritasde forma abstracta
 Concretadas en el endpoint
 Protocolo
 Formato de mensaje
 Dirección de Red


3. Documentos WSDL
<definitions>  Web Services Description Language
<types/>  types: Declaraciones de tipos de dato
<message/> habitualmente en XSD
<part/>  message: Definición abstracta de mensajes y sus
</message> tipos de dato (part)
<portType>  portType: Operaciones soportadas por el servicio
<operation/> y los mensajes que se les envía y/o recibe
</portType>
(operation)
<binding/>  binding: Formato de mensaje y protocolo que se
<service>
debe utilizar para invocar las operaciones
<port/>  service: Colección de endpoints cada uno
</service>
representado por un puerto en una dirección de red
y con un nombre de binding
</definitions>


3. Documentos
WSDL
Veamos unos documentos
WSDL


1. Definiciones
3. Documentos WSDL
4. Registros UDDI


4. Registros UDDI
 Universal Description, Discovery & Integration
 Catálogo de negocios de Internet
 Páginas amarillas
 Páginas blancas
 Páginas verdes
 Accedido por mensajes SOAP para obtener
documentos WSDL


4. Registros UDDI
 Universal Description, Discovery & Integration
 Mecanismo de descubrimiento de Servicios Web
disponibles
 Publicación de Servicios Web
 Descubrimiento de Servicios


Contenidos
I. Fundamentos


IV. Implementando XML Web
Services
1. Tecnologías J2EE para WS
2. Apache AXIS
3. Creación de WS en Java
4. Creación de WS en .Net
5. Publicación de Web Services
6. Consumo de Web Services


 El API SAAJ
 SOAP with Attachments API for Java
 Se emplea para escribir mesajes SOAP
directamente en lugar de utilizar un generador
 Permite escribir y leer mensajes SOAP
 Algunas implementaciones permiten enviar y
recibir mensajes SOAP
 Paquete:
javax.xml.soap

 El API SAAJ sin archivos vinculados
 SOAPMessage <Message>
 SOAPPart <Part>
 SOAPEnvelope <Envelope>
 SOAPHeader <Header>
 SOAPBody <Body>

 Se generan con el SOAPMessage


 El API SAAJ sin archivos vinculados


 El API SAAJ con archivos vinculados
 AttachmentPart
 Hay que crearlos a mano
 Debe contener una cabecera MIME

 Tipo de contenido

 Opcionalmente tendrá contenido


 El API SAAJ con archivos vinculados


 El API SAAJ. Conexión
SOAPConnectionFactory factory =
SOAPConnectionFactory.newInstance();
SOAPConnection conexion =
factory.createConnection();
//Crear un mensaje SOAP de request
java.net.URL endpoint = new URL("http:
//...");
SOAPMessage respuesta = conexion.call
(request, endpoint);


 El API SAAJ. Acceder al contenido
SOAPBody cuerpo = respuesta.getSOAPBody();
//Lectura del cuerpo
for(SOAPBodyElement elemento : cuerpo.
getChildElements(Name)){
String valor = elemento.getValue();
}
//Modificación del cuerpo
SOAPBodyElement docElement = cuerpo.
addDocument(documento);


 El API SAAJ. Attachments
//Crear y añadir
AttachmentPart adjuntos = message.
createAttachmentPart();
adjuntos.setContent("texto", "text/plain");
adjuntos.setContentId("id");
message.addAttachmentPart(adjuntos);

//acceder a contenidos
for(AttachmentPart att : message.getAttachments()){
String id = att.getContentId();
String type = att.getContentType();
Object content = att.getContent();
}


 El API JAX-RPC
 Java API for XML-Based RPC
 Permite construir aplicaciones y Servicios Web con
funcionalidades RPC basadas en XML
 Cumple la especificación SOAP 1.1
 JAX-RPC 2.0 ha sido renombrado a JAX-WS 2.0

https://jax-rpc.dev.java.net/


 El API JAX-RPC


 El API JAX-WS
 Tecnología Java para construir clientes y Servicios Web
basados en XML
 Orientados a mensajes
 Orientados a RPC
 Oculta la complejidad de SOAP
 Se crea un objeto Proxy que invoca a los métodos del
Servicio
 Se requiere la anotación javax.jws.WebService para que la
clase se comporte como WS
 Se habla de endpoint del WS


 JAX-WS Endpoint
 Un endpoint requiere:
 javax.jws.WebService/WebServiceProvider
 @WebService
 No admite métodos finales ni estáticos
 javax.jws.WebMethod
 Parámetros compatibles con JAXB
 Clase no abstracta ni final
 Con un constructor público por defecto
 Sin destructor (finalize)


 El API JAX-WS


 JAX-WS Endpoint
import javax.jws.WebService;

@WebService()
public class Hello {
private String message = new String(“Hola, ");
public Hello() {}

@WebMethod()
public String sayHello(String name) {
return message + name + ".";
}
}


 JAX-WS Client
 Un cliente requiere:
 javax.xml.ws.WebServiceRef
 @WebServiceRef(wsdlLocation="http://...")
 Un campo estático que referencie el servicio
static HelloService service;
 Un proxy al servicio con el que trabajar
Hello port = service.getHelloPort();
 Utilizar el proxy para invocar métodos
String response = port.sayHello(name);


 JAX-WS Client
import javax.jws.WebServiceRef;

public class HelloClient {
@WebServiceRef(wsdlLocation = "http://localhost:
8080/helloservice/hello?wsdl")
static HelloService servicio;

public static void main(String[] args) {
Hello puerto = servicio.getHelloPort();
String respuesta = puerto.sayHello(args[0]);
System.out.println(respuesta);
}
}


 JAXR (Java API for XML Registries)
 Permite acceder a registros de negocio basados en UDDI y
otros (ebXML)
 https://jaxr.dev.java.net/
 Proyecto privado
 Requiere hacerse miembro para consultarlo
 Se incluye en el proyecto GlassFish
com.sun.connector.jaxr
javax.xml.registry


Services
2. Apache AXIS


2. Apache AXIS
 Librerías que permiten ejecutar Servicios Web
 Servlet para desplegar y replegar servicios
 Libreria WSDL.jar general el WSDL de Servicios
 Parámetros de entrada/salida y métodos a invocar

 http://ws.apache.org/axis/

org.apache.axis.client


2. Apache AXIS
 Cliente y Servidor SOAP open source
 Implementa el API JAX-RPC
 2006 v1.4 Final
 Axis2 implementa JAX-WS
 Se utiliza con el servidor Tomcat
 Posible desplegarlo en otros
 WebLogic
 GlassFish


2. Apache AXIS
 Desplegar un Servicio manualmente
 Copiar el .class del Servicio en la carpeta
classes dentro de Axis
 Copiar el .java del Servicio con extensión .jws en
la raíz del Axis desplegado
 Para que se genere el WSDL


2. Apache AXIS
 Desplegar un Servicio por línea de comandos
 Fichero .wsdd describe el Servicio
 XML específico de AXIS
 Desde el directorio ejecutar
java -cp %AXISCLASSPATH% org.apache.axis.client.
AdminClient
-lhttp://localhost:8080/axis/services/AdminService
deploy.wsdd


2. Apache AXIS
 WSDL2Java
 Aplicación Java que genera clases a partir de un documento
WSDL
 Para cada <port> genera una clase Proxy
 Para cada <portType> una interfaz (SEI)
 Para cada <binding> un stub que implementa el SEI
 Para cada <service> una interfaz de servicio y su
implementación para localizar el proxy

java org.apache.axis.wsdl.WSDL2Java “fichero-WSDL”


2. Apache AXIS
 Java2WSDL
 Aplicación Java que genera clases a partir de un
documento WSDL
 java org.apache.axis.wsdl.Java2WSDL
-o “fichero-WSDL”
-l“url del servicio”
-n <espacio de nombres>
-p “package” “namespace”
“fichero-CLASS”


2. Apache AXIS
 Consumir un Servicio con AXIS
import org.apache.axis.client.Call;
import org.apache.axis.client.Service;
import javax.xml.namespace.QName;

public class TestClient{
public static void main(String [] args) {
String endpoint = "http://nagoya.apache.org:5049/axis/services/echo";
Service service = new Service();
Call call = (Call) service.createCall();
call.setTargetEndpointAddress(new java.net.URL(endpoint));
call.setOperationName(new QName("http://soapinterop.org/",
"echoString") );
String ret = (String) call.invoke( new Object[] { "Hello!" } );
System.out.println("Sent 'Hello!', got '" + ret + "'");
}
}


Services
2. Apache AXIS


 En Eclipse desde un JavaBean



 Contenido generado:
 Librerías jar
 Servlet en web.xml
 Fichero wsdl
 Ficheros wsdd de AXIS



 Probando el Web Service
 Botón derecho en el WSDL
 Web Services > Test with Web Services Explorer
 Permite configurar múltiples endpoints
 Incluye una ventana de estado que muestra los
mensajes SOAP
 Permite probar el WSDL sin necesidad de nada
más


 En JDeveloper desde un JavaBean


Services
2. Apache AXIS


 Tipo especial de clase
 Extensión ASMX (Visual Studio 2005)
 WCF Web Service (Visual Studio 2010)
 Los métodos a publicar se marcan con el atributo WebMethod
 VB

<WebMethod()> _
Public Function TraerDatos() As String[]
End Function
 C#

[WebMethod]
public String[] TraerDatos(){
}


 Fichero .asmx indica que es un servicio Web
<%@ WebService Language = "C#" CodeBehind =
"~/App_Code/Service.cs" Class = "Service" %>

 Código en /App_Code/Service.cs
public class Service : System.Web.Services.
WebService{
public Service () { }

[WebMethod]
public string HelloWorld() {
return "Hola a todos";
}
}


 [WebService(Namespace = "http://...")]
 Indica el espacio de nombres del servicio
 Distinto del namespace de C#
 Describe el servicio para el descubridor UDDI
WebService(Namespace=“...”, Description=“…”)]
 [WebMethod(Description = "…")]
 Delantede la declaración de los métodos
 Parámetros como siempre


Services
2. Apache AXIS


 En JDeveloper



 Creado desde Visual Studio, sólo es necesario
publicarlo como un sitio Web
 Usando las herramientas de publicación de
VS2005
 http
 ftp
 Front Page Server Extensions
 ¡Copiar y pegar!



 Manualmente:
1. Alojar el servicio en un servidor local (IIS)
 Publicando el servicio en una carpeta
2. Activar el servidor Web
 Indicando el directorio local con el servicio
 Añadirlo a IIS (*)
3. Añadir una referencia Web al proyecto
4. Consumir


Services
2. Apache AXIS


 En JDeveloper


 En .Net
 Crearun proyecto
 Botón derecho > “Agregar Referencia Web”…
 Buscándolo por UDDI
 Utilizando el vínculo al WSDL

 Llamando al Servicio Web con ?wsdl

 Explorando los Servicios de la Solución

 Explorando los Servicios de la máquina local


localhost.Externos objeto;


Contenidos
I. Fundamentos


1. Introducción a los Servicios REST
2. Comparativa con SOAP
3. Implementación de Servicios REST


 REpresentational State Transfer
 Tesis de Roy T. Fielding (2000)
 Coautorde los estándares HTTP y URI
 Cofundador de Apache
 Se han empezado a utilizar porque
 Los Servicios XML son complicados
 Requieren mucha infraestructura lógica
 Al final vamos a utilizar HTTP
 Simplificar el modelo


 Principios de REST
 No tienen estado
 Tienen una interfaz uniforme
 No hay WSDL pero se usan los verbos HTTP
 POST, GET, PUT, DELETE,…
 Se basa en la representación de recursos
 URI + Secuencia de bytes + tipo MIME (txt, xml, json, jpeg,…)
 http://localhost/clientes
 http://localhost/clientes/1234
 http://localhost/pedidos/567/cliente
 Los mensajes están autodescritos
 HATEOS (Hypermedia As The Engine Of application State)


 HATEOS
 Cada respuesta del servidor debe contener todas las URI
que permitan llevar a un siguiente paso
 Todas las posibles transiciones de estado que pueda
realizar el usuario desde el estado actual se representan
mediante URI
 Si no lo cumple no es un servicio RESTful
 No es necesario almacenar el estado en variables de sesión
ni en cookies
 Se identifican los recursos mediante la URI


 Otros principios de REST
 No depender de un único protocolo de comunicación
 Describir dentro del servicio los tipos MIME que
representan los recursos
 No utilizar nombre fijos para los recursos
 Definir las normas para crear URIs válidas en base a los
tipos MIME y el estado actual
 Utilizar un punto de entrada fijo pero que todas las
transiciones las guíe el cliente


 SOAP está más extendido
 Tiene múltiples extensiones
 WS-Extensions, WS-I,…
 Pensadas para la integración de aplicaciones empresariales
 Existen multitud de plataformas de generación de código
 JAX-RPC, JAX-WS, AXIS, …
 Existen entornos ESB que utilizan interfaces WSDL para la
integración de aplicaciones
 Apache ODE, Mule, MQ,…
 El formato document/literal es similar a REST
 Envío de un documento XML encapsulado en SOAP


 La red es una de las aplicaciones más exitosas del planeta
 HTTP es suficientemente general y claro para crear aplicaciones robustas y
escalables
 Los desarrolladores tienden a la complejidad
 Un problema complejo no implica que la solución también lo sea
 SOAP es muy complejo y REST muy simple
 “WS-Estrella de la muerte” Vs “RESTafaris”
 Razonamiento de Occam
 Alternativas SOA
 Comprar un ESB estándar y adaptarte a él
 Comprar el mejor ESB y aprender a manejarlo
 Hacértelo tú mismo
 ¿cómo?, SOAP, REST, formato propio


 Tabla comparativa
Principio SOA Servicios XML Servicios REST
Interpoerabilidad Excelente Buena
Bajo acoplamiento Excelente Excelente
Reutilización Excelente Buena
Fácil descubrimiento Excelente Pobre
Simplicidad Pobre Excelente
Mantenibilidad Buena Buena
Extensibilidad Excelente Pobre
Rendimiento Bueno Excelente
Escalibilidad Buena Pobre


 Los Servicios REST se basan en los verbos de HTTP
 POST, GET, PUT, DELETE
 Y en los tipos MIME de datos enviados
 text/plain, text/xml, image/jpeg,…
 En general se puede decir que REST utiliza actividades CRUD
 Create, Read, Update, Delete
 Cada operación del servicio va a estar disponible dado un
verbo HTTP y uno o varios tipos de contenido MIME


 Mediante JAX-RS
 Basado en el JSR 311
 Define anotaciones para mapear servicios RESTful
 @GET, @POST, @PUT,…
 Implementaciones
 RESTeasy de JBoss

 RESTpack de Mule

 Jersey de Sun

 NetBeans 6 incluye una implementación de Jersey IDE con
ejemplos preconfigurados


 Mediante Jersey
 Requiere las librerías
 Jersey-server
 Jersey-core
 Asm

 1º Crear un Servlet mapeado a "/*"
<servlet>
<servlet-name>RecursoREST</servlet-name>
<servlet-class>
com.sun.jersey.spi.container.servlet.ServletContainer
</servlet-class>
</servlet>
<servlet-mapping>
<servlet-name>RecursoREST</servlet-name>
<url-pattern>/*</url-pattern>
</servlet-mapping>


 Mediante Jersey
 2º Crear una clase de implementación anotada a un path

@Path("/raiz")
public class Servicio{
}

 3º Anotar los métodos de recursos
 Con un verbo HTTP y un tipo de contenido MIME a consumir y/o producir
 Se puede ampliar el path siempre bajo el raíz
 Se localiza en /raiz/saludo

@GET
@ProduceMime("text/xml")
@Path("/saludo")
public String hola(){
}


 Parámetros de entrada
 Parámetros del Path
 Indicar la parte del path que hace de parámetro entre llaves
 @Path("/raiz/{var}")
 Admite expresiones regulares (Ej. Número de 3 dígitos)
 @Path("/raiz/{var: d{3}}")
 Anotar el parámetro con
 @PathParam("var") int x
 Parámetros de la QueryString (?var1=valor&var2=valor&…)
 @QueryParam("var") @DefaultValue("7") int y
 Parámetros de formulario
 Anotar el método con
 @Consumes("application/x-www-form-urlencoded")
 @FormParam("parametro") String z


 Parámetros de retorno
 Tipos sencillos (nativos + fechas + String)
 @Produces(“text/plain”)
 Tipos XML y JSON
 Devolver el contenido como String pero con el tipo MIME adecuado
 Tipos Response
 return Response.ok(contenido, tipoMIME).build();
 Tipos Object
 1º Anotar el objeto con anotaciones JAXB
@XmlRootElement(name=“persona”) public class Persona{
@XmlElement(name=“id”) int id;
@XmlElement(name=“nombre”) String nombre;
}
 2º Devolver el objeto con tipo MIME “application/xml”


 Clientes REST con Jersey
 Requiere las librerías
 Jersey-client
 Jersey-core
 1º Crear un objeto cliente
ClientConfig cfg = new DefaultClientConfig();
Client cliente = Client.create(cfg);
 2º Obtener el recurso Web apuntando a la URL base
URI url = URI.create(“http://localhost:8080/raiz”);
WebResource recurso = cliente.resource(url);


 Clientes REST con Jersey
 3º Consumir el recurso
 Añadir paths opcionales a la URL
recurso.path("subrecurso");
 Indicar el tipo MIME a recoger/enviar
recurso.accept(MediaType.TEXT_XML);
recurso.accept(MediaType.TEXT_XML);
 Invocar al verbo HTTP con el tipo de retorno esperado
String respuesta = recurso.get(String.class);
 Los verbos POST y PUT requiere datos a enviar
ClientResponse r = recurso.put(ClientResponse.
class, datos);


Contenidos
I. Fundamentos



1. Concepto de Interoperabilidad
2. XML Schemas
3. Implementación de la Interoperabilidad


 La característica fundamental de los Web Services es la
interoperabilidad
 Pero, ¿Qué es interoperabilidad?
 Condición mediante la cual sistemas heterogéneos pueden
intercambiar procesos o datos
 Una definición más genérica
 “Propiedad de los sistemas de producción, cuyas interfaces son
perfectamente conocidas, para trabajar con otros sistemas de
producción presentes o futuros sin restricciones de acceso o
implementación”.


 Más sencillo
 Integración a distintos niveles tecnológicos
 Datos, mensajes, componentes, aplicaciones, servicios,
procesos,…
 Para
 Integrar procesos de negocio incompatibles
 Unificar datos usados en distintos sistemas
 Unificar tecnologías
 Unificar tiempos de ejecución (batch + OLTP)
 …



 Interoperabilidad sintáctica
 Posibilidad de intercambiar datos entre dos sistemas
heterogéneos
 Transformación de datos: XSLT

 Interoperabilidad semántica
 Posibilidad de entender y ser capaz de utilizar los datos
intercambiados
 Definición de datos: XSD


 La interoperabilidad exige que los tipos de datos
utilizados como parámetros en los Web Services
tengan una correspondencia con los tipo XSD
 Porque ya existan (tipos nativos)
 Porque sean composición de éstos (clases sencillas
mapeadas a complexType)
 No se admiten tipos complejos
 List, Array, Map, DataSet, …
 En el mejor de los casos se mapean a array [ ]



2. XML Schemas


2. XML Schemas
 En documentos XML a veces es necesario
 Especificar una relación entre los elementos del documento
 Verificar la corrección de los datos
 Verificar la integridad de los datos
 Tener un entendimiento compartido
 Se comprueba:
 Elementos o atributos declarados en el esquema.
 Estructura jerárquica de elementos y atributos.
 Orden de los elementos.
 Valores de atributos y elementos.
 Unicidad de valores.


2. XML Schemas
 XML Schema (XSD)
 Fichero de validación XML
 Sintaxis XML
 Nodos y tipos (primitivos y derivados)
 Soporta la extensión del documento
 Se puede utilizar para transformar el documento en una
jerarquía de objetos
 NO mapea los métodos
 Utiliza espacios de nombres (namespaces)


2. XML Schemas
 <xsd:element
name=“nombre_nodo”
type=“tipo_dato”
default=“valor por defecto”
fixed=“valor fijo”
minOccurs=“cardinalidad mínima”
maxOccurs=“cardinalidad máxima”>
 <xsd:attribute
name=“nombre_atributo”
type=“tipo_dato”
use=“optional o mandatory”
fixed=“valor fijo” >
 <xsd:complexType
mixed=“true o false”>


2. XML Schemas
 Tipos Primitivos:  Tipos Derivados:
 string  integer (decimal)
 boolean  long (integer)
 decimal  normalizedString (string)
 float  token (normalizedString)
 double  Name (token)
 dateTime  ID (Name)
 date  IDREF (Name)
 time  ENTITY (Name)
 …  …


2. XML Schemas
 Mapeo de Objetos Cliente
<xsd:element name="Cliente"> +fechaNac:Date
+direccion:String
<xsd:complexType>
<xsd:all>
<xsd:element name="fechaNac"
type="xsd:date" />
<xsd:element name=“direccion"
type="xsd:string" />
</xsd:all>
</xsd:complexType>
</xsd:element>


2. XML Schemas
Base
+a:int
 Mapeo de Herencia -b:int
<xsd:complexType name=“Base”> -c:int
<xsd:all> +getB():int
<xsd:element name="a" type="xsd:int" /> +setB(int)
<xsd:element name="b" type="xsd:int" />
</xsd:all>
</xsd:complexType>
<xsd:complexType name=“Derivada”>
<complexContent>
<extension base=“Base”> Derivada
<xsd:all>
+x:int
<xsd:element name=“x" type="xsd:int" />
</xsd:all> -y:int
</extension>
</complexcontent>
</xsd:complexType>


2. XML Schemas

Veamos un ejemplo



2. XML Schemas


3. Implementación de la
Interoperabilidad
 Estrategias
 Rápida y de bajo coste de integración
 WSI (WebServices Integration)
 Crear un WS para el sistema a integrar
 Se crean los tipos necesarios para ese sistema
 Poco reutilizable
 Sistemática y de inversión a futuro
 SOI (Service Oriented Integration)
 Diseñar la arquitectura SOA antes de nada
 Interfaces y modelo de datos comunes y centralizados


Interoperabilidad
 Bottom-up
 Generar un SEI y el documento WSDL a partir de una clase de
implementación
 Ventajas: Fácil de implementar y generar
 Desventajas: Podrían utilizarse objetos complejos no serializables
 ●Top-down
 Generar un SEI a partir de un WSDL existente
 Implementar el servicio a partir de esta interfaz
 Ventajas: Se asegura desde la definición que el servicio va a ser
totalmente interoperable
 Inconvenientes: Más costoso de implementar


Interoperabilidad
 ¿Qué pasa con los estándares?
 HTTP  W3C
 XML  ISO
 SOAP  ECMA
 WSDL  OASIS
 …  …
 Estandarizar los estándares
 WS-I.org (no confundir con WSI)
 Web Services Interoperability Organization
 Promoción de interoperabilidad desde el SW libre


Interoperabilidad
 WS-I
 Integrador de estándares
 Guía, recomienda buenas prácticas y proporciona recursos
para el desarrollo
 Pero no desarrolla estándares
 Para
 Lograr la interoperabilidad de WS
 Lograr que se adopte el modelo de WS
 Acelerar el despliegue de WS


Interoperabilidad
 Perfiles WS-I (Profiles)
 Basic 1.0
 SOAP + WSDL + XSD + UDDI
 Basic 1.1
 Basic 1.0 + Attachments
 SwA (SOAP with Attachments)
 Basado en MIME
 No Microsoft
 MTOM (Message Transmission Optimization
Mechanism)
 MIME + codificación Base64


Interoperabilidad
 Se debe:
 Usar HTTP para SOAP
 Usar HTTP 500 para faltas SOAP
 Usar método POST
 Usar WSDL 1.1
 Usar RPC/literal o document/literal
 No se debe:
 Extender/restringir <soapenc:ArrayType>
 Usar RPC/encoding
 Usar operaciones de tipo notificación
 Usar <wsdl:import> para otra cosa que no sea WSDL


Interoperabilidad
 Arrays
 Existe el tipo <soapenc:ArrayType>
 No existen tipos Collection, NO LOS USES
 List, Map, Set, Dictionary, DataSet,…
 Ejemplo:

<xsd:element name="MiArray" type="tns:TipoArray"/>
<xsd:complexType name="TipoArray">
<xsd:sequence>
<xsd:element name="item" type="xsd:string"
minOccurs="0" maxOccurs="unbounded"/>
</xsd:sequence>
</xsd:complexType>
</xsd:element>


Interoperabilidad
 Tips
 Se puede validar un WSDL contra WS-I
 Se puede generar cumpliendo con un perfil WS-I
 Se recomienda el enfoque Top-Down (primero el WSDL)
 Se recomienda usar siempre document/literal
 Se recomienda usar clases tipo JavaBean
 Se recomienda realizar pruebas sistemáticas
 Los mensajes SOAP grandes ralentizan la comunicación
 Los ficheros SOAP complejos también
 Máximo 100KB y 10 niveles de anidación en el SOAP


Contenidos
I. Fundamentos



1. Origen y Motivación
2. Integración de Aplicaciones
3. Modelo ESB


Usuarios

Imagenes
unificadas de datos

Sistemas
existentes
Network Colaboración Contenido Utilitarios Heredados Paquetes


Usuarios

Procesos de negocio
traducidos en
tecnología

Sistemas
existentes
Network Colaboración Contenido Utilitarios Heredados Paquetes

*Extraído de “ESB: Enterprise Services Bus ” de Jorge Humberto Arias


 En una empresa se deben integrar datos, procesos de
negocio, soluciones,…
 Sin caer en un caos que nos lleve al fracaso
 Tener distintas clases Cliente según sistema o Base de Datos…
 Interesa
 Poder dirigir la integración por procesos de negocio
 Localizando las funcionalidades base del proceso
 Pudiendo acceder de modo síncrono y asíncrono
 Que soporte y conviva con la “historia”
 SOA + EDA


 EDA
 ArquitecturaDirigida por Eventos
 Propuesta para la integración de sistemas heredados
 Automatizar la generación de mensajes y el envío de los
mismos por medio de eventos


 Hay muchas formas de integrar aplicaciones nuevas
 ¿Y las antiguas?
 Sistemas heredados/legados (legacy)
 Sistemas grandes difíciles de tratar pero vitales para el
negocio
 Sistemas menos competitivos que otros más modernos
pero con prohibitivo coste de reemplazo
 Antiguos, monolíticos y difíciles de modificar



3. Modelo ESB


 Intrusiva
 Modificar el código
Interfaz de Usuario
 No intrusiva
 Añadir una capa de abstracción
que utilice la aplicación de Servicio
manera transparente
Lógica de aplicación

Datos


 Estrategias
 MBS (Message Bus Architecture)
 Se tiene un bus por el que fluyen mensajes entre las aplicaciones
 Cada aplicación está conectada al bus mediante un adaptador específico
 Switch de Protocolos
 Un motor genérico se encarga de utilizar los distintos tipos de protocolo en
cada caso
 SOAP, CORBA, MOM, Remoting,…
 Gateway
 Un programa “pasarela” comunica las aplicaciones
 Se encarga de las transformaciones necesarias



3. Modelo ESB


3. Modelo ESB
Sistem Atención al Sistema de
cliente CORBA facturación

JMS
RMI SOAP
Servicios de negocio

Enterprise Service Bus (ESB)

Conectores
técnicos


3. Modelo ESB
Estándares
WSP

Infraestructura de servicios no-funcionales Prácticas
( Transacciones, seguridad, BPM, etc.) para
el diseño
de servicios
o
adaptación
Bus de Servicios
Infraestructura/Framework de webservices

Servicio/Adaptador Servicio/Adaptador Servicio/Adaptador

Clientes

Fuente:
Burton Group Plataforma de Plataforma de Plataforma de
negocio A negocio B Negocio C


3. Modelo ESB
 Un buen ESB debe
 Soportar multiprotocolo (SOAP, CORBA, MOM, B2B,…)
 Soportar WSP (Web Services Platform)
 Motor SOAP
 Framework para crear WebServices
 Frameworks adicionales (WS-Eventing, WS-Transaction, WS-Security,
WS-BPEL,…)
 Implementar adaptadores de integración
 Para sistemas legados, CRMs, ERPs,…
 Permitir orquestar procesos de negocio
 Permitir transacciones y transformaciones


3. Modelo ESB
 Algunos ESB
 Libres
 Mule (http://mule.codehaus.org/)
 WSO2 (http://wso2.com/products/enterprise-service-bus/)
 Apache ServiceMix (http://servicemix.apache.org/home.html)
 Comerciales
 Fiorano (http://www.fiorano.com)
 BizTalk (http://www.microsoft.com/biztalk/)
 JBoss (http://www.jboss.org/jbossesb)
 IBM WebSphere (http://www-01.ibm.com/software/integration/wsesb/)
 Oracle (http://www.oracle.com/technologies/soa/service-bus.html)


Muchas Gracias

Óliver Centeno Álvarez


SOA y Web Services: Fundamentos y Arquitectura

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

En vedette

En vedette (20)

Similaire à SOA y Web Services: Fundamentos y Arquitectura

Similaire à SOA y Web Services: Fundamentos y Arquitectura (20)

Plus de Oliver Centeno

Plus de Oliver Centeno (20)

Dernier

Dernier (20)

SOA y Web Services: Fundamentos y Arquitectura

Notes de l'éditeur