Web services y java

Web Services y Java
Óliver Centeno Álvarez

Marzo 2009 WebServices y Java [CMMi Project] 2
Objetivos
 Conocer el modelo SOA y sus
ventajas
 Mostrar los lenguajes y protocolos
implicados en la arquitectura SOA
 Mostrar una panorámica de las
distintas aproximaciones a SOA
disponibles en Java
 Demostrar la creación y consumo
de Servicios Web existentes

Contenidos
I. Fundamentos de XML
II. Tratamiento de XML en Java
III. Fundamentos de Web Services y
consumo desde Java
IV. Web Services con Apache AXIS
V. Autenticación en Web Services
VI. Transacciones en Web Services
VII. Caso Práctico

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 1. Fundamentos de XML 5
1. Introducción a XML
 eXtensible Markup Language
 Metalenguaje extensible de etiquetas
desarrollado por el W3C
 Simplificación y adaptación del SGML
 Se propone como un estándar para el
intercambio de información estructurada
entre diferentes plataformas
 Permite la compatibilidad entre sistemas
para compartir la información de una
manera segura, fiable y fácil

1. Introducción a XML
 Similar a HTML
 Etiquetas o “tags”
 Apertura y cierre
<etiqueta> </etiqueta>
 Autocerradas <etiqueta/>
 Pero más estricto
 Una etiqueta engloba a todas
 Todas las etiquetas cerradas
 No mezclar aperturas y cierres
 Válido: <a><b></b></a>
 Inválido: <a><b></a></b>

2. Origen de XML
 Años 70: IBM diseña GML para almacenar
grandes cantidades de información
 1986: Normalizado por la ISO  SGML
 Emplea gramáticas específicas definidas (DTD)
 1989: Nace HTML en el marco de SGML
 Poco exigente en cuanto a estructura
 1998: XML v1.0
 revisado 4 veces (última en 2006)
 2004: XML v1.1 revisado en 2006

2. Origen de XML
 Subconjunto del SGML que permite:
 Mezclar elementos de diferentes lenguajes. Es
decir que los lenguajes sean extensibles.
 Crear analizadores simples, sin ninguna lógica
especial para cada lenguaje.
 Que no se acepte nunca un documento con
errores de sintaxis.
 XML está orientado a hacer las cosas más
sencillas para los programas automáticos
que necesiten interpretar el documento.

3. Estructura de documentos XML
 Información estructurada
 Etiquetas o tags <etiqueta>
 Organizada en forma de árbol
 Un único nodo raíz
 Elementos
<elemento>…</elemento>
<elemento/>
 Atributos
<elemento atributo1=“valor1”
atributo2=“valor2” …>

10
<?xml version="1.0" encoding="ISO-8859-1" ?>
<Raiz_Mensaje>
<Mensaje>
<Remitente>
<Nombre>Nombre del remitente</Nombre>
<Mail> Correo del remitente </Mail>
</Remitente>
<Destinatario>
<Nombre>Nombre del destinatario</Nombre>
<Mail>Correo del destinatario</Mail>
</Destinatario>
<Texto>
<Asunto> ... </Asunto>
<Parrafo> ... </Parrafo>
</Texto>
</Mensaje>
</Raiz_Mensaje>

11
Raiz_Mensaje
Mensaje
Remitente Destinatario Texto
Nombre Mail Nombre Mail Asunto Parrafo

 Documentos bien formados I
 Han de tener una estructura estrictamente
jerárquica.
 Deben tener un único elemento raíz que
contenga a todos los demás.
 Los valores atributos siempre deben estar
entre comillas simples o dobles.
 Sensible a mayúsculas y minúsculas.
 Elementos delimitados por una etiqueta inicial
y otra final con el mismo nombre.
 Elementos vacíos autocerrados con /

 Documentos bien formados II
 Prólogo (opcional)
<!DOCTYPE Nodo_Raiz SYSTEM "Estructura.dtd">
 Cuerpo (obligatorio)
 Elementos y Atributos
 CDATA
<![CDATA[ contenido no procesado ]]>
 Comentarios

4. Validación de documentos
 Un documento "bien formado" solo se
refiere a su estructura sintáctica
 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
 Entendimiento compartido
 Nuevos lenguajes de marcado, para
aplicaciones específicas

 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.
 Se especifica en un documento externo
(documentos de definición)
 DTD y XSD

 DTD (Document Type Definition)
 Define los tipos de elementos, atributos
y entidades permitidas
 Un documento es "válido" si cumple las
reglas de un DTD determinada
 Puede ser un fichero externo o definirse
dentro del propio documento XML

<!ELEMENT Raiz_Mensaje (Mensaje)>
<!ELEMENT Mensaje (Remitente, Destinatario,
Texto)>
<!ELEMENT Remitente (Nombre, Mail)>
<!ELEMENT Destinatario (Nombre, Mail)>
<!ELEMENT Texto (Asunto, Parrafo)>
<!ELEMENT Nombre (#PCDATA)>
<!ELEMENT Mail (#PCDATA)>
<!ELEMENT Asunto (#PCDATA)>
<!ELEMENT Parrafo (#PCDATA)>

 <!ELEMENT>
 EMPTY (sin contenido)
 ANY (en desuso)
 #PCDATA
 Modificadores (|, ?, *, +)
 <!ATTLIST>
<!ATTLIST Nodo atributo CDATA #REQUIRED>
 CDATA (texto)
 NMTOKEN ( a A 1 . : - _ )
 ID, IDREF
 #REQUIRED, #IMPLIED

<!ELEMENT Raiz_Mensaje (Mensaje*)>
<!ELEMENT Mensaje (Remitente, Destinatario)>
<!ELEMENT Remitente (Nombre, Mail)>
<!ELEMENT Destinatario (Nombre, Mail)>
<!ELEMENT Nombre (#PCDATA)>
<!ELEMENT Mail (#PCDATA)>
<!ATTLIST Mensaje Asunto CDATA #IMPLIED
Parrafo CDATA #REQUIRED>

Raiz_Mensaje
Mensaje
Remitente Destinatario
Nombre Mail Nombre Mail
Asunto Parrafo

21
<Raiz_Mensaje>
<Mensaje asunto="…" parrafo="…">
<Remitente>
<Nombre>Nombre del remitente</Nombre>
<Mail> Correo del remitente </Mail>
</Remitente>
<Destinatario>
<Nombre>Nombre del destinatario</Nombre>
<Mail>Correo del destinatario</Mail>
</Destinatario>
</Mensaje>
</Raiz_Mensaje>

 Limitaciones:
 No existe jerarquía de nombres
 No existen tipos de datos
 Poco flexible a elementos mixtos
 No soporta nuevas ampliaciones de XML

 XML Schemas (XSD)
 Evolución de DTD descrita por W3C
 Más complejo y más potente
 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
 Utiliza espacios de nombres
(namespaces)

 <xsd:element>
 <xsd:attribute>
 <xsd:sequence>
 <xsd:choice>
 <xsd:all>
 <xsd:complexType>
 …

 <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”>

 Tipos Primitivos:
 string
 boolean
 decimal
 float
 double
 dateTime
 date
 time
 …

 Tipos Derivados:
 integer (decimal)
 long (integer)
 normalizedString (string)
 token (normalizedString)
 Name (token)
 ID (Name)
 IDREF (Name)
 ENTITY (Name)
 …

<xsd:element name="Cliente">
<xsd:complexType>
<xsd:sequence>
<xsd:element name="FechaNac"
type="xsd:date" />
<xsd:element name="Direccion"
type="xsd:string" />
</xsd:sequence>
</xsd:complexType>
</xsd:element>

<xsd:complexType name="AddressType">
<xsd:sequence>
<xsd:element name="Line1"
type="xsd:string"/>
<xsd:element name="Line2"
type="xsd:string"/>
</xsd:sequence>
</xsd:complexType>

 Espacios de Nombres
 Definición de tipos para reutilización
 Estructurar los esquemas
 Equivalente a los paquetes Java
 Espacios de Nombres W3C:
 xmlns
 http://www.w3.org/2001/XMLSchema
 http://www.w3.org/2001/XMLSchema-instance

 <xsd:schema
targetNamespace=“espacio”
elementFormDefault=
“qualified|unqualified”
xmlns:xsd=“http://www.w3.org/...”
xmlns:xxx=“espacio xxx”>
 <xsd:import
schemaLocation=“fichero.xsd”
namespace=“espacio xxx” />

<xs:schema xmlns:xs="http://www.w3.org/2001/XMLSchema"
xmlns:cmn="CommonTypes" elementFormDefault="qualified"
targetNamespace="CustomerTypes" >
<xs:import namespace="CommonTypes"
schemaLocation="CommonTypes.xsd" />
<xs:complexType name="CustomerType">
<xs:sequence>
<xs:element name="Name" type="xs:string" />
< xs:element name="DeliveryAddress"
type="cmn:AddressType" />
< xs:element name="BillingAddress"
type="cmn:AddressType" />
</xs:sequence>
</xs:complexType>
</xs:schema>

 Formato cualificado
 Exige utilizar el espacio de nombres en
todos los nodos
 Formato no cualificado
 Sólo exige namespace para el nodo raíz
 Y para los elementos definidos en el
mismo xsd del nodo raíz
 El resto no utiliza namespace

Veamos unos Ejemplos

5. Estilos en XML
 XSL (eXtensible Stylesheet Language)
 Familia de lenguajes basados en el estándar
XML
 Describir cómo la información de un
documento
 debe ser transformada
 o formateada
 Para su presentación en un medio
<xsl:stylesheet version="1.0" xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform">

5. Estilos en XML
 XSL (eXtensible Stylesheet
Language)
 <xsl:template match=“XPath” >
 <xsl:for-each select=“XPath” >
 <xsl:if test=“condición” >
 <xsl:value-of select=“nodo” />
 <xsl:output method=“text/xml/html”
indent=“yes/no”>

5. Estilos en XML
 XPath
 Lenguaje de consulta sobre XML
 Formato UNIX con filtrado
Expresión Descripción
nodo Selecciona todos los hijos del nodo indicado
/ Selecciona el nodo raíz
// Selecciona todos los nodos a partir del actual
. Selecciona el nodo actual
.. Selecciona el nodo padre del actual
@ Selecciona atributos
* Wildcard

5. Estilos en XML
 Predicados en XPath
 [nodo='valor']
 [@atributo]
 = != < >
Función Descripción
last() Selecciona el último elemento hijo
first() Selecciona el primer elemento hijo
position() Permite filtrar por posición del nodo
comment() Selecciona un nodo comentario
text() Selecciona texto dentro de un nodo
processing-
instruction()
Selecciona una instrucción CDATA

5. Estilos en XML
Veamos unos Ejemplos

6. Transformación de documentos
 XSLT (XSL Transformations)
 Parte más importante de XSL
 Desarrollado por el W3C
 Transforma un documento XML en otro
 Añadir y eliminar elementos y atributos
 Redistribuir y ordenar elementos
 Emplea XPath para navegar por el documento
<xsl:transform version="1.0" xmlns:xsl=
"http://www.w3.org/1999/XSL/Transform">

 El modelo de procesamiento incluye:
 Uno o más documentos origen XML
 Uno o más módulos de estilo XSLT
 Un procesador de plantillas XSLT
 Uno o más documentos resultado

 <xsl:variable match=“XPath” >
 <xsl:element name=“nombre nodo”
use-attribute-sets=“atts” >
 <xsl:attribute name=“nombre att”>
 <xsl:copy use-attribute-sets=“atts” >
 <xsl:copy-of select=“nodo” />
 <xsl:choose><xsl:when test=“…”>
 <xsl:otherwise>

45
<xsl:stylesheet version="1.0" xmlns:xsl =
"http://www.w3.org/1999/XSL/Transform" >
<xsl:output method="xml" indent="yes"/>
<xsl:template match="/persons">
<root>
<xsl:apply-templates select="person"/>
</root>
</xsl:template>
<xsl:template match="person">
<name username="{@username}">
<xsl:value-of select="name" />
</name>
</xsl:template>
</xsl:stylesheet>

46
 XML Entrada
<persons>
<person username="JS1">
<name>John</name>
<family-name>Smith</family-name>
</person>
<person username="MI1">
<name>Morka</name>
<family-name>Ismincius</family-name>
</person>
</persons>
 XML Salida
<root>
<name username="JS1">John</name>
<name username="MI1">Morka</name>
</root>

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 2. Tratamiento de XML en Java 48
1. Introducción a JAX
 Java API for XML
 Librería de Sun Microsystems
compuesta de varios APIs para el
tratamiento de XML
 JAXP para procesamiento
 JAXM para mensajería
 JAXR para trabajo con registros
 JAX-RPC para invocación remota
 JAXB para binding

1. Introducción a JAX
 Estos APIs se implementan en
varios paquetes de software
 Xerces (SAX y DOM)
 Crimson XML (SAX y DOM)
 Xalan (XSLT y XPath)
 Sparta XML (SAX, DOM y XPath)

2. Procesamiento de XML
 XML implica datos portables
 Java implica código portable
 J2EE une estas ventajas
 JAXP para procesar XML desde Java
 SAX para parsear XML
 DOM para construir árboles en memoria
 XSLT para presentar y transformar datos
 Soporte para espacios de nombres
 Trabajo con múltiples documentos XML

 JAXP (Java API for XML Processing)
 Permite validar y parsear XML
 Provee 3 interfaces básicas de creación
y procesamiento de XML
 DOM
 SAX
 StAX
 Interfaz para XSTL
 Paquete:
javax.xml.parsers

 JAXP (Java API for XML Processing)
 javax.xml.parsers.DocumentBuilderFactory
 Clase de entrada para procesar XML con DOM
 javax.xml.parsers.DocumentBuilder
 Se construye a través del factory
 Método newDocumentBuilder()
 Contiene métodos de parse para XML
 javax.xml.parsers.SAXParserFactory
 Clase de entrada para procesar XML con SAX
 javax.xml.parsers.SAXParser
 Se construye a través del factory
 Método newSAXParser()
 Contiene métodos de parse para XML

 DOM (Document Object Model)
 Modelo independiente de lenguaje para
describir documentos HTML y XML
 Propuesto por el W3C para acabar con la
guerra de los navegadores
 Adoptado por todos los desarrolladores de
navegadores “excepto” Microsoft
 Incluye un API para consultar y manipular
documentos
 Paquete:
org.w3c.dom

 Simplifica el mapeo de la estructura de XML
 Más práctico con documentos pequeños
(<20MB)
 Muchos o todos los documentos se deben
parsear
 Permite transformar documentos de manera
sencilla

 Fácil acceder repetidamente al
documento o de modo no secuencial
 Define cómo se relacionan objetos y
elementos de un documento en el
navegador
 Permite cualquier lenguaje de
desarrollo de páginas Web
 JavaScript
 window, document, body, div, p, …

 Jerarquía de Objetos DOM

 DOM Nivel 1
 Publicado en 1998 por la W3C
 Provee un modelo completo para HTML y XML
 DOM Nivel 2
 Publicado a finales de 2000
 Añade funciones como getElementById()
 Añade soporte para espacios de nombres
 DOM Nivel 3
 Publicado en 2004
 Añade soporte para XPath y eventos de teclado
 Añade interfaz de serialización de XML

 DOM Parser
DocumentBuilderFactory factory =
DocumentBuilderFactory.newInstance();
DocumentBuilder builder =
factory.newDocumentBuilder();
Document document = builder.parse(new
File(“text.xml”));
Element root =
document.getDocumentElement();

 DOM Parser
 getDocumentElement()
 getElementsByTagName(String)
 getChildNodes():NodeList
 getParentNode()
 getFirstChild()
 getLastChild()
 getPreviousSibling()
 getAttributes():NamedNodeMap
 getNodeName()
 getNodeValue()
 …

 DOM Parser
 appendChild(Node)
 cloneNode()
 insertBefore(Node, Node)
 removeChild(Node)
 replaceChild(Node, Node)
 setNodeValue()
 createCDATASection()
 importNode(Node, bool)
 …

 DOM Scripting
 Acceso programático a DOM
 JavaScript
 Originado a partir de DHTML
 Utiliza JavaScript, CSS y HTML
 Suele ser específico para cada navegador
 Suele requerir duplicación de código
 Solo disponible en Web
 Utiliza etiquetas no estandarizadas

 DOM Scripting
 Utiliza un lenguaje de scripting y
etiquetas válidas (HTML, XHTML,
XML,...)
 Puede utilizarse con cualquier tipo de
documento válido
 Puede utilizarse con cualquier lenguaje
de programación o scripting
 Es independiente del navegador

 JavaScript
 Desarrollado en 1996 para Netscape
 Lenguaje DOM Nivel 0
 Solo admite elementos HTML concretos
 Ampliado en 1997
 Intermediate DOM
 Soporte para CSS
 Soporte para capas (layers)
 Abandonado por Netscape

Veamos unos Ejemplos de DOM

 JDOM (Java DOM)
 DOM para XML diseñado para Java
 Integrado con DOM y SAX
 Soporta XPath y XSLT
 Paquetes
org.jdom
org.jdom.adapters
org.jdom.filter
org.jdom.input
org.jdom.output
org.jdom.transform
org.jdom.xpath

 Clases JDOM
 Document
 Element
 Attribute
 CDATA
 Namespace
 Text
 XercesDOMAdapter
 XPath
 XmlTransformer
 …

 JDOM (Java DOM)
Element root = new Element("shop");
root.setAttribute("name", "shop for geeks");
root.setAttribute("location", "Tokyo, Japan");
Element item1 = new Element("computer");
item1.setAttribute("name", "iBook");
item1.setAttribute("price", "1200$");
root.addContent(item1);
XMLOutputter outputter = new XMLOutputter();
outputter.output(new Document(root),
new FileOutputStream ("foo2.xml"));

Veamos unos Ejemplos de JDOM

 SAX (Simple API for XML)
 API de XML basada en eventos
 Los eventos de parseo se reportan
directamente a la aplicación
 Métodos de respuesta permiten
manejar los componentes del
documento
 Paquete:
org.xml.sax

 Permite buscar etiquetas concretas de
manera rápida
 Trabaja bien con documentos grandes
 Es más rápido que DOM
 Pero no soporta la transformación de
documentos tan bien como DOM

SAXParserFactory factory =
SAXParserFactory.newInstance();
SAXParser saxParser = factory.newSAXParser();
DefaultHandler handler = new XMLParser();
saxParser.parse( new File(argv[0]), handler );
 XMLParser debe extender
org.xml.sax.helpers.DefaultHandler que define
métodos para responder a los eventos

 org.xml.sax.helpers.DefaultHandler
 startElement() throws SAXException
 String uri
 String localName
 String qualifiedName
 Attributes attributes
 endElement() throws SAXException
 String uri
 String localName
 String qualifiedName

 org.xml.sax.helpers.DefaultHandler
 characters()
 startDocument()
 endDocument()
 processingInstruction()
 error()
 warning()
 …

Veamos unos Ejemplos de SAX

3. XML Binding
 JAXB (Java Architecture for XML Binding)
 Entorno de binding en tiempo de ejecución
para aplicaciones cliente (GlassFish)
 Incluye capacidades de marshalling,
unmarshalling y validación
 Sun: “Proporciona una manera de procesar
contenido XML a través de objetos Java
enlazando su esquema XML con la
representación Java”
 Paquete Java:
javax.xml.binding

3. XML Binding
 ¿Qué es binding?
 Literalmente vincular/vinculación
 Vamos a vincular un esquema XML (DTD/XSD)
con objetos Java
 ¿Qué es marshaling?
 Transformar un objeto de memoria a un
formato adecuado para ser transmitido
 Serializar
 ¿Qué es unmarshaling?
 Operación inversa al marshaling
 Deserializar

3. XML Binding
 JAXB

3. XML Binding
 JAXB. Ventajas
 Simplifica el acceso a XML
 No requiere parser
 Permite acceso no secuencial a nodos
 Genera objetos Java directamente usables
 Uso eficiente de memoria (respecto a DOM)
 Flexible
 Permite varios orígenes de datos XML
 Permite marshaling a distintas salidas
 Permite acceso a datos sin deserializar
 Permite validar los datos contra un esquema
 Soporta binding personalizado

3. XML Binding
 Caso 1: Unmarshaling
 Acceder y mostrar información de un
documento XML (books.xml)
 En SAX hay que:
 Crear el parser SAX
 Crear un manejador de contenido
 Procesar los eventos de SAX
 En JAXB
 Vinculamos el esquema XML
 Deserializamos el documento en objetos Java
accesibles desde nuestro programa

3. XML Binding
 Caso 1: Unmarshaling
 Acceder y mostrar información de un
documento XML (books.xml)
 En SAX hay que:
 Crear el parser SAX
 Crear un manejador de contenido
 Procesar los eventos de SAX
 En JAXB
 Vinculamos el esquema XML
 Deserializamos el documento en objetos Java
accesibles desde nuestro programa
Collection
Books
Books
bookType
authorName
descriptionisbn name priceauthors

3. XML Binding
 Vincular el esquema XML
 Utilizaremos esquemas XSD
 Son más ricos que los DTD
 El proceso de binding implica generar
clases que representen el esquema
 Lo realiza un “compilador de binding”
xjc.bat –p <paquete> -d <directorio>
 Genera un conjunto de interfaces Java
 Y unas implementaciones básicas en el
directorio /impl

3. XML Binding
 Vincular el esquema XML
 Utilizaremos esquemas XSD
 Son más ricos que los DTD
 El proceso de binding implica generar
clases que representen el esquema
 Lo realiza un “compilador de binding”
xjc.bat –p <paquete> -d <directorio>
 Genera un conjunto de interfaces Java
 Y unas implementaciones básicas en el
directorio /impl
xjc.bat -p test.jaxb books.xsd -d directoriojavac test/jaxb/*.java test/jaxb/impl/*.java
CollectionType.java CollectionTypeImpl.java
Collection.java CollectionImpl.java
BookType.java BookTypeImpl.java
ObjectFactory.java ObjectFactoryImpl.java

3. XML Binding
 Deserializar el documento
 El proceso de unmarshaling implica crear un
árbol de objetos de contenido
 Que representen la estructura y el contenido
del documento
 De manera más eficiente que DOM
 Objeto javax.xml.bind.JAXBContext
 Indicarle los paquetes que contienen las
interfaces generadas
 Objeto javax.xml.bind.Unmarshaller
 Obtenido a partir del JAXBContext

3. XML Binding
 El proceso de unmarshaling implica crear un
árbol de objetos de contenido
 Que representen la estructura y el contenido
del documento
 De manera más eficiente que DOM
 Objeto javax.xml.bind.JAXBContext
 Indicarle los paquetes que contienen las
interfaces generadas
 Objeto javax.xml.bind.Unmarshaller
 Obtenido a partir del JAXBContext
jc = JAXBContext.newInstance("test.jaxb");
unmarshaller = jc.createUnmarshaller();

3. XML Binding
 El objeto javax.xml.bind.Unmarshaller contiene
un método unmarshal() al que hay que indicar
el documento XML a deserializar
 Devuelve test.jaxb.Collection
 Los getter de las interfaces permiten acceder
al contenido
 También se puede modificar ese contenido a
través de los setter
 Existen tanto para elementos como para
atributos

3. XML Binding
 El objeto javax.xml.bind.Unmarshaller contiene
un método unmarshal() al que hay que indicar
el documento XML a deserializar
 Devuelve test.jaxb.Collection
 Los getter de las interfaces permiten acceder
al contenido
 También se puede modificar ese contenido a
través de los setter
 Existen tanto para elementos como para
atributos
Collection collection = (Collection)
unmarshaller.unmarshal(
new File( "books.xml"));
CollectionType.BooksType booksType =
collection.getBooks();
List bookList = booksType.getBook();

3. XML Binding
 Validar los datos
 JAXB permite validar los datos de un
documento contra su esquema XSD
durante la operación de unmarshaling
 Si el documento no es conforme al
esquema se produce un error
 La ejecución puede pararse o continuar
a pesar de estos errores
unmarshaller.setValidating(true);

3. XML Binding
 Caso 2: Marshaling
 Para crear la estructura de árbol en memoria
con DOM hay que:
 Crear un objeto Document
 Añadirle los nodos hijo necesarios
 Añadirle los atributos a los nodos
 DOM exige conocer y entender la estructura
del documento XML
 JAXB permite acceder a objetos de contenido
obtenidos por unmarshaling
 Pero no obliga a navegar por un árbol

3. XML Binding
 Caso 2: Marshaling
 Hay que vincular el esquema del mismo
modo que en el ejemplo anterior
 El esquema representará el documento
a construir
 Se debe crear un “árbol de contenidos”
 Este árbol es el que se va a serializar
hacia el documento XML

3. XML Binding
 Crear un árbol de contenido
 Objetos que se van a volcar al XML
 Clase ObjectFactory generada tras el
binding del esquema
 Contiene los métodos necesarios para
crear los objetos del árbol
 Métodos setter de cada objeto para añadir
información al árbol

3. XML Binding
 Crear un árbol de contenido
 Objetos que se van a volcar al XML
 Clase ObjectFactory generada tras el
binding del esquema
 Contiene los métodos necesarios para
crear los objetos del árbol
 Métodos setter de cada objeto para añadir
información al árbol
ObjectFactory objFactory = new ObjectFactory();
Collection collection = (Collection)
objFactory.createCollection();
Collection.BooksType booksType =
objFactory. createCollectionTypeBooksType();
BookType book = objFactory.createBookType();

3. XML Binding
 Serializar el árbol de contenido
 Crear un objeto de contexto
JAXBContext indicando el namespace
 Paquete que contiene las clases
 Crear un Marshaller a partir del objeto
de contexto
 Método setProperty() para indicar
propiedades
 Método marshal() vuelca el árbol de
contenidos a fichero XML

3. XML Binding
 Serializar el árbol de contenido
 Crear un objeto de contexto
JAXBContext indicando el namespace
 Paquete que contiene las clases
 Crear un Marshaller a partir del objeto
de contexto
 Método setProperty() para indicar
propiedades
 Método marshal() vuelca el árbol de
contenidos a fichero XML
jc = JAXBContext.newInstance("test.jaxb");
Marshaller marshaller = jc.createMarshaller();
marshaller.setProperty(
Marshaller.JAXB_FORMATTED_OUTPUT,
new Boolean(true));
marshaller.marshal(collection,
new FileOutputStream("fichero.xml"));

3. XML Binding
 Validar los datos
 La validación no forma parte del
proceso de marshaling
 Clase javax.xml.bind.Validator
 creada a partir del contexto
 Permite validar el árbol de contenido
 No es necesario que el árbol sea válido
para realizar el marshaling
Validator v = jaxbContext.createValidator();
v.validate(collection);

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 3. Fundamentos de Web Services 96
1. Introducción a los Servicios Web
 ¿Qué es un Servicio Web?
 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.”

 ¿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:
“Sistema diseñado para soportar interoperabilidad entre
máquinas sobre una red.”

 Simplificando más:
 Clase accesible a través de Internet
 Alojada en un Servidor Web
 Invocación remota de procesos
 Autocontenido, Autodescrito, Modular e
Independiente de Plataforma
 Estándares (XML, SOAP, RPC)

 Fundamentos:
 Intercambio de información
 Procesamiento
 Sin intervención del usuario
 Acelerando tiempos de respuesta
 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 o Sun ONE

 Comunicación Distribuida:
 Componentes ubicados en servidores
diferentes deben comunicarse.
referencia remota
<---------referencias locales---------->
RED TCP
Objeto
Cliente
Proxy
Objeto
Remoto
Referencia Remota

 Comunicación Distribuida:
 RMI
 Java en ambos extremos
 Stub (Proxy Cliente) y Skeleton (Servidor)
 Máquina rmiregistry sirve las referencias a objeto
remoto
 CORBA
 Genérico para objetos de distintos lenguajes
 Servidor de nombres (Naming Service) hace de
Skeleton
 IDL (Interface Definition Language)
 DCOM
 Microsoft
 COM+ balancea carga, gestiona transacciones y
admite llamadas asíncronas

 Infraestructura

 Arquitecturas involucradas:
 3 capas (CS):
 N capas (SOA):
ClienteClienteCliente
Lógica de
Negocio Servidor
Cliente
Cliente
Cliente
Seguridad
Servidor
Gestión
Validación

 Arquitectura Orientada a Servicios
 Utilizar servicios para implementar la
lógica de negocio
 Facilita la interacción entre sistemas
 Capas:
 Aplicaciones básicas (SD)
 Exposición de funcionalidad (WS)
 Integración de servicios
 Composición de procesos
 Entrega

 Terminología utilizada en SOA
 Servicio
 Funcionalidad publicada
 Orquestación
 Coordinación de servicios para implementar
una lógica determinada
 Sin estado
 Los servicios no dependen unos de otros y se
pueden orquestar de distintas maneras
 Proveedor
 Consumidor

 SOA
 Exige un cambio de mentalidad
 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

 SOA
 Diversos estándares de comunicación
 No es obligatorio pero se recomiendan
 XML
 HTTP
 SOAP
 WSDL
 UDDI

2. El protocolo SOAP
 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>
<myMethod>
<x xsi:type="xsd:int">5</x>
<y xsi:type="xsd:float">5.0</y>
</myMethod>
</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
 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, volcado de pila,…

3. Documentos WSDL
 Web Services Description Language
 Lenguaje de definició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
 Equivalente a IDL en CORBA

3. Documentos WSDL
 Define una o varias operaciones
 Incluyendo los mensajes que reciben
 Y los mensajes que devuelven
 Descritas de forma abstracta
 Concretadas en el endpoint
 Protocolo
 Formato de mensaje
 Dirección de Red

3. Documentos WSDL
<definitions>
<types/>
<message/> <part/> </message>
<portType><operation/></portType>
<binding/>
<service> <port/> </service>
</definitions>

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

3. Documentos WSDL
Veamos unos documentos WSDL

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
 Equivale al Naming Service en CORBA

4. Registros UDDI
 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

5. Tecnologías J2EE para WS
 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 connection =
factory.createConnection();
//Crear un mensaje SOAP de request
java.net.URL endpoint = new URL("http://...");
SOAPMessage response =
connection.call(request, endpoint);

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

 El API SAAJ. Attachments
//Crear y añadir
AttachmentPart attachment =
message.createAttachmentPart();
attachment.setContent("texto", "text/plain");
attachment.setContentId("id");
message.addAttachmentPart(attachment);
//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);
}
}

6. Creación de Servicios Web

7. Publicación de Servicios Web

8. Consumo de Servicios Web

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 4. Web Services con Apache AXIS 153
1. Introducción a 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

 Librerias que permiten ejecutar
Servicios Web
 Libreria WSDL.jar que general el
WSDL de los Servicios
 Parametros de entrada/salida y
metodos a invocar
 http://ws.apache.org/axis/
org.apache.axis.client
1. Introducción a Apache AXIS

2. Variables de Sistema
 Variables de AXIS
AXIS_HOME=c:axis
AXIS_LIB=%AXIS_HOME%lib
AXISCLASSPATH=%AXIS_LIB%axis.jar;
%AXIS_LIB%commons-discovery.jar;
%AXIS_LIB%commons-logging.jar;
%AXIS_LIB%jaxrpc.jar;%AXIS_LIB%saaj.jar
;%AXIS_LIB%log4j-1.2.8.jar;
%AXIS_LIB%wsdl4j-1.5.1.jar;
I:SunSDKlibantlibxercesImpl.jar;
I:SunSDKlibactivation.jar;
I:SunSDKlibmail.jar

3. Despliegue de Servicios
 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

 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

 Desplegar con SOAP Monitor
 java org.apache.axis.utils.SOAPMonitor

 Habilitar AdminServlet
 web.xml

4. Consumo de Servicios
 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 + "'");
}
}

5. Herramientas AXIS
 Varios subsistemas trabajan en
paralelo
 Manejadores de mensajes
 Servicios
 Proveedores
 Transporte
 WSDD
 WSDL
 …

 WSDL2Java
 Aplicación Java que genera clases a
partir de un documento WSDL
 Para cada <port> genera una clase
 Para cada portType una interfaz
 Para cada <binding> un stub Java
 Para cada <service> una interfaz de
servicio y una implementación
java org.apache.axis.wsdl.WSDL2Java “fichero-WSDL”

 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”

 TCP Monitor
 java org.apache.axis.utils.tcpmon
 [listenPort] puerto de escucha
 [targetHost] servidor
 [targetPort] puerto del servidor
 Permite
 Redirigir el servidor a otro puerto
 Monitorizar mensajes en ese puerto
 Mantener un log de request-response

 TCP Monitor

 SOAP Monitor
 -u [usuario]
 -w [password]
 -l [http://servidorAXIS]
 Permite monitorizar mensajes SOAP
 Applet java 1.3
 Compilar SOAPMonitorApplet.java
 Desplegar deploy-monitor.wsdd
 Aplicación incluida en Axis

 SOAP Monitor

6. WSDD
 Web Service Deployment Descriptor
<deployment xmlns="http://xml.apache.org/axis/wsdd/"
xmlns:java="http://xml.apache.org/axis/wsdd/providers/j
ava">
<service name="MyService" provider="java:RPC">
<parameter name="className"
value="samples.userguide.example3.MyService"/>
<parameter name="allowedMethods" value="*"/>
</service>
</deployment>

6. WSDD
 Colocar los ficheros en estos directorios no
garantizan el despliegue
 Se debe crear un WSDD y desplegarlo
 java org.apache.axis.client.AdminClient
 <deployment> es la raíz de un WSDD
 Contiene los servicios a registrar
 <service name=“servicio”
provider=“java:RCP ó java:MSG”>
 Y sus parámetros
 <parameter name=“parametro”
value=“valor”/>

6. WSDD
 Parámetros WSDD
 className: clase Java que se va a activar
 allowedMethods: métodos de la clase
permitidos
 allowedRoles: usuarios que pueden invocarlo
 wsdlServicePort:
 scope: Alcance de los objetos creados
(request, session, application)
 …
http://www.oio.de/axis-wsdd/

6. WSDD
 WSDD de repliegue
<undeployment name="test"
xmlns="http://xml.apache.org/axis/wsdd/">
<service name="servicio1"/>
<service name="servicio2"/>
</undeployment>

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 5. CAS SSO en Axis 180
1. Autenticación y Autorización
 Autenticación
 Asegurar que un usuario es quien dice ser
 Autorización
 Comprobar que un usuario autenticado tiene
permisos de acceso a un contenido
determinado

2. CAS
 Número CAS
 Identificación numérica única
 Ticket que se genera al iniciar sesión
 Permite autenticar al usuario
 Central Authentication Service
 Protocolo SSO para Web
 Permite acceso de usuarios a múltiples
aplicaciones con una única validación
 Permite validar al usuario sin requerir
password
 Paquetes CAS implementan el protocolo
 http://www.jasig.org/cas

2. CAS
 Proyecto originado en Yale (2001)
 Una capa (servidor CAS)
 SSO centralizado
 CAS 2.0 en 2002
 Añade posibilidad de n capas
 Añade posibilidad de proxys para SSO
 En 2005 pasa a ser proyecto de JA-SIG
 CAS 3.0 cambia la arquitectura
 Permite extender el servidor
 Permite crear plug-ins

2. CAS
 Solución Java que permite autenticar
usuarios en Web
 También permite integrarlo con SSO
 para validar en varios servidores
 Sistema muy sólido de autenticación
 Amplio rango de clientes y tecnologías
 http://www.ja-sig.org
 /wiki/display/CASUM/Technical+Overview

2. CAS
 Involucra
 Cliente (browser)
 Aplicación Web
 Servidor CAS
 El cliente accede a un Servidor que
requiere CAS
 El Servidor le redirige a CAS
 Se valida contra Kerberos, AD, …
 Usuario/Password
 Si se autentica recibe un ticket
 Similar a certificados digitales

2. CAS
 Acción de generar ticket
public final class GenerateServiceTicketAction extends
AbstractAction {
@NotNull private CentralAuthenticationService cas;
protected Event doExecute(final RequestContext
context) {
final Service service =
WebUtils.getService(context);
final String ticketGrantingTicket =
WebUtils.getTicketGrantingTicketId(context);

2. CAS
try {
final String serviceTicketId =
this.cas .grantServiceTicket(
ticketGrantingTicket, service);
WebUtils.putServiceTicketInRequestScope(context,
serviceTicketId);
return success();
} catch (final TicketException e) {
if (isGatewayPresent(context)) {
return result("gateway");
}
}
return error();

2. SSO
 Single Sign-On
 Procedimiento de autenticación
 Permite al usuario acceder a varios
sistemas con una sola identificación
 “Log in once, access always”
 Emplea servidores de autenticación
centralizados
 Todas las aplicaciones deben tener
acceso

2. SSO
 5 tipos de SSO
 Enterprise single sign-on (E-SSO):
 legacy single sign-on
 autenticación primaria, a través de un login
 para sistemas que pueden deshabilitar la pantalla de
login
 Web single sign-on (Web-SSO):
 Web access management (Web-AM)
 aplicaciones y recursos Web
 un proxy redirige a los usuarios a un servidor de
autenticación
 utiliza cookies para almacenar usuarios y su estado
 Kerberos:
 los usuarios se registran en el servidor Kerberos
 reciben un "ticket“
 lo presentan para obtener acceso

2. SSO
 5 tipos de SSO
 Federation:
 nueva manera de autenticar
 también para aplicaciones Web
 protocolos basados en estándares
 identificar a los clientes sin necesidad de
autenticación redundante
 OpenID:
 SSO distribuido y descentralizado
 la identidad se compila en una URL
 cualquier aplicación o servidor puede
acceder para verificarla

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 6. Transacciones en Web Services 191
1. Transacciones Distribuidas
 Transacción (TX): secuencia de
operaciones agrupadas como una unidad
 El inicio y el final definen los puntos de
consistencia de la base de datos
 Si una acción de la transacción no se puede
ejecutar, entonces ninguna acción tendrá
efecto
 COMMIT y ROLLBACK
 Propiedades:
 Atomicidad
 Consistencia
 Aislamiento
 Durabilidad

 Transacción Distribuída (DTX): Abarca
dos o más servidores conocidos como
administradores de recursos
 Administrador de transacciones coordina
la transacción
 Solicita COMMIT a los implicados
 Invoca ROLLBACK si alguno falla
 Transacción en 2 fases (2PC)
 Preparación
 Confirmación

 Fase de Preparación
 El administrador recibe una petición de
transacción distribuida
 Comunica a los implicados que está
preparando un COMMIT global
 Los implicados comunican si han tenido éxito
o no en la preparación
 Fase de Confirmación
 Si todos los implicados han tenido éxito envía
COMMIT a todos
 COMMIT global si todos responden
 Si alguno falla o se consume un timeout
envía ROLLBACK a todos

 JTA (Java Transaction API)
 API Java para comunicación con
administradores de transacciones e
implicados
 Administrador de Recursos
 Servidor de Aplicaciones
 Aplicaciones Transaccionales
 XID: Identificador de una DTX
 XARESOURCE: Recurso implicado

 JTA (Java Transaction API)
Servidor de
Aplicaciones
Administrador
de Transacción
Administrador
de Recursos
Administrador
de Recursos
Administrador
de Recursos
CRM/ERP
TX App
Recurso

 Niveles de Aislamiento
 READ_UNCOMMITED
 Acceso libre a los recursos de la DTX
 Problema de los “dirty reads”
 READ_COMMITED
 Se exige COMMIT para guardar cambios
 Problema de las “lecturas no repetibles”
 REPETEABLE_READS
 Lecturas repetidas dan los mismos datos
 Problema de los “phantom reads”
 SERIALIZABLE
 Bloquea los resultados de una consulta

2. Transacciones con EJB
 EJB permite modelar el comportamiento
de una DTX
 Internamente implementa JTA
 Cada EJB comparte el mismo XID
 Propaga los COMMIT o ROLLBACK entre
los EJB relacionados
 ROLLBACK ante RuntimeException
 SessionContext permite administrar los
ROLLBACK
 getRollbackOnly() consulta al admin JTA
 setRollbackOnly() provoca un ROLLBACK

 Implementar un EJB de sesión sin estado
 Añadir los métodos a publicar en la interfaz
remota
 En JDev es el .java que creamos
 Implementarlos en el EJB bean
 Se puede crear un Servicio Web que publique el
EJB
@Resource SessionContext ctx;
@Resource TransactionAttribute ta;
@Resource TransactionManagement tm;

 Propagación de la transacción
 Punto clave del comportamiento
 Transmitir los COMMIT y ROLLBACK
 Indicar si varios EJB comparten XID
 Tipos:
 PROPAGATION_REQUIRED
 PROPAGATION_REQUIRES_NEW
 PROPAGATION_MANDATORY
 PROPAGATION_SUPPORTS
 PROPAGATION_NEVER
 PROPAGATION_NOT_SUPPORTED

 PROPAGATION_REQUIRED
 Mantiene el XID de transacción o crea uno nuevo
si no existe
 PROPAGATION_REQUIRES_NEW
 Crea siempre un nuevo XID
EJB1
EJB2
EJB3
EJB4
EJB5
T1
T1
T1
-
T2
T3

Veamos un ejemplo

3. Transacciones con Spring
 Spring permite definir
 el comportamiento
 el nivel de aislamiento
 Creando Spring beans parametrizados
 org.springframework.jdbc.datasource.Da
taSourceTransactionManager
 org.springframework.transaction.interce
ptor.TransactionAspectSupport

 Crear una interfaz a publicar
 Implementarla
 Crear un bean de Spring de
configuración
 Añadir un bean que instancie la clase de
implementación
 Crear un bean proxy que conecte con la
instancia
 Este bean admite configuración de
aislamiento y propagación para cada método
 Su target debe ser mi instancia
 Requiere un gestor de transacciones

 Crear el bean gestor de transacciones
 Cuyo dataSource apunta a un origen de datos
 Crear un bean origen de datos
 Que apunte a un origen
 Que apunte a un JNDI
 …
 JNDI debe apuntar al recurso en el
web.xml
 java:comp/env/[nombre del recurso en
web.xml]

Veamos un ejemplo

Contenidos
consumo desde Java
VII. Caso Práctico

Marzo 2009 7. Caso Práctico 207
VII.Caso Práctico
1. Consumir un Servicio Web de
http://www.webservicelist.com/
2. Crear un Servicio Web que
consuma el buscador de Ecocoma
y nos devuelva SOLO resultados
con contenido embebido

Muchas Gracias
Óliver Centeno Álvarez

Web services y java

Más contenido relacionado

La actualidad más candente

Destacado

Similar a Web services y java

Más de Oliver Centeno

Web services y java