Investigación Servicios Web

INSTITUTO TECNOLOGICO
SUPERIOR DE ALVARADO
Campus Medelln
INGENIERA EN
SISTEMAS COMPUTACIONALES
Materia:
Programacin Web
Semestre - Grupo - Sistema:
6 Semestre - Grupo A Escolarizado.
Producto Acadmico:
Investigacin U6
Presenta:
Carrasco Sosa Cinthia Janette, 116Z1150
Mancilla Orea ngel Daniel, 116Z0561
Jcome Amaya Carlos Alejandro, 116Z06542
Docente:
Ing. Rogelio Reyna Vargas
MEDELLIN DE BRAVO, VER. FEB. JUN. 2014
ndice
Objetivo..3
Introduccin...4
Hipertexto...5
W3c...14
Ibm17
Conclusin...56
Bibliografa...56
Objetivo
Se espera que con esta investigacin se tenga un mejor entendimiento del tema, que
en este caso es sobre los servicios web.
Introduccin
Los servicios que hoy ofrece Internet no slo se han multiplicado, sino que han
evolucionado hacia nuevas y mejoradas funciones y han ganado en facilidad de uso
y manejo. A este cambio han contribuido no slo la velocidad de transferencia de los
bits que permiten los modems y routers actuales y la mayor eficiencia y capacidad de
las lneas de telecomunicaciones con un gran ancho de banda, sino tambin,
mejoras en el software y las aplicaciones (bases de datos integradas en la
Web, motores de bsqueda, agentes inteligentes, etc.) y en el hardware (mayor
capacidad de almacenamiento y memoria, incremento exponencial de la velocidad de
los procesadores, capacidad de tratar todo tipo de datos no slo los textuales, sino
tambin los datos multimedia, etc.).
Servicios Web
Existen numerosas definiciones de Servicios Web y esto demuestra, en parte, la gran
complejidad de los servicios que se agrupan bajo este trmino y las implicaciones
asociadas a ellos. Hasta ahora la definicin ms general y convincente es decir que
los Servicios Web son el conjunto de aplicaciones o tecnologas con capacidad para
interoperar en la Web. Estas tecnologas intercambian datos entre ellas con el fin de
ofrecer unos servicios.
La World Wide Web no es slo un espacio de informacin, tambin es un espacio

de interaccin. Utilizando la Web como plataforma, los usuarios, de forma remota,
pueden solicitar un servicio que algn proveedor ofrezca en la red. Pero para que
esta interaccin funcione, deben existir unos mecanismos de comunicacin
estndares entre diferentes aplicaciones. Estos mecanismos deben poder interactuar
entre s para presentar la informacin de forma dinmica al usuario. Se precisa,
pues, una arquitectura de referencia estndar que haga posible la interoperabilidad y
extensibilidad entre las distintas aplicaciones y que permita su combinacin para
realizar operaciones complejas.
Fuente: W3C Oficina Espaola. "Los Servicios Web en funcionamiento". Gua Breve
de Servicios Web. http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb
Con el fin de estandarizar los diferentes aspectos relacionados con los servicios web
o Web Services (WS), el W3C recoge todo lo referente a estos en: Web Services
Activity(http://www.w3.org/2002/ws/).
As pues, Web Services (WS) ofrece una un significado estndar para interoperar
entre diferentes aplicaciones de software corriendo en diferentes plataformas y/o
marcos de trabajo. El W3C pretende disear la arquitectura, definirla y crear el
ncleo de tecnologas que hagan posible los Servicios Web. Esta arquitectura se
basa en los siguientes componentes:
Disear un marco de mensajera:
Simple SOAP: Simple Object Access Protocol es un protocolo
simple para intercambiar informacin estructurada en un ambiente

descentralizado y distribuido. "Messaging Framework" define, usando
tecnologas XML, un marco extensible de mensajera que contiene una
construccin del mensaje que se pueda intercambiar con una variedad
de protocolos subyacentes. http://www.w3.org/TR/soap12-part1/
Web Services Addressing (WS-Addressing): Direccionamiento de
Servicios Web. La direccin de los servicios Web proporciona

mecanismos neutrales para transportar los servicios web y los
mensajes. Define un sistema de caractersticas abstractas y una
representacin de XML para referirse a servicios de la Web y para
facilitar la direccin final de los mensajes. Esta especificacin permite a
los sistemas de mensajera soportar la transmisin del mensaje a travs
de redes que incluyen el procesado de nodos tales como gestin final,
cortafuegos
pasarelas
mediante
una
forma
de
transporte
neutro. http://www.w3.org/TR/ws-addr-core/
SOAP Message Transmission Optimization (MTOM) Descripcin
de la Optimizacin de la Transmisin del Mensaje. Describe una

caracterstica abstracta y una puesta en prctica concreta para
optimizar el formato de la transmisin y/o de la va de los mensajes
SOAP. http://www.w3.org/TR/soap12-mtom/
Descripcin de los Servicios:
Web Services Description Language (WSDL): Lenguaje de
Descripcin de los Servicios Web. Se trata de un lenguaje para describir

Servicios Web. La especificacin define el lenguaje bsico que puede
usarse para describir servicios Web basados en un modelo abstracto de
lo que ofrece el servicio. Tambin define los criterios de conformidad de
los
documentos
en
lenguaje. http://www.w3.org/TR/wsdl20/
5
relacin
este
Web Services Choreography Description Language (WS-CDL):
Lenguaje de Descripcin de la Coreografa de los Servicios Web. Es un

lenguaje basado en XML que describe colaboraciones peer to peer de
los participantes definiendo, desde un punto de vista global, un
comportamiento observable comn y complementario; donde ordenado
el mensaje, intercambia el resultado de acuerdo a un objetivo de
negocios comn.http://www.w3.org/TR/ws-cdl-10/
Los servicios web que se basan en XML permiten que las aplicaciones compartan
informacin
que
independientemente
adems
de
cmo
invoquen
se
funciones
hayan
creado
de
otras
dichas
aplicaciones
aplicaciones
independientemente del sistemas operativo o plataforma en que se ejecuten y de los

dispositivos utilizados en el acceso. Los servicios Web XML, aunque sean
independientes entre s, pueden vincularse para realizar una tarea. Por ejemplo,
Google, utiliza un Servicio Web -Google Web APIs- basado en los estndares SOAP
y WSDL que permite programar en Java, Perl Visual Studio.NET y que sirve para
la recuperacin de informacin permitiendo utilizar este buscador en distintas
plataformas y Servicios Web.http://www.google.com/apis/ Por su parte, Amazon Web
Services ofrece una serie de de aplicaciones de referencia que permiten a los
desarrolladores acceso directo a la plataforma de tecnologa de Amazon y construir
aplicaciones propias. Una lista promenorizada de muchos de los servicios web
existentes en la actualidad los ofrece XMethod: http://www.xmethods.com
Adems, existen numerosos proyectos como Web Services and Semantic (WS2)
Project (http://www.w3.org/2004/WS2/) cuyo objetivo es promover los Servicios Web
y trabajar en la integracin de la semntica en la Web, o el proyecto Infrawebs
Europe http://www.infrawebs.org/ cuyo objetivo es desarrollar un marco para que los
desarrolladores de software y proveedores de servicios puedan generar y establecer
plataformas de desarrollo para aplicaciones de Servicios Web que sean abiertas,
extensibles y reconfigurables.
Como se ha afirmado anteriormente, los servicios web se componen de varias capas
entre las que destacan: servicios de transporte (constituidos por los protocolos del
nivel ms bajo, que codifican la informacin independientemente de su formato, y
que pueden ser comunes a otros servicios), de mensajera, de descripcin y

de descubrimiento.
En la capa inferior se encuentran los servicios de transporte que son los encargados
de establecer la conexin y el puerto utilizado. Lo ms comn es emplear
el protocolo de hipertexto HTTP, pero tambin se pueden usar otros protocolos
como SMTP (Simple Mail Transfer Protocol o Protocolo de Transmisin de Correo
Simple que es el protocolo que nos permite recibircorreos electrnicos), o el
protocolo FTP (File Transfer Protocol).
Por su parte, la funcin WSDL (Web Service Description Language) es decirle a una
aplicacin qu formato usar para comunicarse, especificando por medio de un
lenguaje estndar, tanto la direccin del servicio como la interfaz que se va a utilizar.
WSDL es un lenguaje basado en XML para describir servicios en la Web. Ofrece a
los proveedores de servicios, una formato bsico de descripcin de las peticiones de
servicios web sobre diferentes protocolos o codificaciones.
Existe un grupo de trabajo dentro del W3C, el Web Services Description Working
Group http://www.w3.org/2002/ws/desc/ que analiza y desarrolla el lenguaje WSDL.
WSDL se usa para describirqu puede hacer un servicio web, dnde reside, y cmo
invocarlo. WSDL define los servicios como colecciones de puntos finales de la red
o puertos. En WSDL la definicin abstracta de puntos finales y mensajes se separa
de su concreto despliegue en la red o formato de datos ligados. Esto permite
reutilizar las definiciones abstractas de los mensajes, que son descripciones
abstractas de los datos que estn siendo intercambiados, y los tipos de puerto, que
son
colecciones
abstractas
de
operaciones.
El
protocolo
concreto
las
especificaciones del formato de datos para un tipo particular de puerto constituye un

enlace reutilizabe. Un puerto se define por asociacin a una direccin de red con un
enlace reutilizable; una coleccin de puertos define un servicio. Y, as, un documento
WSDL usa los siguientes elementos en la definicin de servicios en red:
Tipos (Types): un contenedor para definiciones del tipo de datos que usan
algunos tipos de sistemas (tal como XSD).
Mensaje (Message): una definicin abstracta tipo del dato que est siendo
comunicado.
Operacin (Operation): una descripcin abstracta de una accin soportada

por el servicio.
Tipo de puerto (Port Type): un conjunto abstracto de operaciones soportadas

por uno o ms puntos finales.
Conexin (Binding): un protocolo concreto y una especificacin de formato

de datos para un tipo de puerto particular.
Puerto (Port): un punto final individual definido como una combinacin de una
conexiny una direccin de la red.
Servicio (Service): una coleccin de puntos finales relacionados.
Por ltimo, en la capa superior se encuentra UDDI (Universal Description, Discovery

and Integration), un protocolo que permite no slo describir servicios web, sino
tambin describir productos, compaas, transacciones, etc. UDDI es uno de los
principales edificios construidos para llevar a cabo los servicios Web. UDDI provee
un mecanismo para que los clientes encuentren de forma dinmica otros servicios
web creando una plataforma interoperable estndar que permite a las compaas
usar de forma rpida, fcil y dinmica los servicios Web. Usando la interfaz de UDDI,
pueden conectarse dinmicamente la empresas con los servicios proporcionados por
socios externos. Para ello es necesario registrarse en UDDI y los registros pueden
tener diversos propsitos y usarse en distintos contextos. Existen 2 tipos de clientes:
compaas que desean publicar un servicio (y su interfaz de uso) y clientes que
desean obtener cierta clase de servicios por medio de una conexin. UDDI se monta
sobre SOAP y asume que las consultas y las respuestas son objetos de UDDI
enviados como mensajes de SOAP. El W3C tambin est teniendo en consideracin
los desarrollos del protocolo UDDI. Se trata de un esfuerzo conjunto de la industria y
en el que intervienen proveedores de las principales plataformas y software, as
como operadores en el mercado y lderes de los negocios dentro del consorcio de los
estndares OASIS. El proyecto UDDI no es especfico de una industria, sino que
cualquier compaa de cualquier parte del mundo puede beneficiarse de esta
iniciativa. http://www.uddi.org/
As pues, la plataforma bsica de los Servicios Web es el lenguaje XML construido
sobre el protocolo de hipertexto HTTP y para el intercambio de esta informacin
estructurada en un entorno descentralizado y distribuido, se utiliza el protocolo SOAP

(Simple Object Access Protocol), pero en los Servicios Web tambin intervienen otros
mecanismos, lenguajes y tecnologas entre las que se encuentran el lenguaje WSDL,
el protocolo UDDI y otros lenguajes como WSFL, WSML, WSMO, WSMX, etc.
El lenguaje WSFL o Web Services Flow Language es un lenguaje XML para describir
la composicin de los servicios web como parte de una definicin del proceso de
negocio. Fue diseado por IBM como parte de un marco tecnolgico de servicios
web y para completar las especificaciones existentes. WSDL considera 2 tipos de
servicios web: el primer tipo especifica un proceso de negocio ejecutable conocido
como Modelo de flujo (flowModel) y el segundo tipo es un negocio en colaboracin
conocido como Modelo global (globalModel).
The layered Web services stack with UDDI. Fuente: Tom Bellwood. Understanding
UDDI.
http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/
Flow of UDDI messages between Client and Registry.Fuente: Tom Bellwood.

Understanding
UDDI.
http://www-128.ibm.com/developerworks/webservices/library/ws-featuddi/
Para describir los servicios web, el W3C recomienda utilizar el Web Service Modeling
Language (WSML) o Lenguaje de Modelado de Servicios Web que provee una
sintaxis formal y una semntica para el modelado de ontologas de servicios web
(Web Service Modeling Ontology -WSMO-). WSML est basado en diferentes lgicas
formales, llamadas Lgica de descripcin (Description Logics), Lgica de Primer
Orden (First-Order Logic) y Lgica de Programacin (Logic Programming), que se
usan para el modelado de Servicios de la Web Semntica. WSML consta de un
nmero de variantes basadas en estas diferentes lgicas formales llamadas WSMLCore, WSML-DL, WSML-Flight, WSML-Rule y WSML-Full. WSML-Core es el ncleo
el lenguaje y las otras variantes WSML ofrecen incrementos de expresividad en la
direccin de la Descripcin Lgica y la Lgica de Programacin. Por ltimo, ambos
paradigmas se unifican en WSML-Full, la variante ms expresiva de WSML.
WSML se especifica en trminos de una sintaxis normativa legible por seres
humanos. Pero adems de esta sintaxis legible por seres humanos, WSML tiene una
sintaxis XML y RDF para el intercambio sobre la Web y para la interoperabilidad con
aplicaciones basadas en RDF. Tambin es posible el mapeo entre ontologas WSML
y ontologas OWL para interoperar con ontologas OWL por medio de un subconjunto
10
semntico comn de OWL y WSML. Ms informacin al respecto, se puede obtener

en: http://www.wsmo.org/wsml/wsml-syntax,http://www.wsmo.org/wsml y http://www.w
3.org/Submission/WSML/.
Web Service Modeling Ontology (WSMO) u Ontologa de Modelado para Servicios
Web se basa en el Marco de Modelado de Servicios Web (WSMF) que separa los
elementos que se necesitan para describir servicios en ontologas, servicios Web,
objetivos y mediadores. WSML es el lenguaje usado para describir todos estos
elementos. El modelo de servicios describe el comportamiento del servicio en
trminos de procesos y de constructos de control. La base conecta procesos,
entradas y salidas en el modelo de proceso a un determinado protocolo de transporte
descrito
en
un
documento
de
WSDL
(http://www.wsmo.org y http://www.w3.org/Submission/WSMO/)
WSMO supone uno de los mayores esfuerzos con el propsito de especificar la
informacin semntica de los Servicios Web para hacer posible la automatizacin de
servicios, su composicin y ejecucin. WSMO recomienda el uso de vocabularios
ampliamente aceptados tales como metadatos Dublin Core y FOAF. En WSMO, un
objetivo especifica qu quiere el usuario y las descripcin del servicio Web definen la
capacidad que proporciona el servicio. Con WSMO tambin pueden expresarse las
propiedades no funcionales del servicio.(http://www.wsmo.org/TR/d2/v1.2/)
Tambin
se
ha
desarrollado WSMX
(Web
Service
Modelling
eXecution
environment) que es el entorno de ejecucin de modelado de servicios web y la

implementacin de referencia de WSMO. Se trata de la ejecucin de un entorno para
integracin de las aplicaciones de los compaas donde los servicios web estn
integrados por varias aplicaciones. El objetivo es incrementar la automatizacin de
los procesos en los negocios de una manera flexible mientras se ofrecen soluciones
de
integracin
escalable.
El
lenguaje
interno
de
WSMX
es
WSML.
(http://www.wsmx.org/)
Por ltimo, tambin existe el lenguaje SWSL (Semantic Web Services Language) un
lenguaje para describir la ontologa de los servicios de la Web Semntica (SWSO).
SWSL tiene 2 partes: SWSL-FOL, un lenguaje de lgica de primer orden, y
SWSLRules, un lenguaje basado en reglas. SWSL-FOL se usa principalmente para
11
la especificacin formal de la ontologa y para proeer interoperabilidad con otros

modelos de procesos basados en la lgica de primer orden y otras ontologas de
servicios. Por el contrario, SESL-Rules est diseado para ser un lenguaje actual
para la especificacin de servicios. (http://www.w3.org/Submission/SWSF-SWSL/)
Otros proyectos destacables en el campo de la semntica de los servicios web son:
Semantic Web Enabled Web Services (SWWS): es un proyecto de la

UE. http://swws.semanticweb.org/
Ontogrid: es un proyecto que coordina la Universidad Politcnica de

Madrid. http://www.ontogrid.net
Ajax
MAssive
Storage
Systems
(AMASS): http://codinginparadise.org/projects/storage/README.html
Un nuevo estudio de la industria, Semantic Wave 2006, predice que el mercado de la
tecnologa semntica rondar los "50 billones de dlares USA" hacia 2010, con los
consiguientes impactos sobre las industrias de las tecnologas de la informacin y la
comunicacin. Pero, sin duda, tambin tendrn su impacto econmico sobre los
usuarios de la red. Los servicios de la Web Semntica permiten que las aplicaciones
ya no estn alojadas en los ordenadores clientes (como hasta ahora ocurra con las
aplicaciones
que
se
descargaban,
ejecutaban
instalaban
en
el ordenador del usuario, ya fuera mediante programas originales o copias piratas),

sino que permanecern en los servidores y sern ofrecidas por un proveedor a modo
de servicio web al que se deber acceder cada vez que se quiera hacer uso del
servicio. Esto es, con la puesta en marcha de los servicios web se podr cobrar por
cada acceso o uso individual del servicio web correspondiente. Una filosofa de signo
bien contrario a la que, en paralelo, se est desarrollando mediante la llamada Web
social y colaborativa o Web 2.0
Qu son los Servicios Web?
Existen mltiples definiciones sobre lo que son los Servicios Web, lo que muestra su
complejidad a la hora de dar una adecuada definicin que englobe todo lo que son e
implican. Una posible sera hablar de ellos como un conjunto de aplicaciones o de
12
tecnologas con capacidad para interpelar en la Web. Estas aplicaciones o

tecnologas intercambian datos entre s con el objetivo de ofrecer unos servicios. Los
proveedores ofrecen sus servicios como procedimientos remotos y los usuarios
solicitan un servicio llamando a estos procedimientos a travs de la Web.
Para qu sirven?
Estos servicios proporcionan mecanismos de comunicacin estndares entre
diferentes aplicaciones, que interactan entre s para presentar informacin dinmica
al usuario. Para proporcionar interoperabilidad y extensibilidad entre estas
aplicaciones, y que al mismo tiempo sea posible su combinacin para realizar
operaciones complejas, es necesaria una arquitectura de referencia estndar.
Cmo funcionan?
El siguiente grfico muestra cmo interacta un conjunto de Servicios Web:
Un usuario a travs de una aplicacin, solicita informacin sobre un viaje que desea
realizar haciendo una peticin a una agencia de viajes que ofrece sus servicios a
travs de Internet. La agencia de viajes ofrecer a su cliente (usuario) la informacin
requerida. Para proporcionar al cliente la informacin que necesita, esta agencia de
viajes solicita a su vez informacin a otros recursos (otros Servicios Web) en relacin
con el hotel y la compaa area. La agencia de viajes obtendr informacin de estos
recursos, lo que la convierte a su vez en cliente de esos otros Servicios Web que le
van a proporcionar la informacin solicitada sobre el hotel y la lnea area. Por
ltimo, el usuario realizar el pago del viaje a travs de la agencia de viajes que
servir de intermediario entre el usuario y el servicio Web que gestionar el pago.
En todo este proceso intervienen una serie de tecnologas que hacen posible esta
circulacin de informacin. Por un lado, estara SOAP (Protocolo Simple de Acceso a
Objetos). Se trata de un protocolo basado en XML, que permite la interaccin entre
varios dispositivos y que tiene la capacidad de transmitir informacin compleja. Los
datos pueden ser transmitidos a travs de HTTP , SMTP , etc. SOAP especifica el
formato de los mensajes. El mensaje SOAP est compuesto por un envelope (sobre),
cuya estructura est formada por los siguientes elementos:
13
header (cabecera) y body (cuerpo).
Para optimizar el rendimiento de las aplicaciones basadas en Servicios Web, se han

desarrollado tecnologas complementarias a SOAP, que agilizan el envo de los
mensajes (MTOM) y los recursos que se transmiten en esos mensajes (SOAPRRSHB).
Por otro lado, WSDL (Lenguaje de Descripcin de Servicios Web), permite que un
servicio y un cliente establezcan un acuerdo en lo que se refiere a los detalles de
transporte de mensajes y su contenido, a travs de un documento procesable por
dispositivos. WSDL representa una especie de contrato entre el proveedor y el que
solicita. WSDL especifica la sintaxis y los mecanismos de intercambio de mensajes.
Durante la evolucin de las necesidades de las aplicaciones basadas en Servicios
Web de las grandes organizaciones, se han desarrollado mecanismos que permiten
enriquecer las descripciones de las operaciones que realizan sus servicios mediante
anotaciones semnticas y con directivas que definen el comportamiento. Esto
permitira encontrar los Servicios Web que mejor se adapten a los objetivos
deseados. Adems, ante la complejidad de los procesos de las grandes aplicaciones
empresariales, existe una tecnologa que permite una definicin de estos procesos
mediante la composicin de varios Servicios Web individuales, lo que se conoce
como coreografa.
Ejemplos
A continuacin se muestra el cdigo que se utilizara para solicitar un viaje:
14
<?xmlversion='1.0' ?>
<env:Envelopexmlns:env="http://www.w3.org/2003/05/soap-envelope">
<env:Header>
<m:reservaxmlns:m="http://empresaviajes.ejemplo.org/reserva"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<m:referencia>
uuid:093a2da1-q345-739r-ba5d-pqff98fe8j7d
</m:referencia>
<m:fechaYHora>2001-11-29T13:20:00.000-05:00</m:fechaYHora>
</m:reserva>
<n:pasajeroxmlns:n="http://miempresa.ejemplo.com/empleados"
env:role="http://www.w3.org/2003/05/soap-envelope/role/next"
env:mustUnderstand="true">
<n:nombre>Pepe Ejemplo</n:nombre>
</n:pasajero>
</env:Header>
<env:Body>
<p:itinerario
xmlns:p="http://empresaviajes.ejemplo.org/reserva/viaje">
<p:ida>
<p:salida>Nueva York</p:salida>
<p:llegada>Los Angeles</p:llegada>
<p:fechaSalida>2001-12-14</p:fechasalida>
<p:horaSalida>ltima hora de la tarde</p:horaSalida>
<p:preferenciaAsiento>pasillo</p:preferenciaAsiento>
</p:ida>
<p:vuelta>
<p:salida>Los Angeles</p:salida>
<p:llegada>Nueva York</p:llegada>
<p:fechaSalida>2001-12-20</p:fechaSalida>
15
<p:horaSalida>media-maana</p:horaSalida>
<p:preferenciaAsiento/>
</p:vuelta>
</p:itinerario>
<q:alojamiento
xmlns:q="http://empresaviajes.example.org/reserva/hoteles">
<q:preferencia>ninguna</q:preferencia>
</q:alojamiento>
</env:Body>
</env:Envelope>
Qu son los servicios web?
Comencemos con una idea general de lo que son los servicios web, y por qu son
importantes para el desarrollo de software.
Despus de todo cul es el problema?
Si usted no se hubiese cansado de escuchar todo tipo de informacin acerca de la
arquitectura orientada a los servicios (SOA) y los servicios web, no estara aqu,
entonces la pregunta es por qu tanto problema con esto? La respuesta es que se
trata de algo importante porque es un cambio de paradigma en la forma en que las
aplicaciones se comunican entre ellas. Las SOAs existen desde hace muchsimo
tiempo. Al principio se trataba mayormente de aplicaciones middleware en las que un
nico tipo de middleware posee, como mnimo, los dos extremos del cable. Por otra
parte, los servicios web, estn compuestos por un grupo de estndares que tratan de
posibilitar que diversos sistemas puedan comunicarse, sin la necesidad de un
middleware en particular, de lenguaje de programacin, o incluso de un sistema
operativo. Veamos la progresin desde donde comenzamos hasta llegar a ahora.
Aplicaciones tradicionales
Al principio, fueron las computadoras. Y fue algo bueno. Las computadoras hacan
tareas aparentemente milagrosas, automatizaban muchas cosas que la gente haca
16
a mano, desde clculos complejos, para pasar a las finanzas, y a muchas otras
tareas.
Pero las aplicaciones tradicionales son silos. La aplicacin de recursos humanos no
poda hablar con la de finanzas que, a su vez, no poda hablar con la aplicacin de
distribucin. Todas estas aplicaciones tenan su propio hogar, en sus propias
computadoras y, si bien eran tiles, no era una buena forma de compartir datos entre
ellas. Uno tena la opcin de escribir procesos batch (por lotes) para pasar los datos
de un sistema al otro, pero eso no era una sustitucin de la integracin en tiempo
real.
Computacin distribuida
El paso siguiente en nuestra cadena de evolucin es la computacin distribuida. La
computacin distribuida permita que diferentes aplicaciones se comunicaran entre
s, aun estando en computadoras distintas. Las tecnologas tipo CORBA, NTS, y
Enterprise Java Beans (EJB), proporcionaron un sistema que inclua un registro de
estilos, para que las aplicaciones pudiesen encontrar componentes con los que
queran interactuar, y luego llamarlos como si estuviesen ubicados en la mquina
local.
Estos sistemas era compatibles mediante middleware, o ms especficamente,
mediante middleware orientado a mensajes, que proporcionaba los dos requisitos.
Ahora se pueden crear las aplicaciones de manera tal que pueden acceder a los
recursos de otros sistemas, incluso si se encuentran en ubicaciones geogrficas
diferentes.
servicios web
El siguiente, y casi inevitable vnculo en esta cadena evolutiva son los servicios web.
Basados en XML, y, en la mayora de los casos, HTTP, los servicios web todava
significas muchas cosas para mucha gente, pero en este caso, hablaremos de los
servicios web como el intercambio entre sistemas de mensajes basados en SOAP.
Estos mensajes se componen de XML, que es un estndar abierto basado en texto,
accesible por cualquier persona desde cualquier aplicacin (cualquier aplicacin que
no est diseada para aceptarlo). Esto ampla el mundo de su aplicacin para que
17
cualquier persona pueda acceder a ella en su red. (Si eso le enciende alarmas de
seguridad, est bien, aprender cmo resolverlo en la parte cuatro de esta serie.)
El servicio web basado en SOAP implica el envo de un mensaje XML.
.Servicio web basado en SOAP
<SOAPenv:Envelope
xmlns:SOAPenv="http://schemas.xmlSOAP.org/SOAP/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAPenv:Body>
<req:getNumberOfArticles xmlns:req="http://daily-moon.com/CMS/">
<req:category>classifieds</req:category>
</req:getNumberOfArticles>
</SOAPenv:Body>
</SOAPenv:Envelope>
Estos mensajes van de un sistema a otro, por lo general, va HTTP. El sistema
receptor interpreta el mensaje, hace lo que se supone que debe hacer, y devuelve
una respuesta con la forma de otro mensaje SOAP.
Otros tipos de servicios web
Sera negligente si no mencionara que SOAP no es la nica forma de hacer servicios
web. Existen otras formas basadas en XML para enviar mensajes entre sistemas,
algunas de las cuales son adecuadas para un entorno de empresa, y otras que no lo
son. Por ejemplo, Amazon fue una de las primeras empresas basadas en Web en
ofrecer a su pblico el acceso de servicios web a su sistema. Amazon incluye un
servicio basado en SOAP, pero tambin proporciona un servicio basado en
Representational State Transfer (Transferencia de Estado Representacional, REST).
REST es un tipo de servicio web en el que el usuario simplemente accede a la URL,
y la respuesta es un autntico documento XML.
Respuesta REST
<currentArticles>
<category>classifieds</category>
18
<subcategory>forsale</subcategory>
<article id="888204">
<articleHeadline></articleHeadline>
<articleText>30 ft ladder, only used once. Willing to let
go for half it's worth. Has slight dent near the middle.
Harder than a human head. $150 OBO.</articleText>
</article>
<article id="888242">
<articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious inquires only.
555-3264 after 7 PM.</articleText>
</article>
</currentArticles>
Especificaciones bsicas de los servicios web
Por lo general, las especificaciones de los servicios web entran en dos categoras:
especificaciones bsicas de servicios web y especificaciones ampliadas de servicios
web. Las especificaciones bsicas son:
SOAP: El fundamento de todos los servicios web basados en SOAP, la especificacin
SOAP detalla el formato de los mensajes. Tambin detalla la forma en que las
aplicaciones deben tratar determinados aspectos del mensaje, tales como los
elementos del encabezado, lo que le permitir crear aplicaciones en las que un
mensaje pasa entre mltiples intermediarios antes de llegar a su destino final. Este
tutorial abarcar la especificacin SOAP.
WDSL: Web Services Description Language (Lenguaje de descripcin de los
servicios web) es una especificacin que detalla una forma estndar de describir un
servicio web basado en SOAP, que incluye la forma que debern tomar los
mensajes, y a dnde deben ser enviados. Tambin detalla la respuesta a ese
mensaje. Combinado con las herramientas adecuadas, WSDL le permite crear de
manera programtica, una llamada a un servicio web sin saber en realidad lo que
19
busca el servicio web; la aplicacin puede extraer esos detalles del archivo WSDL y
proporcionarle las interfaces programticas para que las use. Nos ocuparemos de
WSDL en la parte dos de esta serie.
UDDI: Universal Description, Discovery and Integration (Descripcin, Descubrimiento
e Integracin Universales) es un estndar que ha sufrido algunos cambios desde su
concepcin inicial. La idea era proporcionarle a las empresas una forma de registrar
sus servicios en un registro global, y consultar ese registro global para buscar
servicios que quisieran utilizar. Sin embargo, como es comprensible que muchas
empresas sean algo renuentes a abrir sus sistemas a desconocidos, no se
materializ este objetivo. No obstante, UDDI se afianz como un registro interno de
servicios e informacin de servicios; la parte tres de esta serie da detalles de su uso.
Especificaciones ampliadas de los servicios web
De las docenas de especificaciones WS-* que andan dando vueltas, varias se
destacan como particularmente tiles para la empresa. Y son:
WS-Security (Seguridad para servicios web): Esta especificacin maneja el
encriptado y las firmas digitales, lo que le permitir crear una aplicacin para que los
mensajes no pueden ser espiados, y donde es imposible el no rechazo. La parte
cuatro de esta serie se ocupa de WS-Security.
WS-Policy (Poltica de los servicios web): Esta especificacin es una ampliacin de
WS-Security, la que le permitir detallar de una manera ms especfica cmo y
quines pueden usar un servicio web. La parte cinco de esta serie se ocupa de WSPolicy.
WS-BPEL (Lenguaje de ejecucin de procesos de negocios para servicios web): un
servicio nico est bien, pero en la mayora de los casos no se trata de una
aplicacin. Como mnimo, la computacin a nivel de empresa necesita que usted
cree servicios mltiples dentro de un sistema general, y WS-BPEL le proporciona el
medio para especificar interacciones tales como el procesamiento bifurcado y
coincidente, necesario para crear esos sistemas. La parte siete de esta serie se
ocupa de WS-BPEL.
Configuracin
20
Ahora que ya comprende los principios bsicos que esto implica, comencemos con la
creacin efectiva de una aplicacin. El primer paso es instalar el software.
Configuracin de Apache Geronimo
El primer software que necesitar es un servidor de aplicaciones Web. Por qu
necesita un servidor de aplicaciones Web? Bueno, porque sin l, le va ser muy difcil
dar servicios web. Un servidor de aplicaciones Web atiende solicitudes, las traduce a
algo que el servicio pueda entender, y luego hace el proceso que sea necesario.
Para este proceso usted puede usar virtualmente cualquier servidor Web, pero en la
mayora de los casos instalar software que facilite ese proceso, y eso suele requerir
un servidor de aplicaciones determinado de algn tipo. Especficamente, este tutorial
supone que usted usar un servidor de aplicaciones Java. (En realidad, supone que
ser un servidor de aplicaciones J2EE.)
Cuando se trata de servidores J2EE, usted tiene muchas opciones y, en este caso,
usar Apache Geronimo. Geronimo es el servidor de aplicaciones de cdigo abierto
que forma la base de IBM WebSphere Application Server Community Edition.
Geronimo es pequeo, de fcil instalacin y de fcil manejo. Tambin funciona bien
con otros proyectos Apache, como por ejemplo Axis2, que usted instalar despus.
Descargue el software (ver Requisitos Previos) y extraiga los archivos en un
directorio de destino. Ver que los archivos extrados tienen su propio directorio, de
manera que slo tendr que descomprimirlos y moverlos a donde quiera. Se acepta
cualquier directorio, pero evite aquellos que contengan un espacio en su nombre,
como Archivos de Programa, Documents and Settings, o sus descendientes. Por
ejemplo, la instalacin de prueba para el tutorial usa e:\geronimo-1.0.
Listo. Ya instal Geronimo. Fcil no?
Para iniciar el servidor, abra una ventana de peticin de comandos y ejecute los
siguientes comandos:
cd <GERONIMO_HOME>
java -jar server.jar
Instalacin de Apache Axis2
Es completamente posible dar servicios web desde un servidor HTTP comn. Sin
21
embargo, no es aconsejable. Hay mucho que hacer para procesar mensajes SOAP, y
no hay motivos para que usted reinvente la rueda. Desde hace ya varios aos, el
proyecto Apache Axis2 simplifica esta tarea con la creacin de un entorno donde,
crear y procesar servicios web es muy fcil. El software incluye aplicaciones que lo
ayudarn a crear un servicio web a partir de un objeto comn, crear un objeto Java a
partir de un servicio web, y a procesar ambos. El grupo Apache design una nueva
versin de Axis, Axis2, que toma todo el trabajo hecho en Axis y lo eleva una
categora mediante el cambio de arquitectura para permitirle un mayor grado de
elasticidad. Esto es importante, porque continuamente aparecen especificaciones
para servicios web. La creacin de Axis2 permite una integracin ms sencilla con
proyectos tales como WSS4J, la implementacin de WS-Security de Apache. Como
ms adelante usaremos estos proyectos, instale Axis2 ahora (ver Requisitos previos
de informacin sobre la descarga).
Asegrese de descargar tanto la Binary Distribution (Distribucin binaria) como la
War Distribution (Distribucin War). La primera lo ayudar con la creacin de los
clientes, y la segunda con la creacin de los servicios.
Para instalar Axis2 en el servidor Web, copie el archivo axis2.war en el directorio de
implementacin de Geronimo. (Para que aparezca el directorio, debe asegurarse de
haber iniciado Geronimo por lo menos una vez.) Geronimo detecta su presencia
inmediatamente, por lo que no tendr que implementar nada.
Verificacin del eje a la instalacin
Para estar seguro de que todo se ha instalado correctamente, apunte su navegador a
http://localhost:8080/axis2/index.jsp y haga clic en Validate. (Validar).
Asegrese de que Axis est feliz antes de continuar con el resto del tutorial.
Instalacin de un servicio de muestra
La primera aplicacin que escribir es un cliente, por lo que necesitar un servicio al
que ste pueda acceder. Afortunadamente, la distribucin Axis2 trae varios. En
principio, instalar el servicio MyService de la siguiente forma:
Autentquese
en
la
aplicacin
Axis2
apuntando
su
navegador
http://localhost:8080/axis2/Login.jsp y despus inicie la sesin. El nombre de usuario
22
y la contrasea predeterminados son admin y Axis2, respectivamente.

Haga clic en Upload service>Browse (Cargar servicio>Navegar).
Navegue hacia el archivo MyService.aar. Podr encontrarlo en el directorio
samples/userguide de la distribucin estndar de Axis2. Haga clic en OK.
Haga clic en Upload (Cargar).
Deber ver una notificacin de que el servicio ha sido incorporado. Axis2 incluye, de
manera predeterminada, hot deployment, por lo que no tendr que hacer nada para
activarlo.
Ahora veamos lo que usted va a crear.
Entender SOAP
Ahora que ya instal el software, puede comenzar a ver el servicio web propiamente
dicho. Ahora que ya instal el software, puede comenzar a ver el servicio web
propiamente dicho. Como mencion en Other kinds of Web services (Otros tipos de
servicios web), usted dispone de diversos formatos para elegir. En esta serie, usar
SOAP.
Un breve comentario acerca de XML
Todos estos mensajes que van y vienen estn basados en Extensible Markup
Language (Lenguaje de marcado extensible) o XML. Si no est familiarizado con
XML, investigue un poco al respecto antes de entrar en profundidad en los temas de
los servicios web. Sin embargo, aqu aparecen los fundamentos que debe conocer
antes de seguir adelante con este tutorial.
XML es un lenguaje de marcado ampliable, lo que significa que proporciona una
forma de suministrar informacin adicional sobre el contenido. Esta informacin tiene
la forma de tags (etiquetas), las que denotan elements (elementos).
Archivo XML que muestra los fundamentos
<article articleId="88271" categoryId="classifieds" subcategoryId="forsale">
<articleHeadline>Fun, fun, fun</articleHeadline>
Driven by my daughter until I took it away. Serious
23
inquires only. 555-3264 after 7 PM.</articleText>

</article>
Observe un par de cosas acerca de este texto. Ante todo, es texto. Eso lo hace
legible por casi cualquiera, o por casi cualquier cosa. Segundo, las etiquetas estn
indicadas con > y <, con una etiqueta open (de apertura) que contiene un nombre, y
atributos posibles, como la ID del artculo, y una etiqueta de cierre con una barra (/).
Los elementos deben estar auto-contenidos y anidados correctamente. En otras
palabras, usted no podra tener un documento XML similar.
Muestra no vlida de un documento XML
<article articleId="88271" categoryId="classifieds" subcategoryId="forsale">
<articleHeadline>Fun, fun, fun
<articleText></articleHeadline>Vintage 1963 T-Bird.
Less than 300 miles. Driven by my daughter until I
took it away. Serious inquires only. 555-3264 after
7 PM.</articleText>
</article>
XML tambin proporciona una forma de separar el contenido en diferentes "espacios
de nombres, para que pueda ser tratado de otra manera por una aplicacin. Por
ejemplo, un mensaje SOAP puede parecerse al siguiente:
Ejemplo de mensaje SOAP
<?xml version='1.0' ?>
<env:Envelope xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
</env:Header>
<env:Body>
<cms:getNumberOfArticles xmlns:cms="http://www.daily-moon.com/cms">
<cms:category>classifieds</cms:category>
<cms:subcategory>forsale</cms:subcategory>
</cms:getNumberOfArticles>
</env:Body>
</env:Envelope>
24
No se preocupe por la estructura del mensaje, pero observe que hay dos prefijos
distintos, cada uno de los cuales corresponde a un espacio de nombres en particular.
En este caso, diferenciamos el sobre SOAP de la carga til real.
El sobre SOAP
La unidad bsica de un mensaje de servicio web es el sobre SOAP. Se trata de un
documento XML que incluye toda la informacin necesaria para procesar el mensaje.
Ejemplo de mensaje SOAP
<?xml version='1.0' ?> <env:Envelope
xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header> </env:Header> <env:Body>
</env:Body> </env:Envelope>
En este caso, usted tiene un Envelope (Sobre) sencillo, con el espacio de nombres
especificado como SOAP versin 1.2. Incluye los dos sub-elementos, un Header
(Encabezado) y un Body (Cuerpo). Veamos qu hacen cada uno de estos elementos.
El encabezado SOAP
El Header (Encabezado) de un mensaje SOAP tiene la finalidad de proporcionar
informacin acerca del mensaje en s mismo, contrariamente a la informacin
destinada a la aplicacin.
Informacin de ruteo en el Header (Encabezado)
<env:Header>
<wsa:ReplyTo xmlns:wsa=
"http://schemas.xmlSOAP.org/ws/2004/08/addressing">
<wsa:Address>
http://schemas.xmlSOAP.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:From>
<wsa:Address>
25
http://localhost:8080/axis2/services/MyService</wsa:Address>
</wsa:From>
<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID>
</env:Header>
<env:Body>
</env:Body>
</env:Envelope>
El Header (Encabezado) y puede incluir todo tipo de informacin sobre el mensaje en
s mismo. En realidad, la especificacin SOAP insume mucho tiempo en elementos
que pueden ir en el Header (Encabezado), y cmo deben ser tratados por los
"intermediarios SOAP. En otras palabras, la especificacin SOAP no infiere de
manera alguna que el mensaje ir directamente de un punto a otro, desde el cliente
al servidor. Permite la idea de que un mensaje SOAP puede ser procesado en efecto
por diversos intermediarios, en su ruta al destino final, y la especificacin es muy
clara en cuanto a la forma en que debern tratar esos intermediarios la informacin
del Header (Encabezado). Ahora veamos la carga til.
The SOAP body (El cuerpo SOAP)
Cuando usted enva un mensaje SOAP, lo hace con un motivo en mente. Usted trata
de decirle al destinatario que haga algo, o trata de impartir informacin al servidor.
Esta informacin se llama "carga til". La carga til va en el Body del Envolope.
Tambin tiene su propio espacio de nombres, en este caso el que corresponde al
sistema de gestin de contenidos. En este caso, la eleccin del espacio de nombres,
es completamente arbitraria. Slo tiene que ser diferente del espacio de nombres de
SOAP.
Ejemplo de una carga til
<env:Header>
...
26
</env:Header>
<env:Body>
<cms:addArticle xmlns:cms="http://www.daily-moon.com/cms">
<cms:category>classifieds</category>
<cms:articleHeadline></cms:articleHeadline>
<cms:articleText>Vintage 1963 T-Bird. Less than 300 miles.
Driven by my daughter until I took it away. Serious inquires only.
555-3264 after 7 PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
En este caso, usted tiene una carga til simple, que incluye instrucciones para
agregar un artculo al sistema de gestin de contenidos para elDaily Moon.
La seleccin de la estructura de la carga til incluye el estilo y la codificacin.
Estilo y codificacin
Este tema lo ver con mayor profundidad en la parte dos, que habla del Web
Services Description Language (Lenguaje de descripcin de los servicios web,
WSDL), pero cuando cree su aplicacin, necesitar decidir la estructura de la carga
til que enviar una y otra vez. A tal fin, tomemos unos instantes para hablar de la
programacin del estilo y de la codificacin.
Dicho de manera sencilla, predominan dos estilos de programacin diferentes para
los mensajes SOAP. El primero es el estilo RPC, que se basa en el concepto de usar
mensajes SOAP para crear Remote Procedure Calls (Llamadas a procedimientos
remotos). Estilo RPC
<env:Envelope
xmlns:env="http://www.w3.org/2003/05/SOAP-envelope">
<env:Header>
La alternativa al estilo RPC implica que usted tenga solamente sus datos como
27
contenido del cuerpo SOAP, e incluye la informacin relativa al procedimiento o

funcin a la que sta pertenece en el ruteo del mensaje por parte del servidor de
aplicaciones (ver Listado 12).
Listado 12. Datos como contenido en el cuerpo SOAP
<env:Header>
</env:Header>
<env:Body>
<cms:articleHeadline></cms:articleHeadline>
<cms:articleText>Vintage 1963 T-Bird. Less than 300
miles. Driven by my daughter until I took it away.
Serious inquires only. 555-3264 after 7 PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
Una variante del estilo RPC es RPC/encoded (RPC/codificado), a diferencia de
RPC/literal, como podemos ver arriba.
.Ejemplo de RPC/codificado
<env:Header>
</env:Header>
<env:Body>
28
<cms:category xsi:type="xsd:string">classifieds</category>
<cms:subcategory xsi:type="xsd:string">forsale
</cms:subcategory>
<cms:articleHeadline xsi:type="xsd:string" />
<cms:articleText xsi:type="xsd:string">Vintage 1963
T-Bird. Less than 300 miles. Driven by my daughter until
I took it away. Serious inquires only. 555-3264 after 7
PM.</cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
Al segundo estilo se lo conoce como estilo document/literal, que implica nicamente
la incorporacin de los datos apropiados en el mensaje.
Ejemplo de estilo document/literal
<env:Header>
</env:Header>
<env:Body>
<category>classifieds</category>
<subcategory>forsale</subcategory>
Driven by my daughter until I took it away. Serious
inquires only. 555-3264 after 7 PM.</articleText>
</env:Body>
</env:Envelope>
En este caso, el mensaje propiamente dicho no incluye informacin acerca del
29
proceso del destino a donde debern ser enviados los datos; eso lo maneja el
software de ruteo. Por ejemplo, todos los llamados a una URL o punto final en
particular deben apuntar a una operacin en particular. Usted tambin podra usar el
estilo documento/codificado tcnicamente, pero nadie lo hace, as que, por el
momento, olvdelo.
Cada uno de estos estilos implica concesiones mutuas y, reitero, la parte dos de esta
serie los abarca con ms detalle. Sin embargo, es importante saber que hay un
tercer estilo, "document wrapped," que no est especificado formalmente en ninguna
parte, pero que se ha hecho popular por diversos motivos de interoperabilidad. En
este caso, el contenido de la carga til est ajustado en un nico documento, pero
ese elemento no puede llevar el mismo nombre de la aplicacin o procedimiento al
que pertenecen los datos. Para el ojo humano, estos mensajes son virtualmente
idnticos a los mensajes RPC/literales.
Patrones de intercambio de mensajes
Cuando se trata del envo de mensajes, usted cuenta con una amplia variedad de
opciones, que van desde el envo de una solicitud y la espera de una respuesta, al
envo de una solicitud y olvidarse de ella, hasta el envo de una solicitud y hacerla
pasar a travs de intermediarios mltiples antes de que llegue a su destino final No
obstante, al final, slo tiene dos opciones:
Solicitud/Respuesta: Segn el patrn Solicitud/Respuesta, usted enva una solicitud
con forma de mensaje SOAP y simplemente espera la llegada de una respuesta. La
solicitud puede ser sincrnica o asincrnica.
Mensajera unidireccional: Este caso, tambin conocido como mtodo dispare y
olvdese, implica el envo de la solicitud para despus olvidarse directamente de
ella. Esto lo puede usar en situaciones en las que simplemente imparte informacin,
o en alguna otra en la que, en realidad, no le importa lo que el destinatario pueda
decir de ella.
Ahora, observe la falta de los trminos cliente y servidor. Esto se explica porque
estos patrones de intercambio de mensajes pueden usarse bsicamente para crear
cualquier cantidad de alternativas diferentes, tal cual las mencionadas un poco ms
arriba. Por ejemplo, usted puede crear una situacin en la cual enva una solicitud, y
30
cuenta con que el destinatario se ocupar de ella,

Creacin de un cliente SOAP
Bien, ya vio la teora, ahora lleg el momento de crear las aplicaciones reales.
Comencemos por el cliente.
La forma antigua
Cuando aparecieron por primera vez las APIs Java para el trabajo con mensajes
SOAP, eran muy especficas en cuanto a su razn de ser. Eran, a las claras, para la
creacin del mensaje SOAP. Se requera que usted creara el mensaje, el Envelope
(Sobre), el Header (Encabezado), el Body (Cuerpo), etc. Por ejemplo, puede crear un
cliente segn el estilo antiguo para acceder a la funcin echo (eco) del servicio
MyServiceque instal antes (ver Listado 15).
Nota: Para compilar y ejecutar este cliente, necesitar una implementacin SAAJ,
como
el
software
original
de
Axis.
Puede
descargar
Axis
http://ws.apache.org/axis/.
Cliente SOAP en la forma antigua
import javax.xml.SOAP.*;
import javax.xml.transform.*;
import java.io.FileInputStream;
import javax.xml.transform.stream.*;
import org.w3c.dom.*;
public class SendSOAP {
public static void main(String args[]) {
try {
MessageFactory messageFactory = MessageFactory.newInstance();
SOAPMessage message = messageFactory.createMessage();
//Create objects for the message parts
31
desde
SOAPPart SOAPPart = message.getSOAPPart();

SOAPEnvelope envelope = SOAPPart.getEnvelope();
SOAPBody body = envelope.getBody();
SOAPElement bodyElement =
body.addChildElement(envelope.createName("echo",
"req", "http://localhost:8080/axis2/services/MyService/"));
bodyElement.addChildElement("category")
.addTextNode("classifieds");
message.saveChanges();
SOAPPart SOAPpartbefore = message.getSOAPPart();
SOAPEnvelope reqenv = SOAPpartbefore.getEnvelope();
System.out.println("REQUEST:");
System.out.println(reqenv.toString());
//Now create the connection
SOAPConnectionFactory SOAPConnFactory =
SOAPConnectionFactory.newInstance();
SOAPConnection connection =
SOAPConnFactory.createConnection();
SOAPMessage reply = connection.call(message,
"http://localhost:8080/axis2/services/MyService");
SOAPPart SOAPpart = reply.getSOAPPart();
SOAPEnvelope replyenv = SOAPpart.getEnvelope();
System.out.println("\nRESPONSE:");
System.out.println(replyenv.toString());
32
connection.close();
} catch (Exception e){
System.out.println(e.getMessage());
}
}
}
Note que usted crea directamente el SOAPEnvelope, SOAPBody, etc. Usted puede
agregar elementos, tales como el elemento echo (eco) y el elemento category
(categora) en ese cuerpo. A partir de all, usted crea la conexin, hace la llamada, y
podr volver a abrirse camino a travs de la estructura del mensaje SOAP para llegar
al contenido.
El cliente hasta aqu
REQUEST:
<SOAPenv:Envelope xmlns:SOAPenv=
"http://schemas.xmlSOAP.org/SOAP/envelope/"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<SOAPenv:Body>
<req:echo xmlns:req=
"http://localhost:8080/axis2/services/MyService/">
</req:echo>
</SOAPenv:Body>
</SOAPenv:Envelope>
RESPONSE:
<SOAPenv:Envelope xmlns:SOAPenv=
"http://schemas.xmlSOAP.org/SOAP/envelope/" xmlns:wsa=
"http://schemas.xmlSOAP.org/ws/2004/08/addressing">
33
<SOAPenv:Header>
<wsa:ReplyTo>
<wsa:Address>
http://schemas.xmlSOAP.org/ws/2004/08/addressing/role/anonymous
</wsa:Address>
</wsa:ReplyTo>
<wsa:From>
<wsa:Address>
http://localhost:8080/axis2/services/MyService</wsa:Address>
</wsa:From>
<wsa:MessageID>ECE5B3F187F29D28BC11433905662036</wsa:MessageID>
</SOAPenv:Header>
<SOAPenv:Body>
<req:echo xmlns:req=
"http://localhost:8080/axis2/services/MyService/">
</req:echo>
</SOAPenv:Body>
</SOAPenv:Envelope>
Todo lo que, en realidad hace el servicio echo es volver a solicitar con la solicitud que
ha recibido, lo que es una buena oportunidad para ver la diferencia entre el proceso
del estilo antiguo y el estilo nuevo. Hablemos de esa diferencia.
La forma nueva
En la actualidad, hay un movimiento creciente para esconder la complejidad del
trabajo del programador con los mensajes de servicios web basados en XML. Han
surgido todo tipo de iniciativas, la mayora de las cuales tienden a hacer la
programacin de los servicios web lo ms parecido a programar cualquier otra
arquitectura.
En Axis2, esto significa ms que eso. Axis2 presenta una forma totalmente nueva de
trabajo con el XML que representa al mensaje SOAP, aunque en la superficie sea
muy similar al uso de Document Object Model (Modelo de Objetos de Documentos,
34
DOM). El modelo de objeto AXIs, o AXIOM, hace muchos cambios, pero por el
momento slo mencionar que se concentra en el conjunto de informacin del
mensaje, que es la informacin genuina contenida en los elementos y atributos, ms
que en la versin en serie de las etiquetas que vemos normalmente..
Crear la solicitud
Para comenzar con la creacin del cliente, asegrese de que todos los archivos *.jar
del directorio Axis2 lib que sera la distribucin Estndar, no la War estn en su
CLASSPATH, y cree una clase nueva llamada ClassifiedClient. Cree la carga til
como se muestra en el Listado 17.
Listado 17. Carga til
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.om.OMElement;
import javax.xml.stream.XMLOutputFactory;
import javax.xml.stream.XMLStreamException;
import java.io.StringWriter;
import org.apache.axis2.om.OMAbstractFactory;
import org.apache.axis2.SOAP.SOAPFactory;
import org.apache.axis2.om.OMFactory;
import org.apache.axis2.om.OMNamespace;
public class ClassifiedClient {
public static OMElement getEchoOMElement() {
SOAPFactory fac = OMAbstractFactory.getSOAP12Factory();
OMNamespace omNs = fac.createOMNamespace(
"http://daily-moon.com/cms", "cms");
OMElement method = fac.createOMElement("echo", omNs);
35
OMElement value = fac.createOMElement("category", omNs);

value.addChild(fac.createText(value, "classifieds"));
method.addChild(value);
return method;
}
public static void main(String[] args) {
try {
OMElement payload = ClassifiedClient.getEchoOMElement();
} catch (Exception e) { //(XMLStreamException e) {
System.out.println(e.toString());
}
}
}
Primero, usted crea un generador y un espacio de nombres, y los usa para crear
elementos. En este caso, usted crear los mismos elementos que cre en el ejemplo
anterior, ya que usar otra vez este cliente para acceder a la funcin echo. (Ms
adelante, lo cambiar para acceder al servicio real.)
Luego, crear la solicitud.
Crear la solicitud
El paso siguiente es crear la solicitud real. Aqu volver a ver la marcha del tiempo.
En lugar de enviar simplemente la solicitud a una URL, usted configura una
"referencia de extremo".
Referencia de extremo en la solicitud
...
private static EndpointReference targetEPR = new
EndpointReference(
"http://localhost:8080/axis2/services/MyService");
36

...
}
try {
Options options = new Options();
options.setTo(targetEPR);
options.setTransportInProtocol(Constants.TRANSPORT_HTTP);
}
}
}
El comentario completo acerca de WS-Addressing est fuera del alcance de este
tutorial, pero basta decir que una referencia de extremo incluye la URL hacia donde
se orienta el mensaje pero que, opcionalmente, puede incluir otra informacin, tal
como una respuesta-a la direccin, y otras propiedades de los recursos.
Primero, usted crea las Opciones para la solicitud, las que le permitirn configurar la
EPR (referencia de extremo) para la solicitud, como as tambin otra informacin,
como por ejemplo, el transporte que piensa usar. Una vez que tiene todo eso listo, ya
puede enviar la solicitud.
Enviar la solicitud
Una vez que ha configurado todo, es hora de enviar la solicitud. Desde Axis, hasta la
versin 0.94, la forma preferible de enviar un mensaje es a travs de la clase
ServiceClient.
Envo de la solicitud
...
37
try {
ServiceClient sender = new ServiceClient();
sender.setOptions(options);
OMElement result = sender.sendReceive(payload);
}
}
}
Usted crea el objeto ServiceClient y configura las Options (Opciones) que cre
anteriormente para l. A partir de all, ya podr enviar el mensaje. Y como quiere
obtener una respuesta, usar el mtodo sendReceive() que es un mensaje de
entrada/salida. Ver la mensajera unidireccional en el captulo The one-way service
(Servicio unidireccional) de este tutorial. El mtodo sendReceive() remite la
respuesta real, tal como la recibi el cliente.
Enviar el resultado
En realidad, sendReceive() no remite toda la respuesta, sino nicamente la carga til.
Si usted enva el resultado a la lnea de comandos.
Envo de sendReceive
...
System.out.println(result.toString());
38

}
}
}
La ejecucin de este cliente le da la respuesta que aparece en el Listado 21.
Listado 21. Respuesta de sendReceive
<cms:echo xmlns:cms="http://daily-moon.com/cms"><cms:catego
ry>classifieds</cms:category></cms:echo>
Por supuesto, podr hacer muchas cosas con estos datos, una vez que los recibe.
Por ahora, vamos a crear el verdadero serviciogetNumberofArticles().
Creacin de un servicio SOAP
Si el proceso de creacin de un servicio web le resulta bastante sencillo, tiene razn.
Y la creacin de un servicio, hasta cierto punto, es igualmente sencilla.
Proceso general
El proceso general de la creacin de un servicio web Axis2 implica los siguientes
pasos:
Crear el manifiesto de servicios
Crear la clase
Empaquetarlos en un archivo de almacenamiento Axis
Cargar el archivo de almacenamiento Axis en la aplicacin Web Axis2
De ser necesario, reiniciar el servidor
Eso es todo. Comencemos con el manifiesto de servicios.
Crear el manifiesto
El manifiesto de servicios le dice a la aplicacin Axis2 (y por extensin, al servidor de
aplicaciones) qu solicitudes corresponden a qu clases.
Especificacin de dos funciones de servicio en el manifiesto
<service name="CMSService">
<description>
This is a sample web service for the newspaper's
Content Managment System.
39
</description>
<parameter name="ServiceClass" locked="false"
>CMSService</parameter>
<operation name="getNumberOfArticles">
<messageReceiver class=
"org.apache.axis2.receivers.RawXMLINOutMessageReceiver"/>
</operation>
<operation name="addArticle">
<messageReceiver class=
"org.apache.axis2.receivers.RawXMLINOnlyMessageReceiver"/>
</operation>
</service>
First, you define the overall service, giving it a name and a description and specifying
the class to actually serve the request. Next, you define the actual operations. Notice
that this example specifies two different types of messageReceiver. El primero,
RawXMLINOutMessageReceiver, es para el servicio solicitud/respuesta tradicional.
El segundo, RawXMLINOnlyMessageReceiver es para mensajes unidireccionales. El
nombre de la operacin corresponde al elemento raz de la carga til, como as
tambin el mtodo a ejecutar.
Guarde este archivo como services.xml.
Ahora creemos la aplicacin real.
Crear la aplicacin
Comience con la creacin de una clase que imite la funcin echo (eco) que vimos
antes, remitiendo una copia de la carga til original.
Clase CMSService
40
public class CMSService {
public OMElement getNumberOfArticles(OMElement element)
throws XMLStreamException {
element.build();
element.detach();
return element;
}
}
Para compilar esta aplicacin, asegrese de que todos los archivos *.jar de
<axis2_home>/lib estn en su CLASSPATH.
La aplicacin es bastante sencilla, con una sola funcin que corresponde a la
operacin getNumbereOfArticles Esta funcin, y cualquier otra funcin que tenga
como destino una operacin, toma un nico OMElement, que representa la carga til.
Aqu, usted primero usa el mtodobuild() para asegurarse de que se hayan recibido
todos los datos AXIOM usa un mtodo pull de acceso a los datos y luego
desvincula el elemento de su rbol actual para poder remitirlo.
Si se cree valiente, no dude en Implementar el servicio y en Acceder al servicio para
acceder al servicio y ver los resultados. Deber ver algo similar a lo que se muestra
en el Listado 24.
Listado 24. Respuesta de la Clase CMSService
<cms:getNumberOfArticles><cms:category>classifieds</cms:category></cms:
getNumberOfArticles>
Ahora veamos cmo manejar los datos en la realidad.
Extraer la carga til
41
La extraccin de informacin de la carga til es una forma de manipulacin del

elemento carga til recibido usando tcnicas muy similares a DOM (ver Listado 25).
Listado 25. Extraccin de informacin de la carga til
...
element.build();
element.detach();
String rootName = element.getLocalName();
OMElement categoryElement = element.getFirstElement();
String categoryElementName = categoryElement.getLocalName();
String categoryValue = childElement.getText();
return element;
}
}
Crear y remitir la respuesta
Para terminar, usted usar los datos que extrajo de la carga til de la solicitud para
crear una respuesta. En este caso, lo alimentar a una segunda funcin que, en una
aplicacin real, hara otro trabajo.
Creacin de una respuesta
...
42
element.build();
element.detach();
String rootName = element.getLocalName();
OMElement childElement = element.getFirstElement();
String childName = childElement.getLocalName();
String categoryValue = childElement.getText();
SOAPFactory factory = OMAbstractFactory.getSOAP12Factory();
OMNamespace namespace = factory.createOMNamespace(
"http://daily-moon.com/cms/", "resp");
OMElement resultElem = factory.createOMElement(
"numberOfArticles",namespace);
String actualValue =
(articleCount(categoryValue)).toString();
resultElem.setText(actualValue);
return resultElem;
}
private Integer articleCount(String catId){
//Perform some function such as searching the CMS
//database, and return the actual value. For our
//purposes, you'll hardcode it.
return new Integer(42);
}
}
Primero, cree el generador que usar para crear todos los otros objetos, y despus
43
cree el espacio de nombres que agregar a la carga til de la respuesta. A

continuacin, cree los elementos de resultado reales, en este caso un elemento
llamado numberOfArticles.
El contenido del elemento numberOfArticles ser un nmero que devolver la funcin
articleCount() que, en este caso, es completamente arbitrario. En una aplicacin real,
usted har todo lo que sea necesario para obtener este dato. Una vez obtenido, lo
configurar como contenido del elemento numberOfArticles y simplemente remitir
ese elemento.
Lo nico que falta ahora, es implementar el servicio.
Implementar el servicio
Para poder implementar el servicio, deber crear un archivo de almacenamiento Axis.
Este archivo es como un archivo *.jar o *.war, ya que se trata de un simple archivo
zip con una extensin de archivo especial, en este caso .aar. Siga estos pasos para
crear este archivo:
Incorpore todos los archivos del directorio <AXIS2_HOME>/lib a su CLASSPATH y
compile el archivo CMSService.java.
Cree un directorio nuevo llamado META-INF en el mismo directorio del archivo
CMSService.class.
Desde el directorio que contiene el archivo CMSService.class, emita este comando:
<code type="section" width="100"> jar cvf CMSService.aar ./* </code> Deber ver
como resultado, algo parecido a: <code type="section" width="100"> added manifest
adding:
CMSService.class(in
513)
(out=
330)(deflated
35%)
adding:
CMSService.java(in = 328) (out= 182)(deflated 44%) ignoring entry META-INF/

adding: META-INF/services.xml(in = 391) (out= 229)(deflated 41%) </code>
Incorpore el servicio al servidor siguiendo los pasos descriptos en Instalacin de un
servicio de muestra. (Si ve errores de servlet en la interfaz Web, asegrese de haber
iniciado sesin en la aplicacin Axis2. Si su sesin venci, la aplicacin no se lo
avisar, pero probablemente le muestre un error.)
En caso de ser necesario, reinicie Geronimo. (Es probable que no deba hacerlo
despus de haber incorporado el servicio, pero probablemente deba hacerlo despus
de realizar cambios.)
44
Servicios disponibles
Acceder al servicio
Ahora que cre el servicio, lleg la hora de acceder a l a travs del cliente. Haga los
siguientes cambios en el archivo ClassifiedClient.java que cre anteriormente
private static EndpointReference targetEPR =
new EndpointReference(
"http://localhost:8080/axis2/services/CMSService");
"http://daily-moon.com/cms", "cms");
OMElement method = fac.createOMElement("getNumberOfArticles", omNs);
OMElement value = fac.createOMElement("category", omNs);
value.addChild(fac.createText(value, "classifieds"));
method.addChild(value);
return method;
}
try {
ServiceClient sender = new ServiceClient();
45
String response = result.getText();
System.out.println("There are "+response+" classifieds at the moment.");
}
}
}
Cuando compile y ejecute esta aplicacin, deber ver la respuesta que aparece en el
Listado 28.
Listado 28. Respuesta de ClassifiedClient
En este momento hay 42
clasificados.
El servicio unidireccional
Antes seguir adelante, veamos las diferencias que implica trabajar con un servicio
unidireccional, en lugar de hacerlo con uno de solicitud/respuesta.
El servicio
La creacin de un servicio unidireccional es bastante sencilla. El proceso es
exactamente el mismo que para la creacin de un servicio solicitud/respuesta, con la
excepcin de que no remite nada
En el archivo services.xml, usted especific la operacin addArticle como una
operacin entrante nicamente, por lo que no se esperar remitir nada, pero slo
para que pueda ver que, en realidad sucede algo, enve la carga til recibida a la
lnea de comandos. La ver en la ventana de Geronimo.
En una aplicacin real, este mtodo extraera la informacin de la carga til para
incorporarla a determinado tipo de base de datos o repositorio.
El cliente
46
El cliente para este servicio tambin es similar al que usted usara para un servicio
solicitud/respuesta (ver Listado 30).
Listado 30. Creacin del cliente
import org.apache.axis2.addressing.EndpointReference;
import org.apache.axis2.client.Options;
import org.apache.axis2.client.ServiceClient;
import org.apache.axis2.SOAP.SOAPFactory;
import org.apache.axis2.om.OMAbstractFactory;
import org.apache.axis2.om.OMNamespace;
public class AddArticleClient {
private static EndpointReference targetEPR =
new EndpointReference(
"http://localhost:8080/axis2/services/CMSService");
private static OMElement getOMElement(){
"http://daily-moon.com", "cms");
OMElement method = fac.createOMElement("addArticle", omNs);
OMElement category = fac.createOMElement("category", omNs);
category.setText("classifieds");
OMElement subcategory =
fac.createOMElement("subcategory", omNs);
category.setText("wantads");
OMElement adtext = fac.createOMElement("article", omNs);
47
adtext.setText("Do you have good head for numbers"+

" and a great deal of patience? Do you like"+
" to sit for hours sorting objects by their"+
" size? If so, then you could be the"+
" next goober counter in the world famous"+
" Murphy Brothers peanut factory. "+
" Willingness to dress up as our mascot"+
" helpful, but not required.");
method.addChild(category);
method.addChild(subcategory);
method.addChild(adtext);
return method;
}
try {
OMElement payload = AddArticleClient.getOMElement();
ServiceClient serviceClient = new ServiceClient();
serviceClient.setOptions(options);
serviceClient.fireAndForget(payload);
} catch (AxisFault axisFault) {
axisFault.printStackTrace();
}
48
}
}
Aunque la carga til es diferente, por lo que puede ver en el mtodo
getOMElement(), el nico cambio verdadero, en lo que hace a la programacin, es el
uso del mtodo fireAndForget() en lugar del mtodo sendReceive(). Este mtodo no
devuelve una respuesta.
Si ejecuta este cliente, ver un envo en la ventana de Geronimo, similar al que
aparece en la Figura 5.
Figura 5. Envo de la lnea de comandos
Acceso al servicio va GET
Antes de SOAP 1.2, la nica forma de acceder a un servicio web basado en SOAP
con el uso de HTTP, era mediante el uso de una solicitudPOST. Usted tena que
crear un cliente que creara una solicitud POST con el mensaje SOAP como
contenido de esa solicitud. Sin embargo, SOAP 1.2, define la forma de acceder a un
servicio web basado en SOAP con el uso de una solicitud GET.
GET contra POST
Antes de seguir adelante, es importante comprender la diferencia entre las
solicitudes GET y POST en HTTP. Aunque muchos programadores actan como si
estas dos solicitudes fuesen intercambiables, existe en realidad un motivo para cada
una de ellas. GET, donde toda la informacin acerca del recurso que usted solicita
est contenida en la URL, por lo general como parmetros, est destinada al uso
exclusivo de solicitudes idempotentes. Esas son solicitudes para las que no hay
efectos secundarios. En otras palabras, usted podr llamar a esa solicitud una
docena de veces, cien veces, mil veces; y no debera cambiar nada. Por ejemplo,
una solicitud Web para la temperatura actual en Albuquerque es idempotente. Una
solicitud Web que inserta un comentario en la base de datos de un blog no lo es.
.
En lo que respecta a SOAP, esto significa que usted debe ser capaz de usar GET
para solicitudes SOAP que simplemente recuperan informacin sin hacer cambios.
49
Tambin debera usar POST para cualquier operacin que s haga cambios.
Acceso al servicio
En Axis2, puede crear una solicitud GET y el servidor la traducir a un mensaje
SOAP y remitir como resultado la carga til. Por ejemplo, apunte su navegador a la
ubicacin que aparece en el Listado 31.
Listado 31. Acceso a los servicios
http://localhost:8080/axis2/services/CMSService/getNumberOfArticles?
category=classifieds
Desde la versin 0.94 usted ver una respuesta como la que aparece en el Listado
32.
Listado 32. Respuesta de la carga til SOAP
<resp:numberOfArcticles>42</resp:numberOfArcticles>
Sin embargo, esto no es muy preciso. Segn la Recomendacin SOAP 1.2, usted
debera ver la respuesta SOAP completa. Esto probablemente cambie con las
versiones futuras de Axis2.
Manejo de adjuntos
Otra variante del mensaje SOAP comn es el adjunto. Los adjuntos se han ido
metiendo en la piel de la gente durante aos, pero dado que ahora son requeridos
por determinadas especificaciones ampliadas, hay que aprender a manejarlos.
Datos binarios y XML
Aunque XML es un formato basado en texto, no podemos ignorar que existe un
mundo binario. Como tal, llegar el momento en que debamos pasar informacin
binara hacia o desde un servicio web.
Usted podr manejar esta situacin de una de estas dos formas: La primera opcin
es incluir el dato binario dentro del documento. Un ejemplo de esto sucede cuando
guardamos un documento de Microsoft Word como archivo XML. Si tenemos
imgenes incrustadas en ese documento, Word las incrusta en el documento XML
como dato binario, codificado en Base64. La segunda opcin es referenciar el dato
para que la aplicacin que procesa el documento la pueda encontrar. Un ejemplo
muy significativo de esto es un navegador Web y cmo maneja las imgenes
50
referenciadas desde un archivo HTML. El archivo XHTML incluye un elemento de

img, (o, si usted es adecuadamente avanzado, un elemento de object y ese elemento
incluye un atributo src que contiene la URL que apunta a ese dato. La aplicacin
puede entonces cargar el dato desde esa ubicacin y usarlo apropiadamente.
Paquetes Optimizados XML binario
Como puede ver, XML, ya es ms detallado de lo que quisieran los oponentes del
binario. Y como tal, usa mucho ms ancho de banda. Entonces, cuando usted
considera el hecho de que el mtodo preferido para incorporar datos binarios a un
documento de texto XML codificndolo como Base64 tiene la tendencia a
incrementar su tamao por un factor de dos o ms, usted tiene un verdadero
problema.
En realidad, hubo tanto revuelo en los ltimos aos, por la falta de algn tipo real de
soporte para los datos binarios, que fue casi una rebelin, y W3C se ocup del
problema. Como resultado, aparecieron los Paquetes optimizados XML binario
(XOP). Este protocolo proporciona una formar de referenciar de manera fiable los
datos externos desde dentro de un documento XML. Por ejemplo, la especificacin
SOAP con Adjuntos deca que el dato binario poda enviarse como parte de un
documento MIME multiparte, donde el dato XML compona la primera parte, y el dato
binario incorporado, como partes adicionales. El problema de esto es que, aunque su
programa pueda desconocer la existencia del dato, el documento no. Tampoco
permite la optimizacin selectiva del documento, o el procesamiento retroactivo de un
documento existente que incluya datos binarios.
XOP mejora esta situacin mediante el suministro de un mecanismo por el cual se
puede extraer selectivamente la informacin que debe ser optimizada, la incorpora a
un mensaje MIME multiparte que tambin incluye nuestro mensaje SOAP, y hace una
referencia directa a l.
XOP especifica que, en cambio, usted extraiga el dato, y lo reemplace con un
elemento Include (Incluir), que referencie su nueva ubicacin, como en este ejemplo
que aparece en el Listado 34.
Uso de XOP
51
MIME-Version: 1.0
Content-Type: Multipart/Related;boundary=MIME_boundary;
type="application/xop+xml";
start="<soapmsg.xml@daily-moon.com>";
start-info="text/xml"
Content-Description: An XML document with binary data in it
--MIME_boundary
Content-Type: application/xop+xml;
charset=UTF-8;
type="text/xml"
Content-Transfer-Encoding: 8bit
Content-ID: <soapmsg.xml@daily-moon.com>
<env:Header>
</env:Header>
<env:Body>
<cms:subcategory>forsale
</cms:subcategory>
<cms:articleHeadline><cms:articleHeadline>
<cms:articleText><xop:Include
xmlns:xop='http://www.w3.org/2004/08/xop/include'
href='cid:http://daily-moon.com/tbird.doc'
/></cms:articleText>
</cms:addArticle>
</env:Body>
</env:Envelope>
52
--MIME_boundary
Content-Type: application/vnd.oasis.openoffice
Content-Transfer-Encoding: binary
Content-ID: <http://daily-moon.com/tbird.doc>
// binary octets for the word processing file
--MIME_boundary-Observe que la ubicacin especificada en el elemento Include (Incluir), coincide con
la Content-ID (ID de contenido), menos el protocolo decid:. Ahora es ste el mensaje
que se enva, en lugar de un mensaje SOAP de texto comn.
SOAP, datos binarios, y Axis2

El proceso de utilizacin de XOP en documentos SOAP se denomina MTOM (para
Mecanismo de optimizacin de transmisin de mensajes SOAP). Axis2 proporciona
soporte para esta forma de trabajo con datos SOAP, pero usted debe asegurarse de
configurar la aplicacin de manera apropiada.
Uso de XOP con Axis2
<axisconfig name="AxisJava2.0">



<parameter name="hotdeployment" locked="false">true</parameter>
<parameter name="hotupdate" locked="false">true</parameter>
<parameter name="enableMTOM" locked="false">true</parameter>


53
<parameter name="userName" locked="false">admin</parameter>

<parameter name="password" locked="false">axis2</parameter>
...
De ser necesario, puede extraer el archivo axis2.war, hacer este cambio, y volver a
comprimirlo en un .war.
reemplazar la aplicacin Axis2, visite la consola Geronimo, usando la URL que
aparece en el Listado 36.
Conclusin
Hay diferentes tipos de servidores web, entre ellos se encuentra el xammp, el cual es
un programa que maneja el servidor apache, as como el gestor de Base de Datos
MYSQL.
Con esta investigacin tenemos en cuenta que hay variedad de servidores web.
Bibliografa
BOX,
Don. A
brief
history
of
SOAP. http://webservices.xml.com/pub/a/ws/2001/04/04/soap.html
MILLS, Davis (dir). Semantic Wave 2006. SemTech 2006. http://www.semanticconference.com/semanticwave.html [Volver]
MOLLER, Anders. SCHAWARTZBACH, Michael I. Interactive Web Services with
Java,
JSP,
Servlets,
JWIG,
SOAP,
WSDL,
UDDI. http://www.brics.dk/~amoeller/WWW/
http://www.brics.dk/ixwt/IXWT_C04c.pdf In An Introduction to XML and Web
54
Techonologies.
MOLLER,
Anders.
SCHWARTZBACH,
Michael
I.
"Chapter
11.
Web
Services". http://www.brics.dk/ixwt/webservices.pdf In An Introduction to XML and

Web Techonologies. Slides PDF. http://www.brics.dk/ixwt/slides.html
OGBUJI, Uche. Using WDSL in SOAP applications: An introduction to WDSL for
programmers. http://www-128.ibm.com/developerworks/library/ws-soap/?dwzone=ws
VASUDEVAN,
Venu. A
Web
Services
Primer. http://webservices.xml.com/pub/a/ws/2001/04/04/webservices/index.html
VeriSign. XML
Trust
Services
Overview. http://www.verisign.com/rsc/wp/xml/xmloverview/xmloverview_wp.pdf
W3C.es Gua
breve
de
Servicios
Web. http://www.w3c.es/Divulgacion/Guiasbreves/ServiciosWeb
W3C. Semantic Web Activity. http://www.w3.org/2001/sw/
W3C. Simple SOAP. http://www.w3.org/TR/soap12-part1/
W3C. SOAP
Message
Transmision
Optimization
(MTOM). http://www.w3.org/TR/soap12-mtom/
W3C. Web Services Addredsing (WS-Addressing). http://www.w3.org/TR/ws-addrcore/
W3C. Web Services Description Language (WSDL). http://www.w3.org/TR/wsdl20/
W3C. Web
Services
Choreography
Description
Language
(WS-
Standarization:
An
CDL). http://www.w3.org/TR/ws-cdl-10/
W3C. Web
Services,
Semantic
and
Overview. http://www.w3.org/2005/Talks/0712-hh-ec/
WEb Services Int
XAML http://www.xaml.org
XMethods. http://www.xmethods.com/
55

Investigación Servicios Web

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Investigación Servicios Web

Uploaded by

Copyright:

Available Formats

INSTITUTO TECNOLOGICO

MEDELLIN DE BRAVO, VER. FEB. JUN. 2014

La World Wide Web no es slo un espacio de informacin, tambin es un espacio

basa en los siguientes componentes:

Disear un marco de mensajera:

Simple SOAP: Simple Object Access Protocol es un protocolo

simple para intercambiar informacin estructurada en un ambiente

Web Services Addressing (WS-Addressing): Direccionamiento de

Servicios Web. La direccin de los servicios Web proporciona

SOAP Message Transmission Optimization (MTOM) Descripcin

de la Optimizacin de la Transmisin del Mensaje. Describe una

Descripcin de los Servicios:

Web Services Description Language (WSDL): Lenguaje de

Descripcin de los Servicios Web. Se trata de un lenguaje para describir

Web Services Choreography Description Language (WS-CDL):

Lenguaje de Descripcin de la Coreografa de los Servicios Web. Es un

independientemente del sistemas operativo o plataforma en que se ejecuten y de los

que pueden ser comunes a otros servicios), de mensajera, de descripcin y

especificaciones del formato de datos para un tipo particular de puerto constituye un

Operacin (Operation): una descripcin abstracta de una accin soportada

Tipo de puerto (Port Type): un conjunto abstracto de operaciones soportadas

Conexin (Binding): un protocolo concreto y una especificacin de formato

Servicio (Service): una coleccin de puntos finales relacionados.

Por ltimo, en la capa superior se encuentra UDDI (Universal Description, Discovery

estructurada en un entorno descentralizado y distribuido, se utiliza el protocolo SOAP

Flow of UDDI messages between Client and Registry.Fuente: Tom Bellwood.

semntico comn de OWL y WSML. Ms informacin al respecto, se puede obtener

environment) que es el entorno de ejecucin de modelado de servicios web y la

la especificacin formal de la ontologa y para proeer interoperabilidad con otros

Semantic Web Enabled Web Services (SWWS): es un proyecto de la

Ontogrid: es un proyecto que coordina la Universidad Politcnica de

el ordenador del usuario, ya fuera mediante programas originales o copias piratas),

tecnologas con capacidad para interpelar en la Web. Estas aplicaciones o

header (cabecera) y body (cuerpo).

Para optimizar el rendimiento de las aplicaciones basadas en Servicios Web, se han

http://localhost:8080/axis2/Login.jsp y despus inicie la sesin. El nombre de usuario

y la contrasea predeterminados son admin y Axis2, respectivamente.

inquires only. 555-3264 after 7 PM.</articleText>

contenido del cuerpo SOAP, e incluye la informacin relativa al procedimiento o

cuenta con que el destinatario se ocupar de ella,

SOAPPart SOAPPart = message.getSOAPPart();

OMElement value = fac.createOMElement("category", omNs);

public static OMElement getEchoOMElement() {

} catch (Exception e) { //(XMLStreamException e) {

La extraccin de informacin de la carga til es una forma de manipulacin del

cree el espacio de nombres que agregar a la carga til de la respuesta. A

CMSService.java(in = 328) (out= 182)(deflated 44%) ignoring entry META-INF/

adtext.setText("Do you have good head for numbers"+

referenciadas desde un archivo HTML. El archivo XHTML incluye un elemento de

SOAP, datos binarios, y Axis2

<parameter name="enableREST" locked="false">true</parameter>-->

<parameter name="userName" locked="false">admin</parameter>

Services". http://www.brics.dk/ixwt/webservices.pdf In An Introduction to XML and

You might also like