Java Modulo 7

Profesional en Plataforma Java
Mdulo 7. Creando servicios web usando la tecnologa Java. Puesta en marcha de redes VLAN y trunks
Contenido Mdulo 7. Creando servicios web usando la tecnologa Java. Puesta en marcha de redes VLAN y trunks
Unidad 1 - Idificando la construccin de bloques de servicios Web Unidad 2 - Analizando la tecnologa y plataforma de servicios Web Unidad 3 - Aplicando XML Unidad 4 - Examinando mensajes SOAP Unidad 5 - Desarrollando Servicios Web usando SOAP con adjuntos Unidad 6 - Explicando el lenguaje de Servicios Web (WSDL) Unidad 7 - Reconociendo el papel del servicios de registro Unidad 8 - Implementando servicios web con Java API para servicios web XML con tecnologa (JAX-WS) (JAX Unidad 9 - Desarrollando servicios Web cliente
www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 1: Identificando la construccin de bloques de servicios Web

Objetivos
x x Conocer toda la estructura de elementos que conforman un Servicio Web. Aprender los conceptos esenciales para cada bloque incluido dentro de un Web Service.
Introduccin
Desde que apareci el World Wide Web, internet ha experimentado una gran evolucin. En un principio, internet estaba formado por pginas estticas escritas en HTML. stas s no eran actualizadas muy a menudo y los usuarios no tenan posibilidad de participar en la creacin de los contenidos que se mostraban por la red. A este tipo de servicios nos referimos cuando hablamos de Web 1.0. El diseo de este tipo de sitios estticos, stticos, se limitaba a la edicin de etiquetas, y predominaban las imgenes GIF, los formularios va email y en su conjunto componan sitios web que a menudo eran pginas personales y otros servicios de contenidos en los que no sola interactuar directamente directa el usuario sino un administrador que iba creando sus contenidos mediante la edicin manual de cdigo HTML. Progresivamente aparecieron las pginas web dinmicas en las que una simple consulta o insercin en la base de datos le permitan al administrador administrador modificar fcilmente el contenido de sus pginas. stas han sido conocidas menos popularmente como Web 1.5. Pero la verdadera revolucin de internet lleg con la creacin de espacios dinmicos en los que el usuario era el protagonista de la informacin, informacin, permitindole la posibilidad de crear, modificar y borrar contenidos. ste es el principio en el que se sustenta la Web 2.01 tal y como la present por primera vez Tim OReilly en una conferencia en el ao 2004. Esta actualizacin est relacionada con con un fenmeno social en el que el predomina el aporte del usuario, nutrindose as de la inteligencia colectiva. El creador de este concepto incluso llega a comparar la Web 1.0 con la 2.0 de forma anloga a como compararamos las webs personales con los blogs, la publicacin con la participacin, los sistemas de gestin de contenidos con las wikis o la Enciclopedia Britnica con la Wikipedia. Actualmente existen multitud de aplicaciones con estas caractersticas como pueden ser wikis, blogs y dems servicios ios de red donde compartir todo tipo de informacin multimedia. Igualmente existen muchos mbitos profesionales en los que esta evolucin puede incorporarse en el da a da, como pueden ser las aplicaciones educativas con una intranet donde el profesorado profesorad y el alumnado comparten material didctico y conocimientos, o mdicas, donde aplicaciones como Google Health permiten organizar informacin mdica con la que interacta el propio usuario, aunque esta ltima con la privacidad necesaria. Siguiendo el desarrollo rrollo que est experimentando constantemente la red, podemos observar caractersticas que van ms all de la simple interaccin de usuario con las aplicaciones web.
Nuevos frentes se estn abriendo en los que la interoperabilidad de la red con procesadores o agentes inteligentes permiten procesar de forma eficiente multitud de informacin. Siguiendo la dinmica del proceso evolutivo de internet surge la Web 3.0, en la cual se extiende el concepto de web semntica, en el que se le dota de significado a los elementos de cualquier web para que sea ms fcil y directa su localizacin, tambin se apuesta por evolucionar en el campo de las 3D y en el de la inteligencia artificial. ificial. Grandes compaas como Google estn aportando tecnologa que permite directamente trabajar en este aspecto, permitiendo la creacin de modelos predictivos que utilicen tcnicas de inteligencia artificial va web. En este entorno de comunicacin n en el que ha evolucionado la red, aparecen los servicios web, que son sistemas de informacin que permiten comunicar clientes con cualquier tipo de informacin, independientemente del lenguaje que vaya a utilizar el cliente para el acceso.
Definicin de e Servicios Web

Un servicio Web es un servicio, con un interfaz definido y conocido, al que se puede acceder a travs de Internet. Se puede definir los servicios web como un conjunto de servicios que proporcionan mecanismos de comunicacin estndares entre re 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, adoptando el uso de protocolos y estndares abiertos. El World Wide Web Consortium (W3C) y la Organization for the Advancement of Structured Information Standards son las organizaciones responsables de la estandarizacin y la arquitectura de los servicios Web. Igual que una pgina Web est definida por un URL (Uniform Resource Locator), un servicio Web est definido por un URI (Uniform Resource Identification) y por su interfaz, a travs del cual se puede acceder a l, ocultando as los detalles de su implementacin. Estos servicios pretenden ser independientes del hardware y software utilizado para acceder a ellos. Las aplicaciones Web se convierten en clientes que integran servicios Web procedentes proced de diferentes proveedores de manera que puede ofrecerse al usuario una funcionalidad ms completa. Con el desarrollo que ha tenido Internet y el avance de componentes software se puede llegar a construir grandes aplicaciones distribuidas que pueden pueden residir en uno o ms servidores y poder as reducir el software cliente. De esta forma, las empresas pueden ofrecer a sus usuarios tener un acceso sencillo y casi universal a sus aplicaciones sin tener que preocuparse de los gastos derivados del mantenimiento. mantenimiento. Los servicios Web normalmente utilizan como base para la creacin de sus mensajes de intercambio XML (Extensible Markup Language), que es un estndar para la descripcin de datos (metadatos). XML tiene la propiedad de utilizar una gramtica sencilla sencilla y compatible con la mayor parte de los sistemas conectados a la red. Esta propiedad permite a los servicios Web poder ser accesible desde diferentes plataformas software o sistemas hardware.
Protocolos de Servicios Web

La comunicacin entre los servicios ervicios Web y las aplicaciones se realiza mediante protocolos que pueden clasificarse en 4 tipos: x Servicios de transporte:
Son los protocolos de ms bajo nivel que codifican la informacin independientemente de su formato, y que pueden ser comunes a otros s servicios como HTTP, FTP, SMTP o utilizar alguno especfico como BEEP (Block Extensible Exchange Protocol). x Servicios de mensajera
Especifican como se deben codificar los mensajes que contienen los datos que se intercambian. Los ms utilizados son SOAP P (Protocolo Simple de Acceso a Objetos) y XML-RPC XML RPC (Remote Procedure Call mediante XML). Mientras ste ltimo utiliza HTTP como protocolo de transporte, SOAP puede funcionar con varios (SMTP, FTP, HTTP, etc.). Estos protocolos utilizan XML como base para el intercambio de informacin. x Servicios de descripcin
Para que una aplicacin sepa de manera automtica que formato usar para comunicarse con un servicio, ste ha de especificarse. Esto se hace mediante WSDL DL (Web Services Description Language). Mediante dicho protocolo se obtiene la direccin y la interfaz de un servicio. x Servicios de descubrimiento
Es la capa ms alta. Permite llevar WSDL ms all, describiendo productos, la empresa y cmo se realizan las transacciones. UDDI (Universal Description, Discovery and Integration) es el protocolo que se utiliza para buscar servicios Web y obtener informacin de cmo acceder a ellos. La arquitectura de los servicios web incluye distintas tecnologas y interrelacionados cuya interpretacin y desarrollo no es nico. capas de protocolos
Los estndares de mayor importancia para la comprensin de la arquitectura de Servicios Web son XML, SOAP y WSDL. Dichos estndares conforman toda la tecnologa asociada a cualquier cualquier servicio, independientemente del lenguaje en el que se haya desarrollado dicho servicio.
Aqu tenemos una imagen que nos muestra los diferentes bloques que conforman un Web Service:
Servicios XML
XML (eXtensible Markup Language) es un metalenguaje extensible de etiquetas desarrollado por el W3C cuyo propsito es la definicin de datos contenidos en un documento. La palabra Extensible en su definicin hace referencia al hecho de que XML no es un lenguaje en particular, sino un estndar para la definicin definicin de nuevos lenguajes que se utilizarn para el intercambio de informacin entre diferentes plataformas, de forma que el desarrollador puede definir y extender sus propias etiquetas y crear su propio lenguaje para adaptarse a las necesidades de la aplicacin. a Existen dos tipos de documentos XML: aquellos que contienen la informacin propiamente dicha y los documentos de especificacin del lenguaje.
Documentos de Datos XML

El componente principal de los documentos XML son las etiquetas representadas representa en el formato y entre las cuales se encuentran los datos. Los tres principales tipos de elementos etiqueta son diferenciables: x Elementos que contienen otros elementos anidados, como
<Informacion> <Nombre> </Informacion>
Elementos que contienen cadenas de datos, como por ejemplo informacin sobre el nombre de la informacin.
que contiene la
<Informacion> <Nombre>dato</Nombre> </Informacion> x Elementos que estn vacos pero que aportan informacin con su presencia o con sus s atributos, como en el ejemplo con el atributo id del nodo informacin:
<Informacion id=identificador> <Nombre>dato</Nombre> </Informacion> Los documentos XML han de ser vlidos y bien formados, es decir, deben ajustarse a las reglas semnticas definidas as por su XML Schema o su DTD correspondiente y han de ajustarse a las normas de sintaxis XML. Debemos diferenciar entre un documento XML bien formado y un documento XML vlido. Un documento xml bien formado es un documento que mantiene las reglas sintcticas sintcti del lenguaje xml, diferenciando mayculas y minsculas en su sintaxis, por ejemplo. Un documento xml vlido es un documento que mantiene una estructura asociada a otro tipo de documento que indicar los nodos que representar o el nmero de elementos que q contendr cada nodo. A dicho documento asociado se le conoce por XML Schema o DTD. Los servicios Web tienen una estructura de documento XML y envan la informacin al clientecliente consumidor mediante SOAP, que es un esquema. Por ejemplo, imaginemos que tenemos mos la siguiente clase que representa un servicio web en java: package paquetees; import javax.jws.WebMethod; import javax.jws.WebService; @WebService() public class NewWebService { /** * Web service operation */ @WebMethod(operationName = "operation") public Integer operation() { int numero = 20; return numero; } } Cuando hagamos una solicitud en el cliente, veremos las operaciones devueltas en formato XML:
Como podemos comprobar en la imagen, uno de los bloques ms importantes dentro de la arquitectura de los Web Services es la arquitectura SOAP. Las Arquitecturas Orientadas a Servicios, estn motivadas por la creciente necesidad de los negocios de responder con rapidez a los cambios en el entorno comercial en que se desenvuelven. Esto los lleva a tener que cambiar sus sistemas tecnolgicos con esa misma rapidez y para lograrlo es necesario que los componentes de esta infraestructura, sean tan reutilizables y poco interdependientes que permitan una rpida reestructuracin de los mismos. Los elementos bsicos que conforman SOA son: x x x Proveedores de Servicios Consumidores de Servicios Bus Empresarial de Servicios
Adems podemos definir otros elementos participantes dentro de una arquitectura arquitect SOA tales como:
Cliente
Se entiende Cliente como el componente que invoca un servicio provisto por un proveedor.
Concepto de servicio
Un servicio es una unidad de trabajo realizada por un componente de software a fin de conseguir un resultado especfico. El servicio debe ser alcanzable por parte de los consumidores a travs de una interfaz programtica.
Utilizacin de web services

La arquitectura orientada a servicios, no especifica necesariamente que los servicios deben ser brindados a travs de un protocolo otocolo especfico. Los Web Services son en realidad un conjunto de estndares que definen un protocolo de invocacin remota de servicios, basados en HTML y XML. Si bien, son tambin un mecanismo adecuado y en muchos casos recomendable para implementar servicios no son el nico. Es importante que las arquitecturas orientadas a servicios soporten mltiples protocolos a fin de cumplir al mximo su visin de brindar un modelo de integracin para toda la plataforma tecnolgica.
El fichero WSDL (Web Services Description Language), en formato XML, describe al ordenador que lo consulta, la forma de comunicacin, es decir, los requisitos del protocolo y los formatos de los mensajes necesarios para interactuar con los servicios listados lis en su catlogo. Del mismo modo, al igual que en la Web tenemos buscadores como Google, que nos llevan a las pginas que nos interesan, existe el concepto equivalente a nivel de Servicios Web, que es UDDI (Universal Description Discovery Integration). Integration) UDDI es un repositorio en lnea que se puede utilizar desde las aplicaciones para descubrir de forma dinmica otros servicios en lnea, todos ellos perfectamente integrados en una interfaz XML simple. La funcionalidad de los protocolos y lenguajes empleados empleados en estos servicios es la siguiente: x x x x XML (eXtensible Markup Language): Un servicio Web es una aplicacin Web creada en XML. WSDL (Web Services Definition Service): Este protocolo se encarga de describir el servicio Web cuando es publicado. Es el lenguaje XML que los proveedores emplean para describir sus servicios Web. SOAP (Simple Object Access Protocol): Permite que programas que corren en diferentes sistemas operativos se comuniquen. La comunicacin entre las diferentes entidades se realiza mediante med mensajes que son rutados en un sobre SOAP. UDDI (Universal Description Discovery and Integration): Este protocolo permite la publicacin y localizacin de los servicios. Los directorios UDDI actan como una gua telefnica de servicios Web.
Ventajas e inconvenientes de los servicios Web Ventajas

Los servicios Web en todo su conjunto ofrecen las siguientes ventajas tecnolgicas que han provocado que hayan tenido mucho xito: Interoperabilidad Cualquier servicio Web puede interactuar con cualquier otro servicio serv Web. El protocolo SOAP permite que cualquier servicio pueda ser ofrecido o utilizado independientemente del lenguaje o ambiente en que se haya desarrollado. Omnipresencia Los servicios Web se comunican utilizando HTTP y XML. Cualquier dispositivo que trabaje con stas tecnologas puede tanto ser un cliente del servicio como servidor en algunas circunstancias. Mnimo Esfuerzo Los conceptos detrs de los servicios de Web son fciles de comprender y se ofrecen Herramientas de Desarrollo especficas por [WebLogic], Sun, Apache los que permiten a los programadores implementar rpidamente servicios Web con SOAP. Uno de los problemas a solucionar para los servicios Web es la gestin de sistemas altamente distribuidos ya que algunos servicios Web delegan delegan funcionalidades a otras de ms bajo nivel.
Seguridad de los Servicios Web

Las expectativas alrededor de la tecnologa de servicios Web son grandes, tambin puede tener sus riesgos ya que los servicios Web hacen uso de las mismas tecnologas que han sido s atacadas en tantas ocasiones. Si los usamos, la seguridad de una empresa puede verse comprometida. La ausencia de tcnicas de seguridad estndar es un obstculo para la adopcin de la tecnologa. La calidad de un Servicio Web es un parmetro que no est demasiado claro, pero cuya medida es fundamental a la hora de desarrollar un servicio estable y maduro. Esta tecnologa est en desarrollo y la mayora de los protocolos recomendaciones a seguir. en los que se basa, son
Actualmente, los servicios Web estn siendo ampliamente aceptados por las empresas para el desarrollo de software de uso interno. De esta forma, los servicios pueden implementar toda su funcionalidad y permanecer seguros tras el firewall de la empresa. Los desarrollos actuales no ayudan a la cooperacin entre las empresas ya que no hay ningn estndar establecido sobre las tcnicas de seguridad. Debido a la tecnologa que es usada por los servicios Web, y en concreto, al uso de SOAP, las tcnicas de seguridad eguridad convencionales que se han venido usando en Internet, ya no son suficientes. Con SOAP, cada mensaje simple que se intercambia realiza mltiples saltos y es enrutado a travs de numerosos puntos antes de que alcance su destino final. Es por ello que los servicios Web necesitan tecnologas que protejan los mensajes desde el principio hasta el final. Existen un conjunto de tcnicas que se pueden usar para garantizar la seguridad a nivel de mensaje SOAP. x x x Cifrado de XML: Evita que los datos se vean expuestos a lo largo de su recorrido. Firma Digital XML: Asocia los datos del mensaje al usuario que emite la firma, de forma que este usuario es el nico que puede modificar dichos datos. SAML y la Autorizacin: SAML (Security Assertion Mark-up Mark Language) age) hace posible que los servicios Web intercambien informacin de autentificacin y autorizacin entre ellos, de modo que un servicio Web confe en un usuario autentificado por otro servicio Web. Validacin de datos: Permite que los servicios Web reciban reciban datos dentro de los rangos esperados. Ttambin existen tcnicas que permiten mantener la seguridad a otros niveles. La seguridad en UDDI permite autentificar todas las entidades que toman parte en la publicacin de un servicio Web: proveedor, agente agente y consumidor del servicio. De esta forma, nadie podr registrar servicios en el papel de un proveedor o hacer uso de ellos sin contar con los permisos adecuados.
x x x x
Ver Video: Visualizar los bloques de un Servicio Web, en el Mdulo 7. Unidad 1, en la plataforma elearning.
Laboratorio: Servicio Web DNI Objetivo

Comprender el funcionamiento de los servicios Web dentro de la tecnologa de Java.
Enunciado
Vamos a realizar un Servicio Web que nos devolver la letra del correspondiente a un DNI que enviaremos como parmetro. Comenzaremos crendonos un nuevo proyecto Web en NetBeans.
.
Llamaremos al proyecto ProyectoServicios
Utilizaremos el servidor de aplicaciones GlassFish y no utilizaremos Frameworks. Sobre el proyecto, vamos a agregar un nuevo Servicio Web.
Lo llamaremos ServicioDNI
Vamos a agregar una nueva operacin:
Aadimos un mtodo llamado getLetraNif() que recibir el nmero del DNI y devolver la letra correspondiente a dicho DNI.
Para conseguir averiguar la letra del NIF respecto respecto a su nmero debemos seguir las siguientes instrucciones: La frmula para calcular la letra del nmero del DNI se recupera de la siguiente forma: (n DNI - ((n DNI / 23) * 23)) Se mira la equivalencia en la siguiente tabla: tabla
0=T 1=R 2=W 3=A
4=G 5=M 6=Y 7=F
8=P 9=D 10=X 11=B
12=N 13=J 14=Z 15=S
16=Q 17=V 18=H 19=L
20=C 21=K 22=E 23=T

Para ello
Ahora vamos a implementar la lgica para poder realizar las acciones del ServicioDNI. implementaremos el mtodo de la siguiente forma: package paquete; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService;
@WebService() public class ServicioDNI { /** * Web service operation */ @WebMethod(operationName = "getLetraNif") public String getLetraNif(@WebParam(name getLetraNif(@WebPar = "numerodni")
int numerodni) { String letrasdni = "TRWAGMYFPDXBNJZSQVHLCKET"; int resultado = (numerodni - ((numerodni / 23) * 23)); Character letra = letrasdni.charAt(resultado); return letra.toString(); } } Una vez que lo tengamos, ser el momento de probar el servicio y su funcionamiento:
Veremos la pantalla de presentacin del servicio:
Si invocamos el servicio, comprobaremos que el dato de la letra es devuelto:
Unidad 2: Analizando la tecnologa y plataforma de servicios Web

Objetivos
x x Conocer la arquitectura de los Servicios Web en diferentes entornos de trabajo. Comparar las arquitecturas de los Servicios Web en los lenguajes ms potentes del mercado.
Introduccin
Como hemos podido comprobar, los servicios Web no son una tecnologa nica del lenguaje java J2EE, a pesar de encontrarnos dentro de dicho entorno. Cuando utilizamos servicios web, el propsito de dichos servicios es encontrar una arquitectura que sea capaz de comunicarse entre diferentes plataformas, independientemente del lenguaje de programacin en el que se hayan creado los servicios. La tecnologa que permite que los servicios web se comuniquen entre diversos lenguajes tiene que ver con el formato de los datos atos enviados en el servicio y con el esquema generado para dicho servicio web. Mediante los esquemas SOAP cualquier lenguaje es capaz de entender los objetos y mtodos que sern devueltos en un servicio web. Lo que veremos en este captulo es la comparativa comparativa entre las dos grandes plataformas sobre las que se pueden desarrollar los servicios web, Visual Studio Net y Java.
Arquitectura SUN Web Services

En la actualidad Sun ofrece tres ediciones edi de la plataforma Java 2. Cada una de ellas tiene una finalidad. Estas plataformas ormas son slo especificaciones, lo que quiere decir que no son productos terminados listos para usar, sino que son documentos que definen cmo deben ser esos productos, cmo deben comportarse y qu requisititos deben cumplir. A los productos que cumplen las especificaciones se les llama implementaciones. Las tres ediciones de la plataforma Java 2 son: x x x Standard Edition (J2SE) Enterprise Edition (J2EE) Micro Edition (J2ME)
La Standard Edition es la plataforma bsica y ms extendida, la que se suele conocer como Java Development Kit o JDK. Con ella se pueden hacer applets y cualquier clase de aplicacin no distribuida. La Enterprise Edition recubre la Standard Edition aadindole aadindole una serie de APIs que permiten crear aplicaciones de empresa mpresa en el lado del servidor, es decir, aplicaciones para ser utilizadas en Internet.
La Micro Edition ofrece un entorno de ejecucin altamente optimizado para todo tipo de dispositivos con recursos rsos limitados, como mviles, PDAs, etc. Segn Sun MicroSistem J2EE (Java 2 Platform Entreprise Edition) es un conjunto de estndares y especificaciones para el desarrollo de aplicaciones empresariales basado en la tecnologa Java. Las llamadas aplicaciones es empresariales son aplicaciones del lado del servidor, aplicaciones grandes y complejas que proporcionan servicios a travs de Internet o redes privadas. J2EE proporciona un modelo de programacin que consiste en un conjunto de APIs y que dirige la manera de construir aplicaciones. La idea principal de J2EE es la de proveer un estndar simple y unificado para aplicaciones distribuidas a travs de un modelo de aplicaciones basado en componentes. Para la construccin de un servicio Web bajo la arquitectura arquitectura J2EE, deberemos utilizar Java como lenguaje de programacin. El modelo que sigue J2EE es el siguiente: La aplicacin est asociada a un conjunto de clases con las cuales podemos definir objetos. Gracias a estos objetos se ocultan al programador las dificultades dificultades de desarrollar una aplicacin capaz de responder y aceptar peticiones a travs de la red, as como la interpretacin de estas peticiones, su envo y recepcin. Este conjunto de clases se obtiene como paquete complementario al conjunto de clases clase que en principio ofrece directamente java para implementar y consumir servicios Web. La funcionalidad de la aplicacin en si es construida utilizando componentes EJB (Enterprise JavaBeans). Estos componentes proporcionan acceso a base de datos mediante JDBC (Java DataBase Connectivity) o SQL/J (Lenguaje de consultas para bases de datos), datos), acceso a otros sistemas gracias a JCA (Java Conector Architecture) o acceso a servicios Web utilizando JAX (Java APIs for XML). En general, la lgica de la aplicacin est construida gracias al conjunto de clases que proporciona el lenguaje Java. Cualquier aplicacin puede conectarse a una aplicacin J2EE utilizando la tecnologa de servicios Web (por ejemplo XML). Un objeto es capaz de recibir peticiones y contestar a estas, utilizando directamente JAX APIs para ejecutar las operaciones. En definitiva todas las clases y aplicaciones Java pueden convertirse convertirse en servicios Web utilizando Java API for XML. J2EE define un estndar para el desarrollo de aplicaciones empresariales empresariales y simplifica las aplicaciones. Dichas aplicaciones se basan en componentes modulares y estandarizados, dando un completo conjunto de servicios a estos componentes, y manejando muchas de las funciones de la aplicacin de forma automtica, sin necesidad ecesidad de una programacin compleja. Como hemos comentado, las aplicaciones empresariales para web de la tecnologa Java estn compuestas por los siguientes componentes: Las aplicaciones J2EE estn formadas por los siguientes componentes: x x x Componentes Clientes Clientes Web Applets
x x x x x x x x x
Aplicaciones Cliente Componentes Web Servlets Pginas JavaServer Pages (JSP) Componentes de Negocios Entreprise Java Beans Session Beans Entity Beans Message Driven Bean
Arquitectura NET Web Services

De acuerdo con la definicin de Microsoft, Microsoft Visual Studio Net es una plataforma que comprende servidores, clientes y servicios. Desde el punto de vista de la arquitectura de servicios web para esta plataforma, net utiliza una implementacin basada en estndares abiertos abier como SOAP o WSDL. Desde el punto de vista del programador, el entorno .NET ofrece un solo entorno de desarrollo para todos los lenguajes que soporta (Visual Basic, C++, C#, Visual J#, Fortran, Cobol, etc). Esta plataforma utiliza los Servicios Web como como un medio para poder comunicar distintas tecnologas. Permite conectar distintos sistemas operativos, dispositivos fsicos, informacin y usuarios. La idea central de .NET es la de servicio final a los clientes, y ms concretamente software como servicio servi y de cmo construir, instalar, consumir, integrar o agregar estos servicios para que puedan ser accedidos mediante Internet. La plataforma .NET utiliza Internet y su capacidad de distribucin para que los usuarios accedan desde cualquier dispositivo, en cualquier sistema operativo y lugar a la funcionalidad que los servicios Web proveen. NET Framework es la parte ms importante de la plataforma .NET. Incluye COM+, un.entorno de ejecucin comn, un compilador JIT, y un conjunto de libreras de sistema sistem que dan acceso a un amplio conjunto de servicios .NET. Los componentes ms importantes de la arquitectura NET son: x CLR (Common Language Runtime)
x x x x
El conjunto de clases del .NET Framework ASP.NET Remoting Windows Forms
La estrategia .Net es innovadora respecto a los productos anteriores de Microsoft, en el sentido de que no compila aplicaciones en cdigo nativo, es decir, no compila aplicaciones en cdigo especfico. La compilacin, al igual que sucede con Java, se realiza realiza en dos pasos sucesivos. El cdigo escrito por el programador se compila en MSIL (Microsoft Intermediate Language), del mismo modo que las instrucciones en Java se convierten en bytecodes. Despus el CLR (Common Language Runtime) de Microsoft compila en tiempo de ejecucin las aplicaciones en cdigo nativo de la plataforma. Esto se realiza mediante el compilador JIT (Just in Time). El CLR tambin revisa el cdigo, verificando la seguridad del mismo y recolectando los objetos para los cuales no existe ya ninguna referencia (recoleccin de basura), adems de gestionar las excepciones entre otras tareas. o En principio, cualquier programa escrito en MSIL puede ejecutarse en cualquier sistema operativo donde funcione un CLR, aunque en realidad, las aplicaciones aplicaciones para la plataforma Net estn creadas para sistemas operativos de Microsoft.
NET Framework es la base de cualquier desarrollador de .NET.
Es un conjunto de clases, interfaces y tipos que simplifican y optimizan el desarrollo de aplicaciones .NET, .NET adems dems de proporcionar acceso a la funcionalidad del sistema. ASP.NET es la parte de .NET dedicada al desarrollo Web. A travs del servidor Web IIS (Internet Information Services) las aplicaciones ASP.NET se ejecutarn bajo el CLR pudindose usar el conjunto unto de clases del NET Framework para desarrollarlas, obteniendo as una versatilidad idad y una potencia nunca antes conseguida en las aplicaciones asp. NET Remoting nos permite tener objetos en mquinas remotas e invocarlos desde otras.mquinas. La tecnologa Windows Forms, permite desarrollar clientes grficos independientes al navegador. Otra innovacin de .NET es el lenguaje C# (C Sharp) incluido en esta plataforma por primera vez en la versin 2003. Es un lenguaje orientado a objetos fuertemente tipado, tipado, diseado por Microsoft para obtener un elevado rendimiento con una relativa simplicidad del lenguaje. C# juega un importante papel en .NET porque ha sido diseado para trabajar de forma ptima con esta plataforma y ciertas caractersticas de .NET se implementaron implementaron pensando en que su rendimiento fuera ptimo con C# (de hecho, algunas bibliotecas de .NET como Collection, XML, ADO+, ASP+, GDI+ y otras fueron escritas en C#). En esta tabla podemos observar a comparativa entre las tecnologas de Sun y Microsoft Micro que permiten poder obtener una arquitectura de comunicacin estndar entre los servicios web.
Caractersticas Tipos de tecnologa Empresas que lo ofrecen
.NET Producto Microsoft
J2EE Estndar Existen mltiples proveedores para ofrecer la tecnologa de J2EE, no existe una empresa oficial sobre la que implementar las
Libreras de desarrollo Intrprete
NET Framework SDK CLR (Common Language Runtime) ASP .NET .NET Components Managed ADO .NET, LINQ SOAP, WSDL, UDDI, Windows Communication
caractersticas de Sun. Java Core API JRE (Java Runtime)
Pginas dinmicas Componentes Acceso a bases de datos Servicios Web
Servlets, JSP EJB JDBC, SQL/J SOAP, WSDL, UDDI, RestFul
Foundation Interfaces grficas Herramientas de programacin Transacciones distribuidas Servicios de directorios Librera de encolado y mensajes Lenguajes utilizados Lenguaje intermedio Windows Forms y Web Forms Visual Studio .NET AWT y Java Swing Depende del fabricante, las ms conocidas son NetBeans y Eclipse. JTS JNDI JMS Java Bytecodes
MS DTC ADSI MSMQ C#, Visual Basic, C++otros IL
Comparacin en las arquitecturas de Servicios Web

El propsito tanto de J2EE como de la plataforma .NET es facilitar y simplificar el desarrollo de aplicaciones empresariales o corporativas. Las pginas JSP (Java Server Pages) son muy similares a ASP (Active Server Pages) o a su descendiente ASP .Net, y los EJB (Enterprise JavaBeans) son muy similares a los COM/COM+ de Microsoft. Los servidores de aplicaciones J2EE y .Net proporcionan un modelo de acceso de componentes a datos y de lgica del negocio, separados por una capa intermedia de presentacin implementada im mediante ASP .Net o Servlets si hablamos de la tecnologa J2EE. J2EE Visual Basic .Net y C# son lenguajes orientados a objetos, al igual que Java, y en su diseo ha tenido mucha importancia la existencia de Internet. Desde la perspectiva de los desarrolladores, esarrolladores, J2EE y .Net proporcionan las herramientas para crear Servicios Web. Al usar .Net una compilacin en dos pasos le permitir tericamente proporcionar entornos de ejecucin para diferentes plataformas de forma similar s a Java y sus JREs y SDKs, Ks, aunque Java soporta cualquier plataforma y Net funciona bajo sistemas operativos Microsoft. Una ventaja muy importante del entorno .Net frente a J2EE es la posibilidad de emplear mltiples lenguajes de programacin, mientras que J2EE slo trabaja con Java. La realidad es que la diversidad de lenguajes es obligatoria por la misma variedad de las necesidades de los programadores. Un lenguaje moderno y orientado a objetos como Java puede resultar inadecuado a la hora de abordar problemas que involucren clculos matemticos masivos y complejos, mientras que esos mismos clculos pueden ser abordados mucho ms adecuadamente con un lenguaje primitivo como Fortran.
Por otro lado, .Net posibilita as que programadores de terceros lenguajes pasen a esta plataforma pla reduciendo el tiempo de aprendizaje y entrenamiento. Las herramientas de desarrollo incluidas por Microsoft en Visual Studio .Net son mucho ms simples, intuitivas y sencillas de manejar que las herramientas de desarrollo equivalentes en J2EE suministradas sum por otras empresas (entre ellas la propia Sun). Cualquier programador medio-avanzado avanzado se manejar rpidamente con la programacin del interface de usuario en Visual Studio .Net, al igual que suceda con versiones anteriores de Visual Studio. C# es un lenguaje interesante, fcil de aprender por los programadores de Java (de hecho, Microsoft ofrece un conversor de Java a C#), que en caso de estandarizarse podra resultar un lenguaje muy conveniente para ciertas tareas de programacin en diferentes diferent plataformas. Las implementaciones de J2EE pueden adquirirse a distintas compaas, mientras que .Net slo a Microsoft. El hecho de que haya distintas organizaciones implementando J2EE ofrece mayor variedad para los usuarios finales y permite la existencia de una cierta competencia entre ellas para obtener mejores productos que no existe te en el caso de Microsoft y Visual Studio .Net. Debido al proceso evolutivo de los productos de Microsoft, y en muchos casos, por motivos de compatibilidad, la seguridad guridad frente a virus informticos de los productos de Microsoft es menor que los basados en Java, pues desde un comienzo Java se fundament en un estricto modelo de seguridad. Como se ha escrito ya, las aplicaciones Java pueden correr en una amplia gama gam de sistemas operativos (desde sistemas empresariales como Windows 2000, OS/390, Solaris, HP-UX, HP IRIX u otras versiones de Unix hasta en sistemas orientados ms a ordenadores personales como Mac OS, Windows 9x Linux, y en sistemas operativos para dispositivos dispositivos mviles) y de arquitecturas hardware. Hasta la fecha, .Net corre solamente sobre sistemas operativos de Microsoft (aunque esta situacin podra cambiar en el futuro), siendo J2EE el nico entorno de desarrollo que ofrece una independencia real de la plataforma. La tecnologa Java es una tecnologa abierta, en el sentido de que el cdigo de la plataforma completa puede ser obtenido, revisado y estudiado por cualquiera que est interesado, y se basa en gran parte en estndares de organizaciones de normalizacin y estndares empresariales. Esto posibilita que los desarrolladores puedan conocer y entender completamente cmo hace las cosas Java y aprovecharlo para sus aplicaciones. Por otro lado, al basarse en estndares empresariales, simplifica la integracin con productos de mltiples compaas. En contraposicin, solo el cdigo fuente del lenguaje C# de la plataforma .Net ha sido abierto al pblico general. Aunque Java fue creado originalmente por Sun MicroSystems, lo cierto es que J2EE es ahora ahor el producto de la colaboracin de muchas empresas y organizaciones de todo tipo. La plataforma .Net es el producto de una sola compaa, que aunque haya implementado algunos estndares en .Net y est intentando conseguir que ciertas tecnologas se conviertan conv en estndares "oficiales", no puede tener el mismo consenso que J2EE, J2EE sobre todo porque casi todo su cdigo no es pblico. La tecnologa Java goza oza ya de una cierta veterana, J2EE y ha probado su eficacia en muchos entornos y situaciones empresariales ales distintas, mientras que .Net ha visto oficialmente la luz de una forma relativamente reciente. Podemos perfectamente comparar un servicio web creado bajo la plataforma Visual Studio y un Servicio web creado bajo la plataforma J2EE.
Al compararlos, veremos emos que los esquemas SOAP son los mismos y que la arquitectura de comunicacin es la misma. Si visualizamos el cdigo de un servicio web creado en Net, veremos lo siguiente: using System; using System.Collections.Generic; using System.Linq; using System.Web; using System.Web.Services; namespace WebService1 { /// <summary> /// Descripcin breve de Service1 /// </summary> [WebService(Namespace = "http://tempuri.org/")] [WebServiceBinding(ConformsTo = WsiProfiles.BasicProfile1_1)] [System.ComponentModel.ToolboxItem(false)] // Para permitir que se llame a este servicio Web desde un script, usando ASP.NET AJAX, quite la marca de_ comentario de la lnea siguiente. // [System.Web.Script.Services.ScriptService] public class Service1 : System.Web.Services.WebService { [WebMethod] public string HelloWorld() { return "Hello World"; } } }
Cuando probemos el servicio, veremos una pantalla en el explorador web y que nos mostrar los mtodos que utiliza dicho servicio.
Como podremos comprobar, los servicios creados en la plataforma de Visual Studio utilizan la extensin de archivo asmx y no vemos el esquema WSDL. Si queremos visualizar el esquema WSDL bastara con con escribir lo siguiente en el explorador web para poder representarlo. http://localhost:7722/Service1.asmx?wsdl Este es el esquema resultante de un servicio web en NET:
Si invocamos el mtodo HelloWorld del servicio, veremos el resultado expresados en datos XML.
Ahora vamos a visualizar la arquitectura de un servicio web creado en Java. Realizaremos el mismo tipo de servicio con un mtodo tambin llamado HelloWorld y que devolver un mensaje del tipo String. package paquete; import javax.jws.WebService; import javax.jws.WebMethod;
import javax.jws.WebParam; @WebService(serviceName = "NewWebService1") public class NewWebService1 { /** This is a sample web service operation */ @WebMethod(operationName = "helloworld") public String helloworld(@WebParam(name = "name") String txt) { return "Hello " + txt + " !"; } }
Cuando probemos el servicio, (como en net) veremos veremos una pantalla en el explorador web y que nos mostrar los mtodos que utiliza dicho servicio.
La informacin del esquema WSDL ser la misma que en una aplicacin realizada con Visual Studio. La extensin para un Servicio Web creado en Java ser wsdl.
Si invocamos el mtodo, la visualizacin es diferente, pero el XML generado en la salida ser el mismo que un servicio web realizado en otro lenguaje.
Podemos visualizar la solicitud SOAP
Y podremos visualizar la respuesta que nos ofrece el servicio. servici
Ver Video: Arquitectura Web Services, en el Modulo 7. Unidad 2, en la plataforma elearning.
Unidad 3: Aplicando XML

Objetivos
x x x Conocer los conceptos de los documentos XML. Analizar las caractersticas de XML con documentos bien formados y su validacin. Comprender la utilizacin de documentos XML y Schemas para la representacin y estructura de datos dentro de los Servicios Web.
Introduccin
XML significa eXtensible Markup Language, o lenguaje de anotacin extensible. Ya conocemos el lenguaje e HTML (hypertext markup language), lenguaje de anotacin para pgina webs que permite navegacin tipo hipertexto, sin embargo, XML no es slo un lenguaje, es una forma de especificar lenguajes, de ah lo de extensible. Todo lenguaje que se exprese de una forma determinada puede ser XML. Por lo tanto, XML no es un lenguaje para hacer mejores pginas web, sino un lenguaje para informacin auto-descrita, auto o al menos, auto-descrita descrita si las etiquetas estn correctamente creadas. XML se inici como un subconjunto o de SGML (Structured Generalized Markup Language), un standard ISO para documentos estructurados que es sumamente complejo y que se utilizaba para poder servir documentos en internet. XML es una implementacin de SGML simplificado, de manera que una aplicacin apli no necesita comprender SGML completo para interpretar un documento, sino slo el subconjunto que se defina. Los editores SGML, sin embargo, pueden comprender XML. No debemos pensar que XML se utiliza para la creacin de pginas web, o algo parecido a las pginas web. XML es un lenguaje que cambia el paradigma de programacin, que como ya sabemos, est basada en funciones u objetos, y dicha programacin utiliza los documentos para representar la informacin. XML se puede utilizar para cambiar totalmente totalmente el paradigma de publicacin de informacin. Podemos pensar en un programa que recibe unas entradas y produce unas salidas, se envia un documento que genera otro documento, o bien programas que toman documentos y producen otros documentos. Por eso, en general, exceptuando los entornos de servicios web, lo normal es que el documento XML se use en el servidor, y se sirva otro tipo de documentos traducidos a HTML, por ejemplo, que se obtienen a base de una serie de transformaciones. Precisamente, todo este planteamiento hace que los documentos XML se usen dentro de entornos de aplicaciones. Este entorno de aplicaciones permite publicar documentos XML, que, antes de ser enviados al cliente, sufrirn una serie de transformaciones para adaptarlo a los requisitos requisitos del entorno. Algunos ejemplos de entorno de aplicaciones son el Cocoon, un entorno basado en Java libre, que permite no slo publicar pginas XML, sino tambin incluir programas dentro de las pginas (XSP). No se caracteriza por su velocidad ni amigabilidad, pero es excelente como entorno de desarrollo. Otra alternativa gratuita es el AxKit, escrito en Perl.
Como alternativas de pago estn el Bea Weblogic y el IBM WebSphere Transcoding Publisher. Podemos incluir multitud de ejemplos basados en otros lenguajes tales como Krysalis, un entorno de publicacin basado en PHP, que incluye facilidades para ser usado a travs del protocolo SOAP, un protocolo de acceso remoto a documentos basado en XML. Lo ms normal es que la informacin est almacenada en una base de datos, se convierta a XML y luego se transforme para servirlo al cliente. Dentro de estos entornos de desarrollo y/o publicacin, o usndolo de cualquier otra forma, XML tiene gran nmero de aplicaciones. La mayor parte de los portales y sitios de noticias ya estn basados en XML, porque permite estructurar la informacin y luego aplicarle fcilmente transformaciones para su presentacin. Podemos poner como ejemplo las noticias RSS que incluyen incluyen la mayora de medios de publicacin de internet. Es un ejemplo muy claro sobre la utilizacin de XML en internet y la facilidad que puede ofrecer para la tecnologa. RSS es una forma muy sencilla para que podamos recibir, directamente en el ordenador ordenad o en una pgina web online (a travs de un lector RSS) informacin actualizada sobre pginas web, sin necesidad de tener que visitarlas una a una. RSS utiliza una estructura especfica y que no puede variar, por lo tanto, podemos afirmar que cualquier rss tiene la misma serie de etiquetas, pero su contenido cambiar respecto al resto. Esta informacin se actualiza automticamente, sin incluir ninguna accin posterior y sin coste de programacin, simplemente se debe seguir la estructura y cambiar el contenido. contenido. Para recibir las noticias RSS, el portal web deber tener disponible el servicio RSS y podremos utilizar pginas web o lectores Rss. Gracias al RSS, no tendremos que visitar una a una todas las pginas web que ofrezcan informacin que nos interesa para ver si han cambiado los contenidos o visualizar si se ha aadido algn artculo interesante. Estas pginas nos informarn a nosotros a travs de un lector de RSS. Cuando ingresemos una direccin a un lector RSS (o Rss Reader), estaremos automticamente automticame informados sobre todas las novedades que se han producido en todas las pginas web que hayamos dado de alta. Gracias al RSS, tendremos reunidas en un mismo lugar y a un solo clic de distancia, toda la informacin actualizada de las pginas web (Fuentes o canales RSS) que ms nos interesan. Podemos poner como ejemplo cualquier publicacin de prensa via web. visualizar los rss de un peridico digital como El Pais y veremos lo siguiente: Por ejemplo, podemos
Si entramos en cualquiera de los enlaces (documentos (documentos RSS), veremos la informacin con un formato especfico para una pgina web:
En realidad, lo que estamos visualizando es un documento XML con una estructura especfica. Dicha estructura est basada en un esquema que indica como debe formarse dicho dicho documento. Si visualizamos el cdigo fuente, podremos comprobar que tiene una estructura xml: <?xml version="1.0" encoding="iso-8859 8859-1"?> <rss version="2.0"> <channel> <title>Titulo del RSS</title> <link>Vinculo de acceso al RSS</link> <description>Descripcion del conjunto</description> <lastBuildDate>Fecha de actualizacin</lastBuildDate> <language>es-es</language> <image> <url>Vinculo de la imagen</url> <title>Titulo de la imagen</title> </image> <item> <title>Noticia 1</title> <link>Vinculo 2</link>
<description>Descripcion de la noticia</description> <author>Nombre del autor</author> <pubDate>Fecha de publicacin</pubDate> </item> <item> <title>Noticia 2</title> <link>Vinculo 2</link> <description>Descripcion de la noticia</description> <author>Nombre del autor</author> <pubDate>Fecha de publicacin</pubDate> </item> </channel> </rss>
La estructura es la misma para cualquier documento documento rss, por lo tanto, cualquier publicacin de noticias rss tendr los mismos elementos pero con diferente informacin. Gracias a esta estructura, podemos afirmar que todos los documentos rss sern leidos de la misma forma, porque su estructura no cambiar. cambi Si probamos a visualizar cualquier otro artculo RSS, podremos comprobar que tendr la misma estructura, aunque con diferentes noticias. Lo importante de la afirmacin de lo que acabamos de analizar con las noticias rss es su importancia para poder ofrecer recer informacin en un formato accesible y que est compuesto simplemente por etiquetas ilustrativas.
Estructura de documentos XML

XML no tiene un formato cerrado ni un entorno sobre el cual se deba crear. Para editar documentos XML, al igual que para hacerlo cerlo con HTML, se puede hace de dos formas: editndolos como cualquier otro fichero ASCII (el bloc de notas de Windows, por ejemplo), utilizando cualquier editor estructurado como UltraEdit, o bien usar un editor especfico para XML, que entiende las particularidades part del lenguaje y ofrece ayuda en el momento de escribir el documento como puede ser el cierre de etiquetas de jerarquia. Un ejemplo de la estructura de un documento XML sera el siguiente:
En el momento de definir las etiquetas XML, debemos de saber que el lenguaje esw casesensitive, es decir, diferencia maysculas de minsculas en los elementos y en los atributos del documento.
Los mismos entornos incluyen facilidades para validar el cdigo XML resultante, pero esto se puede hacer tambin usando do analizadores XML, de los cuales hay muchos, de bastante buena calidad, y la mayor parte de ellos gratuitos. Uno de los ms conocidos y usados es el Xerces, del cual hay versiones en Java, en Perl y en C++. Es adecuadamente rpido, y adems incorpora todos todos los ltimos estndares del W3. Otra opcin, que adems se puede usar desde Internet, es el XParse de Jeremie, que analiza directamente el documento y te lo presenta en forma de rbol, aunque elementos como exploradores web tambin incorporan validaciones ones de documentos XML, como por ejemplo, Internet Explorer. La mayor parte de los validadores trabajan de forma independiente, y se pueden utilizar como libreras desde el lenguaje de programacin de propia eleccin. En muchos casos, como en el caso de C#, C#, el XML se puede generar automticamente a partir de la definicin de una clase, o bien, al revs, una clase o un objeto de una clase se puede generar automticamente a partir de XML o a partir de un fichero. Si nos centramos en los servicios web, podemos generar documentos xml que se basan en las clases creadas para ser expuestas hacia el cliente. Podemos visualizar en ste cdigo una respuesta de un documento XML generado a partir de un servicio web realizado en Java. <?xml version="1.0" encoding="UTF-8" 8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:MensajeResponse xmlns:ns2="http://paquetewebservice/"> <return>Servicio Web de Java</return> </ns2:MensajeResponse> </S:Body> </S:Envelope> Como lenguaje de anotacin, las sentencias en XML consisten en una serie de etiquetas (llamadas elementos o nodos) con una serie de modificadores (llamados atributos). Las etiquetas pueden estar anidadas unas dentro de otras, pero toda etiqueta que se abra a se tiene que cerrar de una forma jerarquica, es decir, siempre en el mismo orden. En caso de que un elemento no tenga pareja (por no tener ningn contenido dentro), se le denomina elemento vaco y se indica con un simbolo / al final. Los elementos se agrupan en documentos, como por ejemplo el siguiente cdigo: <?xml version="1.0" encoding='iso-8859 8859-1' ?> <listacompra> <productos id='limpieza'> <producto>Fairy</producto> <producto>Lavavajilla</producto> </productos> <productos id='alimentacion'> <producto>huevos</producto> <producto>mantequilla</producto> <producto></producto> </productos> </listacompra>
Todos los documentos XML deben estar bien formados, y este es el requisito mnimo que deben cumplir los documentos.
Esta afirmacin significa que debemos cumplor una serie de requisitos: x Debemos indicar la codificacin de caracteres que el documento XML utilizar, eso se realiza mediante la primera etiqueta del documento y que tiene como atributo encoding. Dicha codificacin n indicar los caracteres que podremos incluir dentro de las etiquetas del documento. Todas las etiquetas deben tener una jerarqua, es decir, todos los elementos que contengan datos de tipo carcter deben tener etiquetas de principio y fin. Todos los valores res de los atributos deben ir entrecomillados (el carcter comilla simple puede utilizarse si el valor contiene caracteres comillas dobles, y viceversa. Cualquier elemento VACO (por ejemplo aquellos que no tienen etiqueta final como y otros tipos de HTML) HTM deben terminar con o debemos crearlos como no vacos aadindo una etiqueta de fin, tal como vemos en uno de los elementos producto. No podemos utilizar caracteres especiales que formen la estructura del documento, como por ejemplo si necesitamos incluir incluir dichos caracteres, se utilizan entidades que representan dichos caracteres, como por ejemplo < o &. Los elementos deben anidar dentro de s sus propiedades (no se deben sobreponer etiquetas, como en documentos SGML). Los nombres de las etiquetas pueden ser alfanumricos, comenzando con una letra, e incluyendo los caracteres - y :, aunque este ltimo tiene un significado especial.
x x x
x x
Todo documento XML debe estar bien formado para poder ser utilizado y que sea funcional.
XML Namespace
Los espacios de e nombres de un documento nos permiten poder definir la procedencia de un documento como tambin la estructura que sigue un documento. Si en cualquier documento fueramos definiendo etiquetas sin sentido, a pesar de estar bien formado, el documento acabara a siendo un caos de diferentes etiquetas procedentes de diferentes sitios, y, lo que es peor, de etiquetas con el mismo nombre que, en realidad, significan cosas diferentes. El concepto de espacios de nombres (namespaces) permite particionar el conjunto de todos los nombres posibles, de forma que se pueda definir a qu zona de ese espacio corresponde una etiqueta. De esta forma, etiquetas con el mismo nombre, pero definidas por dos autores diferentes, pueden diferenciarse en el espacio de nombres. El espacio pacio de nombres no es esencial en todos los documentos, pero resulta til cuando se usan etiquetas procedentes de diferentes procedencias (por ejemplo, etiquetas nuevas dentro de un documento XML), o etiquetas que se quieren procesar de forma diferente. El espacio de nombres de una etiqueta se indica como Por ejemplo, se usan espacios de nombres en el documento siguiente: <?xml version="1.0" encoding='iso-8859 8859-1' ?> <milista:listacompra xmlns:milista='http://www.ejemploxml/listacompra'> <milista:productos id='limpieza'> <milista:producto>Fairy</milista:producto> <milista:producto>Lavavajilla</milista:producto> </milista:productos> <milista:productos id='alimentacion'>
<milista:producto>huevos</milista:producto> <milista:producto>mantequilla</milista:producto> >mantequilla</milista:producto> </milista:productos> </milista:listacompra> No es necesario especificar un prefijo para las etiquetas, tambin podemos crear el documento sin necesidad de hacerlo, y el espacio de nombres indicar la procedencia del documento docum y las reglas que debe seguir: <?xml version="1.0" encoding='iso-8859 8859-1' ?> <listacompra xmlns='http://www.ejemploxml/listacompra'> <productos id='limpieza'> <producto>Fairy</producto> <producto>Lavavajilla</producto> </productos> <productos id='alimentacion'> <producto>huevos</producto> <producto>mantequilla</producto> </productos> </listacompra> Un documento XML puede tener tantos espacios de nombres como se quieran declarar, y se pueden mezclar elementos de diferentes espacios espacio de nombres. Por ejemplo, si visualizamos el resultado del mensaje SOAP de un documento XML, podremos comprobar que utiliza los espacios de nombres para definir la estructura y los prefijos para las etiquetas que utilizar en el momento de devolver la informacin ormacin a un cliente:
Validacin de documentos XML Cuando utilizamos documentos XML, una de las caractersticas que hemos analizado es su estructura, es decir, que el documento est bien formado, que las etiquetas tengan una apertura y un cierre, se utilicen caracteres adecuados, etc. Pero otra caracterstica muy importante es la validacin del documento, lo que quiere decir que la estructura que hemos creado siga unos pasos determinados, es decir, que las etiquetas sean las correctas o estn en el orden den adecuado. Dentro de la validacin de documentos XML nos encontramos con dos tipos de elementos: DTD y Schema. Las DTDs son los documentos que definen las etiquetas vlidas dentro de un documento XML.
Un documento XML, usualmente puede tener asociado otro otro documento llamado DTD, que indicar las etiquetas que contendr y el orden de las etiquetas en el documento. Uno de los problemas de las DTDs es, que no son documentos XML en s mismos, no son demasiado extensibles y adems, no nos permite establecer validaciones validaciones ms complejas que la propia existencia y orden de los elementos y atributos. Una DTD es un archivo que encierra una definicin formal de un tipo de documento y, al mismo tiempo, especifica la estructura lgica de cada documento. Define tanto los os elementos de un documento XML, como sus atributos. Utilizar una DTD en un documento XML es opcional. Un documento DTD permite poder diferenciar entre el concepto de documento "bien formado" y un documento "vlido". Por ejemplo, podemos visualizar un documento documento DTD basado en el documento XML de la lista de la compra que hemos visto anteriormente:
<?xml version='1.0' encoding='UTF-8'?> 8'?> <!ELEMENT listacompra (productos)*> <!ATTLIST listacompra xmlns CDATA #IMPLIED> <!ELEMENT productos (producto)*> <!ATTLIST IST productos id CDATA #IMPLIED> <!ELEMENT producto (#PCDATA)>
Dicha DTD indica el orden de los elementos del documento y el contenido (Atributos) de dichos elementos, pero por ejemplo, no puede indicar el tipo de dato de los elementos o crear relaciones relacione entre dichos elementos. Los documentos DTD son antiguos, era algo previsible que las DTDs evolucionasen, debido a temas como tipos de datos o relacin entre las etiquetas de los documentos. Esta evolucin son los schemas (Esquemas XML). Al igual que las as DTD, los Schemas describen el contenido y la estructura de la informacin, pero de una froma ms precisa. Los esquemas indican tipos de dato, nmero mnimo y mximo de ocurrencias y otras caractersticas ms precisas. Los esquemas expresan vocabularios vocabularios compartidos que permiten a las mquinas extraer las reglas hechas por las personas. Los esquemas proveen un significado para definir la estructura, contenido y semntica de los documentos XML. Un esquema XML (XML Schema) es algo similar a un DTD, es decir, decir, define qu elementos puede contener un documento XML, cmo estn organizados y qu atributos y de qu tipo pueden tener sus elementos, pero la utilizacin de Schemas ofrece muchas ms posibilidades a los documentos. Los esquemas utilizan sintaxis XML, al al contratio que los DTD, permiten especificar los tipos de datos y son exgtensibles, es decir, permiten crear nuevos elementos. Un Schema nos permite definir el tipo de contenido de elementos o atributos precisando si debe ser un nmero entero, una cadena de texto, una fecha, etc. Un ejemplo de Schema respecto al documento XML lista de la compra es el siguiente:
<?xml version="1.0" encoding="iso-8859 8859-1"?> <xs:schema attributeFormDefault="unqualified" elementFormDefault="qualified"_ elementFormDefault="qualified"_ targetNamespace="http://www.ejemploxml/listacompra" xmlns:xs="http://www.w3.org/2001/XMLSchema"> <xs:element name="listacompra"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="productos"> <xs:complexType> <xs:sequence> <xs:element maxOccurs="unbounded" name="producto" type="xs:string" /> </xs:sequence> <xs:attribute name="id" type="xs:string" use="required" /> </xs:complexType> </xs:element> </xs:sequence> </xs:complexType> </xs:element> </xs:schema>
Como podemos observar, no solamente indica el orden de los elementos o el nmero de apariciones en el documento, sino que tambin representa el tipo de datos de los atributos y los elementos. Es necesario comenzar el esquema definiendo los elementos ms profundamente anidados dentro de la estructura jerrquica de elementos del documento xml. Las declaraciones de tipo ElementType y AttributeType deben preceder a las declaraciones de contenido element y attribute correspondiente. Un esquems tambin puede verse como una coleccin (vocabulario) de definiciones de tipos y declaraciones de elementos cuyos nombres pertenecen a un determinado espacio de nombres. Los espacios de nombres de e destino hacen posible la distincin entre definiciones y declaraciones de diferentes vocabularios. La estructura de un documento XML aplicada a los servicios se define mediante SOAP. La respuesta de cualquier servicio web viene ofrecida mediante datos xml, y la estructura que definir el tipo de datos, el orden de los elementos ofrecidos por el servicio y el nmero de elementos se expresa en un esquema definido como documento WSDL. Podemos visulizar un ejemplo de WSDL a partir de un servicio web:
Ahora que ya conocemos algo ms sobre elementos XML, nos queda responder a la utilizacin de dichos servicios dentro del entorno de los Servicios Web.
Las razones de la utilizacin de XML en los Servicios Web son las siguientes: x Es un estndar abierto, es decir, es reconocido mundialmente ya que muchas compaas tecnolgicas integran en su software compatibilidad con dicho lenguaje de marcado.
Esto quiere decir que la gran mayora de software de escritorio, de sistema operativo, software de internet o aplicaciones icaciones mviles permiten la compatibilidad con XML. Esto lo hace muy potente a la hora de permitir la comunicacin entre distintas plataformas de software y hardware, lo que es el producto final de los Servicios Web.
La simplicidad de sintaxis XML, lo que quiere decir que es muy fcil de escribir cdigo en XML, y la representacin de los datos es casi entendible por cualquier ser humano.
Esto lo hace muy flexible a la hora de querer representar datos de cualquier tipo, con lo que unicamente bastara con on contar con cualquier editor de texto y aprender unas cuantas instrucciones bsicas. El hecho de que XML sea tan fcil de codificar y de entender lo hace el lenguaje ideal para utilizarlo en los servicios Web.
Independencia del protocolo de Transporte. El hecho de que XML sea un lenguaje de Marcado de Texto significa que no necesita de ningn protocolo de transporte especial, solo necesita de un protocolo que pueda trasferir texto o documentos simples.
Podemos compararlo con protocolos conocidos y que si necesitan de un transporte especial y un marcado especial, como son HTTP o SMTP, por nombrar algunos. Una de las caractersticas ms importantes de los Servicios Web es su independencia del protocolo de transporte.
Ver Video: Estructura y Validacin de documentos XML, en el Mdulo 7. Unidad 4, en la plataforma elearning.
Unidad 4: Examinando mensajes SOAP

Objetivos
x x x Comprender la arquitectura de protocolo de mensajes SOAP en los Servicios Web Entender el uso de SOAP dentro de los mensajes cliente en Web Service. Analizar las caractersticas de SOAP en el envo y la recepcin de datos en Web Services.
Introduccin
SOAP (Simple Object Access Protocol) es un protocolo basado en XML para el intercambio de informacin. Implementar una arquitectura orientada entada a servicio (SOAP) comprende omprende el desarrollo de aplicaciones que usen los servicios, aplicaciones disponibles isponibles como servicios para otras o ambas aplicaciones. aplicaciones
Un servicio web SOAP es una funcin de aplicacin empaquetada como un componente reutilizable reutilizab para ser usado en proceso de negocio. El servicio proporciona informacin o facilita el cambio de datos de negocio en un estado vlido y consistente a otro. La caracterstica principal de SOA es que es una arquitectura con acoplamiento dbil. Acoplamiento to dbil significa que el cliente de un servicio es casi completamente independiente de la construccin de ese servicio. Un Web Service es un servicio que se comunica con los clientes a travs de un conjunto estndar de protocolos y tecnologa. Estos estndares stndares estn implementados en las plataformas y productos de los principales proveedores de software, lo que hace de los Web Services la principal opcin para lo construccin de arquitecturas SOAP Existen varias razones por las que una empresa adopte un desarrollo de arquitectura SOAP basado en Web Services: x Reutilizacin.
El factor fundamental en el cambio a una arquitectura SOAP es la reutilizacin de los servicios de negocio. Las funciones de negocio dentro de una empresa pueden ser expuestos como web we services y ser reutilizados para cubrir las diferentes necesidades de negocio de soluciones. x Interoperabilidad
El objetivo de una arquitectura dbilmente acopada es que los clientes y servicios se comunican independientemente de la plataforma en la que residan. r Los protocolos de comunicacin con Web Services son independientes de la plataforma, lenguaje de codificacin y sistema operativo, por lo que facilitan la comunicacin con los procesos de negocio. x Escalabilidad
Como los servicios de SOAP estn dbilmente dbilmente acoplados, las aplicaciones que usan dichos servicios se escalan fcilmente. Esto se puede realizar porque existe una mnima dependencia entre las aplicaciones clientes y los servicios que las utilizan. x Flexibilidad
Es otra de las caractersticas que proporciona el acoplamiento dbil entre los servicios. Cualquier cambio en la implementacin de uno de ellos, no afectara al resto, siempre y cuando se mantengan en la interfaz. x Eficiencia de coste
Las arquitecturas SOAP AP se basan en la exposicin de servicios ya existentes para ser reutilizados. Al usar Web Services para exponer estos servicios, se reutiliza la infraestructura web existente en casi todas las organizaciones, por lo que se limita considerablemente el coste. cost
SOAP soporta dos modelos de intercambio: 1) Orientado a documentos x x x Generalmente operan en forma asincrnica El mensaje de respuesta no es fundamental, y si existe, existe acta como forma de devolver un ticket o acuse de recibo. La construccin del mensaje y su carga til (payload). La carga til del mensaje es la informacin que se transmite excluyendo aquella que es especfica del protocolo de transmisin.
Caractersticas importantes: Medio de transporte. Destino del documento (endpoint)
2) Orientado a llamadas remotas (RPC, remote procedure call) Generalmente operan en forma sincrnica. Las operaciones llamadas contienen parmetros de entrada y de salida. Los parmetros de salida suelen modelarse como una estructura de retorno (mensaje de respuesta).
Caractersticas importantes: La operacin particular que se invoca. El conjunto de valores de entrada. El conjunto de valores de salida. La correlacin entre los mensajes de pedidos (requests) con los mensajes de respuesta (response) (
SOAP est diseado para comunicaciones punto a punto. Fue desarrollado a finales de 1999 por DevelopMentor (http://www.develop.com), Microsoft y UserLand (http://www.userland.com) como un protocolo especfico de Windows para ejecutar llamadas RPC con XML. En el ao 2000 Lotus e IBM se unieron a este esfuerzo y el objetivo se ampli a producir una especificacin abierta, extensible e independiente de lenguaje y plataforma. La primera versin de SOAP, 1.1, fue aprobada como estndar por la organizacin W3C (World Wide Web Consortium) en Mayo del mismo ao. En el interior de los servicios Web se localiza el protocolo simple de acceso a datos SOAP, que ofrece un mecanismo estndar de empaquetar mensajes. SOAP ha recibido una gran atencin debido a que facilita facil el uso de una comunicacin del estilo RPC entre un cliente y un servidor remoto. Existen xisten multitud de protocolos creados para facilitar la comunicacin entre aplicaciones, incluyendo RPC de Sum, DCE de Microsoft, RMI de Java y ORPC de CORBA. Una de las razones ms importantes para la utilizacin y la extensin de SOAP en los Servicios Web es que SOAP ha recibido un increble apoyo por parte de la industria. SOAP es el primer protocolo de su tipo que ha sido aceptado prcticamente por todas las grandes compaas de software del mundo. Dichas compaas no suelen colaborar o cooperar entre s, pero estn ofreciendo su apoyo a este protocolo. Algunas de las mayores Compaas que soportan SOAP son Microsoft, IBM, SUN, Microsystems, SAP y Ariba. Ventajas de la utilizacin de SOAP Una de las mayores ventajas en la utilizacin del protocolo SOAP es que no esta asociado a ningn lenguaje. SOAP no especifica ninguna API, por lo que la implementacin de la API se deja al lenguaje de programacin elegido para desarrollar arrollar el servicio web, web, como en Java, y Microsoft .Net. SOAP no est asociado a ningn protocolo de transporte. La especificacin de SOAP no describe como se deberan asociar los mensajes de SOAP con HTTP. Un mensaje SOAP no es ms que un documento XML, por lo que puede transportarse utilizando cualquier protocolo capaz de transmitir texto. SOAP no est asociado a ninguna infraestructura de objeto distribuido. distribuido La mayora de los sistemas de objetos distribuidos se pueden extender, y ya lo estn alguno de ellos para que admitan SOAP.
SOAP utiliza los estndares existentes en la industria. industria Los principales contribuyentes a la especificacin SOAP evitaron, intencionadamente, reinventar las cosas. Cada uno de ellos tena unas caractersticas diferentes en su tecnologa tecnologa y distribucin, por lo que decidieron extender los estndares existentes para que coincidieran con sus necesidades. SOAP aprovecha XML para la codificacin de los mensajes, en lugar de usar un sistema propio de tipo, por lo que los tipos de datos s ya estn definidos definido en la especificacin del esquema XML asociado al Servicio Web. mensajes los mensajes Como ya hemos comentado, SOAP no define un modelo de transporte para los mensajes, enviados por el protocolo SOAP se pueden asociar a los protocolos de transporte existentes como HTTP y SMTP. SOAP permite la interoperabilidad ilidad entre mltiples entornos. El desarrollo del protocolo se hizo bajo los estndares existentes de la industria, por lo que las aplicaciones que se ejecuten en plataformas con dicho estndares pueden comunicarse mediante mensajes SOAP con aplicaciones que se ejecuten en otras plataformas. Por ejemplo, una aplicacin de escritorio scritorio que se ejecute en un ordenador, puede comunicarse con una aplicacin que est sirviendo informacin desde internet capaz de enviar y recibir XML sobre HTTP. Estructura de los mensajes SOAP a estructura de un mensaje SOAP indica como se encuentra compuesta la solicitud enviada del La Cliente e hacia el web service y viceversa. En toda solicitud a un Servicio Web, siempre tendremos la estructura de los elementos que veremos en el cliente y los datos que visualizaremos posteriormente desde el servicio web. Vamos a poner como ejemplo un servicio web que indica la temperatura de una regin en un mes y un ao determinado. Por ejemplo, lo que necesitaramos recibir desde el cliente sera la regin, el mes y el ao que desea averiguar el cliente para el resultado. La solicitud del cliente en el mensaje e SOAP sera la siguiente: <?xml version="1.0" encoding="UTF-8"?> 8"?> <SOAP- ENVIO:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENVIO="http://schemas.xmlsoap.org/soap/envelope/" ENVIO="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsi="http://www.w3.org/2001/XMLSchema ="http://www.w3.org/2001/XMLSchema-instance"> <SOAP- ENVIO:Body> <ns1:temperaturas xmlns:ns1="Datos"> <op1 xsi:type="xsd:string"> Madrid </op1> <op2 xsi:type="xsd:integer"> Julio </op2> <op2 xsi:type="xsd:integer"> teger"> 2005 </op2> </ns1:temperaturas> </SOAP- ENVIO:Body> </SOAP- ENVIO:Envelope> Si analizamos el cdigo de la solicitud del cliente veremos los siguientes elementos: Primeramente es definido el clsico elemento para un documento/fragmento documento/fragmento XML: <?xml version="1.0" encoding="UTF-8"?> 8"?> Posteriormente, es definido el elemento raz SOAP-ENVIO:Envelope SOAP :Envelope que como su nombre lo indica (Envelope=Sobre), es empleado para describir el el mensaje SOAP que ser enviado.
Dentro del elemento SOAP-ENVIO son definidos tres Namespaces, una para el mismo SOAP-ENVIO, SOAP otro para el Schema y uno ms para una instancia del de Schema. Terminada la definicin del elemento Envelope se declara el elemento SOAP-ENVIO:Body SOAP (Como podemos comprobar, pertenece al mismo Namespace Namespace que Envelope) que contiene el cuerpo del mensaje SOAP. Dentro del elemento Body se anida el elemento ns1:temperaturas, ns1:temperaturas que indica el inicio del mensaje hacia el web service llamado temperaturas, temperaturas debemos dfijarnos en que el Namespace ns1 corresponde al nombre Datos, tal y como fue definido en el Cliente. A continuacin, son definidos los tres elementos que contienen los parmetros de entrada para el web service, uno de tipo string y otros s dos de tipo integer. Los valores Madrid, Julio y 2005 representan los datos proporcionados por el usuario del web service. Finalizando la estructura, son on definidos los elementos necesarios para cerrar las descripciones de ns1:temperaturas, SOAP-ENVIO:Body :Body y SOAP-ENVIO:Envelope. SOAP SOAP proporciona un mecanismo estndar de empaquetar un mensaje. Un mensaje SOAP se compone de un sobre que contiene el cuerpo del mensaje y cualquier informacin de cabecera que se utiliza para describir el mensaje. Un mensaje debe estar dentro de sobre de SOAP bien construido. Un sobre se compone de un nico elemento envelope, envelope y el sobre puede contener un elemento Header y puede contener un elemento body. Si existe, la cabecera debe ser el elemento hijo inmediato del sobre, con el cuerpo siguiendo inmediatamente a la cabecera. El cuerpo contiene la carga de datos del mensaje y la cabecera contiene los datos adicionales que no pertenecen necesariamente al cuerpo del mensaje. Adems de definir un sobre de SOAP, la especificacin de SOAP define una forma form de codificar los datos contenidos en un mensaje. La codificacin SOAP proporciona un mecanismo estndar para serializar tipos de datos no definidos en la primera parte de la especificacin del esquema XML. La especificacin de SOAP tambin proporciona un patrn de mensaje estndar para facilitar el comportamiento de tipo RPC. Se emparejan dos mensajes de SOAP para facilitar la asociacin de un mensaje de peticin con un mensaje de respuesta. La llamada a un mtodo y sus parmetros se serializan en el cuerpo del mensaje de peticin en forma de una estructura. El elemento raz tiene el mismo nombre que el mtodo objetivo, con cada uno de los parmetros codificado como un subelemento. El mensaje de respuesta puede contener los resultados de la llamada al al mtodo o una estructura de fallo bien definida. Los resultados de la llamada a un mtodo se serializan en el cuerpo de la peticin como una estructura. Vamos a visualizar como sera la respuesta de una peticin sobre el servicio de temperaturas que hemos hem puesto a modo de ejemplo: <?xml version="1.0" encoding="UTF-8"?> 8"?> <SOAP-ENVIO:Envelope ENVIO:Envelope xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:SOAP-ENVIO="http://schemas.xmlsoap.org/soap/envelope/" ENVIO="http://schemas.xmlsoap.org/soap/envelope/"
xmlns:xsi="http://www.w3.org/2001/XMLSchema /www.w3.org/2001/XMLSchema-instance"> <SOAP-ENVIO:Body> <ns1:temperaturasResponse xmlns:ns1="Datos"> <result xsi:type="xsd:double"> 32.6 </result> </ns1: temperaturasResponse> </SOAP-ENVIO:Body> </SOAP- ENVIO:Envelope> Primeramente es definido el clsico elemento para un documento/fragmento XML: <?xml version="1.0" encoding="UTF-8"?> 8"?> Posteriormente, es definido el elemento raz SOAP-ENVIO:Envelope SOAP :Envelope que como su nombre lo indica (Envelope=Sobre), es empleado para describir el mensaje SOAP que ser enviado como respuesta. respuesta Dentro entro de este elemento son definidos tres Namespaces, una para el mismo SOAP-ENVIO, SOAP otro para Schema y uno ms para una instancia de Schema. Terminada la definicin del elemento Envelope se declara el elemento SOAP-ENV ENVIO:Body que contiene el cuerpo del mensaje SOAP. Dentro del elemento Body se anida el elemento ns1:temperaturasResponse ns1: Response que indica la respuesta del web service llamado temperaturas, temperaturas como podemos comprobar, el Namespace Namespa ns1 corresponde al nombre Datos tal y como fue definido en el Cliente. A continuacin, es s definido el elemento que contiene el parmetro de respuesta del web service, el cual es del tipo doubl con el valor 32.6, que representa el resultado procesado por po el web service. Por ltimo, son on definidos los elementos necesarios para cerrar ns1:temperaturasResponse, SOAP-ENV ENVIO:Body y SOAP-ENVIO:Envelope. las descripciones de
Por convenio, el elemento raz tiene el mismo nombre que el mtodo original al que se aade aa result. Los parmetros de retorno se serializan como elementos hijo, con el parmetro de retorno en primer lugar. Si se encuentra un error el cuerpo del mensaje de respuesta contendr una estructura de fallo bien definida. Podemos comprobar fcilmente e que la estructura de los mensajes SOAP es independiente al lenguaje de programacin. Por ejemplo, vamos a visualizar el mensaje SOAP de un Servicio Web creado en Java y otro realizado en Net. Si tenemos un Servicio Web que devuelve el doble de un nmero realizado en Java, veremos la siguiente solicitud SOAP del servicio:
Como podemos comprobar, contiene el elemento sobre (envelope) dentro del documento, incluye un Header y un body con el contenido que hemos enviado a la solicitud del servicio. Si ahora visualizamos la respuesta que nos ha ofrecido el servicio:
Comprobaremos que los datos expuestos son los mismos que en la solicitud, incluyendo la respuesta dentro de la etiqueda Return. Si visualizamos la arquitectura SOAP de un servicio web realizado realizado con la plataforma Visual Studio veremos lo siguiente. Mismo servicio web con un nmero como recepcin y devolucin del doble del nmero recibido como parmetro: SOLICITUD SOAP
RESPUESTA SOAP
Podremos comprobar que la estructura es la misma, por lo que la escalabilidad y la interoperabilidad entre servicios es muy sencilla, lo que quiere decir, que al utilizar la misma estructura en su arquitectura, los servicios se pueden comunicar entre diferentes lenguajes intercambiando su informacin. SOA es una a arquitectura que permite organizar mucho mejor los sistemas IT de una compaa. La organizacin y la utilizacin de SOAP dentro de cualquier arquitectura de negocio ofrecer las siguientes caractersticas: x x x x x x x x x Escalabilidad Robustez Homogeneidad Facilidad en la adaptacin de nuevos servicios Facilidad en la reestructuracin de sistemas Aplicar la lgica en el middleware pudiendo implementar procesos de negocios. Recoger informacin y procesarla para obtener resultados ms utiles Ahorro en tiempos de implantacin implantac Ahorro en tiempos de mantenimiento y operacin
A pesar de obtener todas estas ventajas, no siempre hay que utilizar los servicios web porque tengamos una estructura que necesitamos que sea estndar. Tambin tiene sus desventajas la arquitectura. Por ejemplo, una de las ms importantes es la velocidad en el intercambio de informacin entre sistemas, ya que es ms lenta que si utilizamos un intercambio de informacin directo de punto a punto como en aplicaciones cliente-bases bases de datos, por ejemplo. El que ue SOAP sea una arquitectura muy estudiada y utilizada por todos los proveedores de arquitecturas de desarrollo, no implica que sea recomendable en cualquier escenario.
Ver Video: Estructura SOAP de un Servicio Web Java, en el Modulo 7. Unidad 4, en la plataforma plataforma elearning
Unidad 5: Desarrollando Servicios Web usando SOAP con adjuntos

Objetivo
Explicar las alternativas tcnicas para el envo de documentos adjuntos en una estructura XML.
Introduccin
En aplicaciones de Arquitectura orientada a servicios (SOA) suele requerirse que los datos relacionados con aplicaciones se encuentren asociados con los archivos XML (Lenguaje de marcado extensible) usados en la aplicacin. eado podra estar asociada con el currculum del empleado o una serie Por ejemplo, la foto de un empleado de archivos de datos financieros podran estar asociados con una aplicacin que analice los registros de las cuentas de la empresa. Una forma eficaz de enviar estos datos asociados es mediante mediante un adjunto en Protocolo simple de acceso a objetos (Simple Object Access Protocol o SOAP). Desde el punto de vista del desarrollo, los adjuntos aportan una mayor adaptabilidad y mejoran el rendimiento de las aplicaciones, lo cual se traduce en aplicaciones ms usables. Los adjuntos permiten a sus aplicaciones solicitar los tipos de archivos que sus usuarios podran asociar a su aplicacin adaptando la aplicacin al entorno especfico de cada usuario. En realidad, al enviar informacin los datos se codifican bajo base 64, es decir se convierten los lo datos en binario, lo que conforma forma que el adjunto en s se encuentra separado del cuerpo del de mensaje SOAP, por lo tanto, no se analiza como parte del mensaje y esto elimina la costosa sobrecarga de procesamiento. proc
Tipos de adjuntos
Un adjunto es un conjunto de datos os asociados con una aplicacin, es decir, los datos se encuentran adjuntos al mensaje que usa la aplicacin. En el momento de trabajar con elementos adjuntos dentro de los servicios web podemos podem hacerlo de dos formas diferentes: x Adjunto con enlace implicito
Un adjunto con enlace explcito es un adjunto modelado como parte del lenguaje WSDL (Lenguaje de Descripcin de Servicios Web) que est enlazada como parte MIME (Extensiones de Correo de Internet Int Multipropsito) en un enlace SOAP WSDL. El protocolo SOAP no contiene ningn elemento que haga referencia al adjunto y el adjunto se encuentra dentro del soporte SOAP y dentro del Schema WSDL. Los datos son enviados en modo binario y se recuperan en el cliente de la misma forma. x Adjunto con enlace explicito
Un adjunto referenciado mediante un elemento href (Referencia SOAP con adjuntos) es un adjunto que usa el tipo de adjuncin definido por WS-I. WS El cuerpo SOAP incluye una referencia al adjunto. El adjunto se encuentra fuera del cuerpo SOAP y est modelado fuera del archivo WSDL.
Para leer la definicin de los adjuntos referenciados, debemos acceder a elementos de terceros que se encuentran en direcciones href. d la informacin en algunos documentos XML en los que se requiere Existen momentos de arquitectura de incorporar piezas adjuntas o documentos como parte de la estructura de datos a manejar, unos de los ejemplos ms frecuente es adjuntar documentos escaneados en formato de imagen. Para resolver la solucin de adjuntos dentro de documentos y servicios web xml existen dos opciones: x x Incluir los documentos adjuntos en el XML. (Adjunto Implicito) Apuntar desde el XML a un repositorio donde se encuentren almacenados los documentos (Adjunto Explicito)
Modelo de adjuntos implicitos

En el momento de modelar el documento XML en la etapa de creacin del esquema, se deben considerar las caractersticas del proceso de negocio que se quiere desarrollar y de las caractersticas de los documentos a incluir para tomar la decisin correcta. Al incluir cluir un documento dentro de una representacin XML se ve como una cadena de caracteres como se muestra a continuacin: <documentoXML> <nombre>Usuario</nombre> <adjunto>BJkkEI@DsERtgY.....</adjunto> </documentoXML> Cuando incluimos documentos adjuntos adjuntos dentro del propio documento XML existen una serie de ventajas y desventajas:
Ventajas de adjuntos implcitos x x x x El documento XML contiene todos los datos modelados. (Ej: : datos modelados+nombre+adjunto). modelados+ Cuando se intercambia (enviamos/recibimos) el documento documento. XML, se transfiere un solo
Si el documento se debe firmar con Firma Electrnica Avanzada, la aplicacin de firma tiene todos los elementos para el procesamiento. Agiliza la arquitectura de repositorio y el flujo de trabajo basados en el documento XML.
Desventajas de adjuntos implcitos x x La incorporacin de archivos binarios puede aumentar el tamao del archivo XML hasta un punto que dificulta el procesamiento o intercambio de informacin. La respuesta del servicio web que devuelve el documento xml con adjunto es ms lenta y la transferencia de informacin se realiza de forma menos ptima debido a la lentitud del envo.
XML permite la inclusin de archivos binarios a travs del tipo de datos: datos: xs: base64Binary definido por la W3C en la direccin: http://www.w3.org/TR/2001/REC-xmlschema xmlschema-2-20010502/#base64Binary El tipo de dato base64binary representa al archivo binario codificado en base64.
Se codifica en base64 para tener una cadena de caracteres caracteres donde ningn carcter sea prohibido por el lenguaje XML como son: Por ejemplo, la estructura de un esquema WSDL para enviar una informacin de un contacto con una imagen asociada dentro del documento sera la siguiente:
Y el documento XML que tendra la referencia al resultado sera el siguiente: <Adjuntos> <imagen> <Nro>1</Nro> <Nombre>Usuario</Nombre> <MimeType>image/jpeg</MimeType> <DataCodificada>/9j/4AAQSkZJRgABAAEAyADIAAD//gAfTEVBRCBUZWNobm9sb2dpZXMgSW 5jLiBWMS4wMQD/_ 2wCEAAgFBgcGBQgHBgcJCAgJDBQNDAsLDBgREg4UHRkeHhwZHBsgJC4nICIrIhscKDYoKy8xMzQzHyY4PD gyPC4yMzEBC_ AkJDAoMFw0NFzEhHCExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMTExMf /EaaI_ AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEBAQEBAQAAAAAAAAECAwQF AAAEFAQEBAQEBAAAAAAAAAAABAgMEBQYHCAkKCwEAAwEBAQEBAQEBAQAAAAAAAAECAwQFBgcI CQoLEAACAQMDAgQD_ BQUEBAAAAX0BAgMABBEFEiExQQYTUWEHInEUMoGRoQgjQrHBFVLR8CQzYnKCCQoWFxgZGiUmJygpKjQ1 Njc4OTpDREVGR0h_ JSlNUVVZXWFlaY2RlZmdoaWpzdHV2d3h5eoOEhYaHiImKkpOUlZaXmJmaoqOkpaanqKmqsrO0tba3uLm6w sPExcbHyMnK0tPU1dbX2N_ na4eLj5OXm5+jp6vHy8/T19vf4+foRAAIBAgQEAwQHBQQEAAECdwABAgMRBAUhMQYSQVEHYXETIjKBCBR CkaGxwQ </DataCodificada> </imagen> </Adjuntos> Vamos a visualizar un ejemplo para enviar un texto como adjunto dentro de un servicio web. Vamos a a crearnos un nuevo proyecto en Netbeans del tipo Java Web y seleccionamos Web Application:
Llamaremos al proyecto EjemploAdjuntos
Utilizaremos el servidor de aplicaciones GlasshFish y no agregaremos ningn Framework al proyecto. Sobre el proyecto vamos a agregar un nuevo elemento:
En la carpeta Web Services, seleccionaremos Web Service.
Lo llamaremos ServicioAdjunto
Ahora en nuestro cdigo del servicio, lo que haremos ser agregar un mtodo que nos devolver los datos de un fichero de texto plano, en el envo, tendremos tendremos los datos codificados, y al cliente le llegarn filtrados y decodificados en base 64. El mtodo que agregaremos devolver un array del tipo de dato byte:
Una vez que hemos agregado el mtodo, vamos a implementarlo para devolver un texto codificado en binario. Para ello, debemos utilizar la clase base64 para que en la salida del flujo binario no existan caracteres especiales que no admitan el protocolo http de los servicios web. El cdigo de la clase del Servicio Web quedar de la siguiente forma: package paquetews; import com.sun.org.apache.xerces.internal.impl.dv.util.Base64; import javax.jws.WebMethod; import javax.jws.WebService; @WebService() public class ServicioAdjunto { /** * Web service operation */ @WebMethod(operationName = "adjuntoBinario") public byte[] adjuntoBinario() { String texto = "java"; byte[] salida = Base64.decode(texto); return salida; }
} Debemos agregar el espacio de nombres de apache para poder enviar enviar la codificacin de datos binarios:
Ahora vamos a probar el servicio web para mostrar el envo de informacin codificada y la decodificacin en el cliente. Para ello vamos a recuperar el Tester de Netbeans para mostrar los datos del servicio:
Veremos os la pantalla de presentacin del servicio:
Cuando pulsemos sobre el botn para visualizar los datos en binario, veremos el resultado de enviar los datos en binario:
Si visualizamos la respuesta, veremos que el texto llegar al cliente decodificado:
Modelo adjuntos referenciados (Explcitos)

Apuntar o referenciar un documento adjunto, significa indicar la URL en la cual se encuentra dicho documento.
La forma correcta de referenciar los documentos en un XML, puede ser de las siguientes formas: x Utilizando href
<documentoXML> <nombre>Usuario</nombre> < adjunto href=http://www.ejemplos.com/documento.doc/> </documentoXML> x XLink <documentoXML> <nombre>Usuario</nombre> <adjunto xmlns:xlink="http://www.w3.org/XML/XLink/0.9" _ xlink:type="simple" xlink:href=" http://www.ejemplos.com/documento.doc/> </documentoXML> Al igual que sucede con los documentos XML que contienen la informacin de forma implcita, los documentos XML con adjuntos explcitos tienen sus ventajas y desventajas: desven
Ventajas adjuntos explicitos x x Permite no cargar la instancia XML en trmino de tamao. Permite tener extensibilidad en caso de lista (el documento XML puede apuntar tanto a 10 documentos como a 10.000)
Desventajas adjuntos explicitos x x x x x x x El documento XML no contiene todos los datos modelados. Cuando se intercambia (enviar/recibir) el documento XML, se transfiere un documento. Luego, el receptor debe pedir los documentos relacionados segn necesidades. Si el documento se firma con Firma Electrnica Avanzada, la aplicacin de firma debe pedir todos los documentos antes de generar una representacin del objeto a firmar. Esto en el caso de que los adjuntos sean parte de los datos que se requiere firmar. Requiere de un repositorio permanentemente disponible y de simple acceso, especialmente cuando se intercambian estos documentos XML. Requiere una gestin de cambios de los adjuntos y permanencia de todas las versiones en un repositorio. Si un documento en formato XML firmado con Firma Electrnica Avanzada apunta a adjuntos en un repositorio, al momento de verificar la firma electrnica 2 aos despus de su creacin, los adjuntos a los cuales apunta el XML deben ser los originales, originales no modificados.
Formato de adjuntos en Servicios Web En el proceso de intercambio de informacin entre instituciones, se debe resolver el problema de transferir un expediente de documentacin asociado a un proceso de negocio. Este intercambio de informacin actualmente se realiza realiza a travs de Servicios Web con estructura SOAP. La estructura SOAP es un documento XML, donde se pueden incluir otro documento XML como parte del SOAP o como archivo binario.
En un mensaje SOAP, se ocupa la misma tcnica de incorporacin del archivo binario bin en formato Base64binary como se indic anteriormente. Este mtodo es el mismo que utilizan los servidores de correo cuando transfieren los archivos adjuntos de un email, , dicha transformacin se hace a nivel del servidor y es transparente al nivel del usuario. Al nivel de la interfaz del servicio Web, se pueden especificar los mtodos de envo que optimizan el mensaje cuando contiene archivos. Los estndares de optimizacin de transferencia de archivos binarios han ido evolucionando para incorporar compatibilidad con los estndares de Web Services.
Cronolgicamente, los estndares de transferencia de archivos en servicios Web SOAP son: x x x x x SOAP Messages with Attachments (SwA) Direct Internet Message Encapsulation (DIME) WS-Attachments XML-binary binary Optimized Packaging (XOP) SOAP Message Transmission Optimization Mechanism (MTOM)
Se sugiere utilizar el estndar MTOM por las siguientes caractersticas: x x x x MTOM optimiza la transferencia de binarios (de tipo base64Binary en el XML) MTOM es un mecanismo implementado al nivel del servicio Web (en la prctica, es el servidor que se encarga de implementar MTOM). MTOM opera al nivel de la transmisin del mensaje, eso es, entre el servicio web SOAP y el consumidor del servicio web. MTOM serializa el mensaje en formato MIME Multipart/Related utilizando XOP. XOP
Laboratorio: Adjuntos explcitos en Servicios Web Objetivo

Visualizar el funcionamiento de los adjuntos en los servicios web.
Enunciado
Vamos a realizar un nuevo proyecto en el que enviaremos una imagen dentro del documento XML. El servicio web ser algo muy sencillo, simplemente devolveremos el texto que hace referencia a un fichero adjunto dentro de una pgina web. Para ello, nos crearemos una nueva tabla en la que tendremos los datos datos de unos usuarios y las referencias http de dnde estn ubicadas sus imgenes. Recibiremos el dato del usuario y devolveremos en el servicio la direccin http dnde est ubicada su imagen.
Debemos realizar la siguiente base de datos para poder acceder a los datos de los usuarios: CREATE TABLE USUARIOS (ID_USUARIO INT , USUARIO VARCHAR2(30) , DIRECCIONIMAGEN VARCHAR2(200)); insert into usuarios values (1,'Xabi Alonso','http://3.bp.blogspot.com/Alonso','http://3.bp.blogspot.com/ DHheOC5uJKg/TZkK3VFRzuI/AAAAAAAAAJg/dALQcYUax4I/_ s1600/xabi-alonso-real-madrid.jpg'); insert into usuarios values (2,'Villa','http://www.noticias112.com/wp(2,'Villa','http://www.noticias112.com/wp content/uploads/2010/06/07_Villa_espana_rusia_celebracion_2.jpg'); insert into usuarios values (3,'Casillas','http://4.bp.blogspot.com/_(3,'Casillas','http://4.bp.blogspot.com/_ Fo2nyMBaH8/TC_Ad1obWyI/AAAAAAAAAqQ/V C_Ad1obWyI/AAAAAAAAAqQ/V-J7aScm8Hc/s1600/_ Casillas_987861.jpg'); insert into usuarios values (4,'Iniesta','http://www.experienciapersonal.es/wp(4,'Iniesta','http://www.experienciapersonal.es/wp content/uploads/2010/07/Gol-de-Iniesta.jpg'); Iniesta.jpg'); COMMIT; A continuacin, nos crearemos un nuevo proyecto en Netbeans Netbeans de tipo Web Application.
Llamaremos al proyecto ProyectoAdjuntos
Utilizaremos el servidor de aplicaciones GlassFish y no utilizaremos Frameworks. Sobre el proyecto, vamos a agregar la librera para trabajar con Oracle.
Sobre el proyecto vamos a agregar un nuevo Servicio Web
Lo llamaremos ServicioAdjuntos
Aadimos un mtodo que recibir el Id del usuario y devolver la direccin del adjunto explicito.
Tambin crearemos un mtodo para poder devolver el el nombre del usuario a travs de su ID. El cdigo del Servicio Web quedar de la siguiente forma: package paquete; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService; import java.sql.*; @WebService() public class ServicioAdjuntos { public enum TipoConsulta { NOMBREUSUARIO, DIRECCIONIMAGEN }; @WebMethod(operationName = "datosUsuarios") public String datosUsuarios(@WebParam(name = "idusuario") int idusuario) { return this.getDato(idusuario, TipoConsulta.DIRECCIONIMAGEN); } @WebMethod(operationName = "nombreUsuarios")
public String nombreUsuarios(@WebParam(name = "idusuario") int idusuario) { return this.getDato(idusuario, TipoConsulta.NOMBREUSUARIO); Tip } private String getDato(int idusuario, TipoConsulta tipo) { try { DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver()); Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system", DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system", "java"); Statement stmt = conn.createStatement(); String consulta; consulta = "SELECT * FROM USUARIOS WHERE ID_USUARIO=?"; PreparedStatement smt = conn.prepareCall(consulta); conn.pre smt.setInt(1, idusuario); ResultSet rs = smt.executeQuery(); rs.next(); String dato=""; if (tipo == TipoConsulta.NOMBREUSUARIO) { dato = rs.getString("USUARIO"); }else { dato = rs.getString("DIRECCIONIMAGEN"); } rs.close(); return dato; }catch (Exception ex) { return ex.getMessage(); } } } Una vez que lo tengamos, ser el momento de probar el servicio y su funcionamiento:
Si invocamos el servicio, comprobaremos que el dato es devuelto:
Y el adjunto va en la respuesta XML del servicio
Unidad 6: Explicando el lenguaje de Servicios Web (WSDL)

Objetivos
x x x Aprender los conceptos de fundamentales de los documentos WSDL. Conocer la estructura de cualquier documento WSDL dentro de los Servicios Web. Visualizar la relacin de los esquemas XSD con los Servicios Web.
Introduccin
s un protocolo basado en XML que describe los accesos al Web Service. WSDL es Podriamos decir que es el manual de operacin del web service, porque nos indica cuales son las interfaces rfaces que provee el Servicio web y los tipos de datos necesarios para la utilizacin del mismo. WSDL es el lenguaje propuesto por el W3C para la descripcin de Servicios Web y permite describir la interfaz de un servicio web en un formato XML. Una de las ventajas de WSDL es que permite separar la descripcin abstracta de la funcionalidad ofrecida por un servicio, es decir, de los detalles concretos del mismo, como puede ser el enlace a un protocolo de red o un formato de mensaje concreto que puede ser SOAP, HTTP o MIME. MIME WSDL describe los servicios Web a travs de los mensajes que se intercambian entre el proveedor del servicio y el cliente. El intercambio de mensajes se define mediante operaciones. Una coleccin de operaciones forma un tipo de puerto. Un tipo de puerto constituye la descripcin completa de la interfaz del servicio de manera abstracta. Esta descripcin abstracta es unida luego a un formato de mensaje concreto, lo cual permite describir una interfaz concreta del servicio. Cada servicio contiene uno o varios puertos y cada ada puerto indica la localizacin de la interfaz concreta del servicio. Podemos visualizar los elementos de un documento WSDL en la siguiente figura:
Un documento WSDL contiene ntiene un nmero de versin y un componente raz Definition, Definition que posee un nombre, Name y un atributo TargetNameSpace, que declara el espacio de nombres al que pertenecern todos los nombres de componentes definidos en el documento. Un componente Definition puede contener un componente Types y, , adems podr contener uno, cero o ms componentes Message, Porttype, Porttype Binding, Service e import. Todos los componentes de WSDL pueden tener asociado un componente Documentation. Documentation Un componente Types se utiliza para la definicin de los tipos de datos que sern necesarios para el envo de mensajes. a en el estndar XML Schema. Schema Para esta definicin, WSDL se basa Por ello contiene un componente Schema y asociado a ste, componentes Element que describen cada uno de los tipos de datos, de acuerdo al estndar de los esquemas XML. WSDL permite incluir documentos XML Schemas definidos definido previamente y para ello utiliza un componente Include, , a travs del cual se indica la localizacin del documento. De la misma forma, un componente Import se utiliza para reutilizar definiciones hechas en otros documentos WSDL, indicando el nombre y localizacin del documento que se desea importar. El componente PortType se utiliza para describir el conjunto de mensajes que sern intercambiados interc entre el proveedor del servicio y el cliente. Los mensajes se agrupan en operaciones, es decir, etiquetas Operation. Cada operacin contiene un nombre y puede tener uno, dos o tres mensajes asociados, es decir, un mensaje de entrada, mensaje de salido o los dos al mismo tiempo, tiempo, y opcionalmente, opcionalmente un mensaje de excepcin. Un mensaje est definido con la etiqueta message y contiene una definicin similar a la de una funcin, contiene un nombre y parmetros con la etiqueta Part. Part El tipo asociado a un Part puede ser un tipo base XSD de los esquemas XML (int, float, string, etc.) o un tipo definido en la seccin de tipos creados en el propio Servicio Web y enviado en ste. ste En este ltimo caso, el tipo de dato puede ser asociado a travs de un atributo atribut type o element, dependiendo del tipo de dato que se desea asociar.
El componente PortType describe completamente la interfaz del servicio de manera abstracta. El componente Binding describe un formato de mensaje y protocolo de transmisin concretos (SOAP, (SOAP HTTP o MIME) para el enlace con un componente PortType. WSDL define diferentes componentes para describir describir cada uno de estos protocolos. protocolos El componente Port define el punto concreto de acceso al servicio. Contiene un nombre y combina un componente Binding con la direccin donde se accede a la implementacin del servicio. , contiene un nombre, que ser el nombre del servicio y uno o varios Por ltimo, el componente Service, puertos, , con la etiqueta Port, asociados. Un ejemplo de documento WSDL es el siguiente: siguie <?xml version="1.0"> <definitions> <types> ... </types> <message> ... </message> <portType> ... </portType> <binding> ... </binding> </definitions> En esta tabla podemos visualizar el significado de cada elemento dentro del documento WSDL anterior. Elemento WSDL <?xml version="1.0"> Descripcin Un documento WSDL es como cualquier documento xml y se basa en los esquemas, por lo que debe comenzar con el tag
<definitions>
Comienzo del documento, este tag agrupa a todos los dems elementos
<types>
Se definen los tipos de datos utilizados en el Web Service
</types>
Fin de la definicin de tipos
<message>
Se definen los mtodos y parmetros para realizar la operacin.
Cada message puede consistir en una o (parmetros). </message> <portType> Fin de la definicin de los parmetros
ms partes
Esta seccin es la ms importante, ya que se definen las operaciones que pueden ser realizadas, y los mensajes que involucran (por ejemplo el mensaje de peticin y el de respuesta).
</portType> <binding>
Fin de la definicin de las operaciones y mensajes Se definen el formato del mensaje y detalles del protocolo para cada portType. Fin de la definicin del formato del mensaje y detalles del protocolo para cada PortType
</binding>
Utilizacin de WSDL en los Servicios Web

En la estructura de cualquier Servicio Web, el fichero WSDL se basa en enviar la informacin y los mensajes de entrada y respuesta al cliente que realiza la peticin.
Los pasos que se realizan al consumir el servicio son los siguientes: 1) Lo primero que realiza el cliente al hacer una solicitud al servicio es tomar la definicin del archivo WSDL. 2) El servidor entrega el fichero WSDL. Este archivo indica a la peticin los mtodos y propiedades de ese servicio que estn disponibles. 3) El cliente hace la peticin en el formato que espera el servidor segn las especificaciones del fichero WSDL en el que se dice qu parmetros acepta y de qu tipo. 4) El servidor entrega el resultado de la consulta.
El fichero WSDL es del tipo XML por eso su primera lnea ser la siguiente:
<?xml version="1.0" ?> A continuacin se escriben las definiciones en la que se establece el namespace al que pertenece cada uno de los formatos XML que usamos. Un fichero tipo WSDL pertenece al namespace http://schemas.xmlsoap.org/wsdl/ El cdigo estructurado quedara de la siguiente forma: <?xml version="1.0" ?> <definitions xmlns="http://schemas.xmlsoap.org/wsdl/"> </definitions> Tambin nos podemos encontrar con la posibilidad de que el Servicio Web introduzca el nombre del propio servicio en el momento de crear el WSDL, de forma que tambin podramos verlo asi: <?xml version="1.0" ?> <definitions name="MiServicioWeb xmlns="http://schemas.xmlsoap.org/wsdl/"> </definitions> En realidad, la definicin de un servicio no se realiza sobre la definicin, definicin, sino que se utiliza la etiqueta service para indicar el nombre del servicio, depende de la antigedad del servicio y de la tecnologa que se haya utilizado para crearlo. Cualquier servicio SOAP quedara con la siguiente estructura: <?xml version="1.0" ?> <definitions name=" MiServicioWeb xmlns="http://schemas.xmlsoap.org/wsdl/"> <service name="MiServicioWeb"> </service> </definitions> Dentro del arbol del Servicio se puede abrir otra etiqueta para incluir una descripcin del servicio. servicio <?xml version="1.0" ?> <definitions name="MiServicioWeb xmlns="http://schemas.xmlsoap.org/wsdl/"> <service name=" MiServicioWeb "> <documentation>Este es un servicio que muestra el factorial de un nmero. </documentation> </service> </definitions>
En el momento de trabajar con Servicios Web, dicho servicios van alojados en puertos, dnde se indicar la direccin del servicio y el tipo de acceso. Estos puertos junto a la direccin propiamente dicha tienen que tener un nombre. nombre. <?xml version="1.0" ?> <definitions name="MiServicioWeb xmlns=http://schemas.xmlsoap.org/wsdl/ xmlns:soap=http://schemas.xmlsoap.org/wsdl/soap/ > <service name="MiServicioWeb"> <documentation>Este es un servicio que muestra el factorial de un nmero. </documentation> <port name="MiServicioWebPort"> <soap:address location="http://localhost:8082/MiServicio/Servicio1.wsdl" />
</port> </service> </definitions> Un Servicio Web no tiene que estar obligatoriamente obligatoriamente expuesto mediante el uso de SOAP, tambin se puede exponer mediante el protocolo HTTP GET, en este caso el elemento contendra un con un cdigo de la siguiente forma: http:address location="http://localhost:8082/MiServicio/wsdl/Servicio.jsp"/ Los mtodos y parmetros de recepcin y entrega de informacin se envan en elementos con la etiqueta message. todos se llaman Mensajes y, normalmente, n suele haber dos mensajes, uno de entrada y otro de Los mtodos salida, aunque las posibilidades de definir estrucuturas complejas por parte de cada uno de ellos es bastante amplia. Si tuviramos un mtodo llamado getDatos() que recibe un parmetro String con el apellido en el Servicio Web, la forma de e definirlo sera la siguiente: La definicin del mtodo de entrada sera la siguiente: <message name="getDatosRequest"> <part name="Apellido" type="xsd:string" /> </message> Y la definicin para el mtodo de salida sera tambin parecida a la siguiente: siguiente <message name="getDatosResponse"> <part name="return" type="xsd:string" /> </message> Todos los parmetros que utilizamos en nuestro ejemplo utilizan datos de la clase String, tanto en la entrega como en la devolucin, pero podramos haber utilizado cualquier tipo de dato definido en la estructura de Schemas XML. <part name=numero type='xsd:int'/> <part name='resultado' type='xsd:float'/> Los tipos de datos que podemos definir en un XSD (Schema XML) son los mismos que podemos incluir en cualquier alquier WSDL. Algunos tipos de datos ms comunes dentro de los esquemas XSD son los siguientes, con su transformacin al tipo de dato correspondiente en Java:
XSD Schema XML anyURI base64Binary boolean byte date double
Tipo dato Java String byte[] boolean int java.util.Date double
float
float
int string long
int String long
Tambin podemos definir clases que sean devueltas en el servicio. Dichas clases devolvern al final de todo, tipos de datos primitivos. Tenemos que tener en cuenta que en el momento de definir las devoluciones de parmetros dentro de un Servicio Web, debemos devolver siempre tipos primitivos, ya que cualquier lenguaje podr leerlos independientemente del lenguaje en el que se haya construido. construi Aunque devolvamos clases personalizadas por nosotros, dichas clases devolvern primitivos en sus mtodos y propiedades. Si devolvierarmos, por ejemplo, un objeto ResultSet de java, Visual Studio Net no sera capaz de traducirlo aunque viniera escrito to en el esquema WSDL. Lo que nos quedara para comprender completamente la estructura de los documentos WSDL es la definicin de los parmetros de entrada y salida en los mensajes. Para poder indicar si los parmetros son input o output, se utiliza la etiqueta eti el input message y el message de output. El cdigo sera de la siguiente forma: forma <operation name="getDatos"> <input message="namespace:getDatosRequest" /> <output message="namespace:getDatosResponse" /> </operation> El valor de namespace va incluido en la cabecera de la definicin del servicio. La coleccin de todas las operaciones (mtodos) expuestos por un servicio se llama portType y se definen dentro de WSDL con la etiqueta <portType name="MiServicioWebPortType"> <operation name="getDatos"> <input message="namespace:getDatosRequest" /> <output message="namespace:getDatosResponse" /> </operation> </portType> Para acabar con la definicin de un fichero WSDL, solo quedara el Binding, , que es el enlace que establece la transicin n desde tipos de datos abstractos a tipos de datos concretos. <binding name="MiServicioWebBinding" type="namespace:MiServicioWebPortType"> <soap:binding style="rpc" transport="http://schemas.xmlsoap.org/soap/" /> <operation name="getDatos"> <soap:operation soapAction="url:localhost:8082#MiServicioWeb" /> <input> <soap:body use="encoded" namespace="url:localhost:MiServicioWeb" , dnde se indica
encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </input> <output> <soap:body use="encoded" namespace=" url:localhost:MiServicioWeb" encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" /> </output> </operation> </binding> Despus de analizar todo el contenido de los mensajes WSDL generados por un Servicio Web, habr quedado claro el contenido de WSDL, pero gracias a los editores tales como NetBeans o Eclipse, no es necesario generar un WSDL, sino que bastara con crear el Servicio y el propio editor nos crear el fichero wsdl asociado a dicho servicio. Vamos a visualizar un ejemplo en el que mostraremos el contenido de un WSDL cuando devolvamos una clase creada por nosotros y devuelta en el servicio. Nos creamos un nuevo proyecto Web en NetBeans:
Lo llamaremos AgendaContactos
Utilizaremos el servidor GlassFish y no utilizaremos Frameworks.
Vamos a realizar una sencilla aplicacin en la que tendremos una Clase llamada Contacto. Los contactos estarn formados por un nombre, un identificador y un nmero de tlefono. Devolveremos los datos de un contacto en un mtodo en el que recibiremos su identificador. Comenzamos creando la clase Contacto:
Implementaremos el siguiente cdigo: package paquetews; public class Contacto { private int IdContacto; private String Nombre; private int Telefono; public int getIdContacto() { return IdContacto; } public void setIdContacto(int idcontacto) { this.IdContacto = idcontacto; } public String getNombre() { return Nombre; } public void setNombre(String nombre) { this.Nombre = nombre; } public int getTelefono() { return Telefono; } public void setTelefono(int telefono) { this.Telefono = telefono; } } Ahora nos crearemos un nuevo Servicio Web llamado ServicioContactos
Nos crearemos una operacin llamada getContacto()
Incluiremos el siguiente cdigo en el servicio: package paquetews; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService; import java.util.*; @WebService() public class ServicioContactos { ArrayList<Contacto> listacontactos = new ArrayList<Contacto>(); public ServicioContactos() { Contacto c = new Contacto(1, "Lucia", 917654455); this.listacontactos.add(c);
c = new Contacto(2, "Adrian", 687564333); this.listacontactos.add(c); c = new Contacto(3, "Ana", 789776655); this.listacontactos.add(c); c = new Contacto(4, "Carlos", 12345678); this.listacontactos.add(c); c = new Contacto(5, "Pedro", 4567899); this.listacontactos.add(c); c = new Contacto(6, "Raul", 677554433); this.listacontactos.add(c); } @WebMethod(operationName = "getContacto") public Contacto getContacto(@WebParam(name = "idcontacto") int idcontacto) { Contacto c = this.listacontactos.get(idcontacto); return c; } } Al visualizar el WSDL resultante, veremos que tenemos el siguiente resultado:
Y como podemos odemos visualizar, la respuesta SOAP en el cliente devolver los tipos de datos primitivos que son los datos de un contacto buscado.
Ver Video: Crear Servicio Web a partir de documento WSDL, en el Mdulo 7. Unidad 6, en la plataforma elearning
Laboratorio: Servicio Web Datos de Empleados Objetivo

Conocer el funcionamiento de los Servicios Web utilizando clases personalizadas y bases de datos.
Enunciado
Vamos a realizar un laboratorio en el que crearemos una clase Empleado y la devolveremos con los datos de los empleados que encontremos en la base de datos a partir de un mtodo. Buscaremos los empleados por su nmero de departamento. Crearemos un nuevo proyecto royecto web.
Llamaremos al proyecto ProyectoEmpleados Utilizaremos el servidor de aplicaciones GlassFish y no utilizaremos Frameworks. Sobre el proyecto, vamos a agregar la librera para trabajar con Oracle.
Ahora nos crearemos una nueva clase llamada llam Empleado
Implementaremos los atributos de un empleado y los mtodos getter y setter de cada atributo. La clase quedar de la siguiente forma: package paquetews; public class Empleado { private String nombre; private String oficio; private int salario; private int departamento; public Empleado() { this.nombre = ""; this.oficio = ""; this.salario = 0; this.departamento = 0; } public Empleado(String nombre, String oficio, int salario, int departamento) { this.nombre = nombre; this.oficio = oficio; this.salario = salario; this.departamento = departamento; } public String getNombre() { return nombre; } public void setNombre(String nombre) {
this.nombre = nombre; } public String getOficio() { return oficio; } public void setOficio(String oficio) { this.oficio = oficio; } public int getSalario() { return salario; } public void setSalario(int salario) { this.salario = salario; } public int getDepartamento() { return departamento; } public void setDepartamento(int departamento) { this.departamento = departamento; } } Ahora nos crearemos el Servicio Web. Sobre el proyecto vamos a agregar un nuevo Servicio Web
Lo llamaremos ServicioEmpleados
Aadimos un mtodo que recibir el Id del departamento y devolver los empleados que pertenecen a dicho departamento en objetos de la clase Empleado.
El cdigo del Servicio Web quedar de la siguiente forma: package paquetews; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService; import java.util.*; import java.sql.*; @WebService() public class ServicioEmpleados { @WebMethod(operationName = "getEmpleados") public Empleado[] getEmpleados(@WebParam(name = "iddepartamento") int iddepartamento) { try { ArrayList<Empleado> listaempleados = new ArrayList<Empleado>(); DriverManager.registerDriver(new oracle.jdbc.driver.OracleDriver()); Connection conn = DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system", DriverManager.getConnection("jdbc:oracle:thin:@localhost:1521:XE","system", "java"); Statement stmt = conn.createStatement(); String consulta; consulta = "SELECT ENAME, JOB, SAL, COMM, DEPTNO FROM EMP WHERE DEPTNO=?"; PreparedStatement smt mt = conn.prepareCall(consulta); smt.setInt(1, iddepartamento); ResultSet rs = smt.executeQuery(); while (rs.next()) { Empleado emp = new Empleado(); emp.setNombre(rs.getString("ENAME")); emp.setOficio(rs.getString("JOB")); emp.setSalario(rs.getInt("SAL"));
emp.setDepartamento(rs.getInt("DEPTNO")); listaempleados.add(emp); } rs.close(); int longitud = listaempleados.size(); Empleado arrayempleados[] = new Empleado[longitud]; listaempleados.toArray(arrayempleados); return arrayempleados; }catch (Exception ex) { System.out.println("Excepcion: " + ex); return null; } } } Una vez que lo tengamos, ser el momento de probar el servicio y su funcionamiento:
Si i invocamos el servicio, comprobaremos que los datos de los empleados son devueltos:
Si nos fijamos en el documento WSDL, veremos los mensajes de Empleado en las etiquetas message:
Unidad 7: Reconociendo el papel de los servicios de registro

Objetivo
Conocer el funcionamiento de los directorios UDDI dentro de la tecnologa de los Servicios Web.
Introduccin
Los Servicios Web en Internet estn tomando cada vez ms importancia. Se disean como sistemas transparentes de informacin que ocultan la complejidad de los sistemas finales y permiten una fcil comunicacin. Los problemas que existen en el mundo de los Servicios Web no son su creacin ni su implementacin final, problemas que se pueden resolver con sintaxis del lenguaje e implementaciones implementacion de cdigo de los Servicio y con la documentacin propia del lenguaje creador del servicio. Su principal problema es el descubrimiento. Lo que quiere decir al final, es que existen multitud de Servicios Web en internet, pero si no estn ubicados en ningn ningn lugar ni en ningn buscador, es difcil descubrirlos. De ah naci UDDI (Description Discovery And Integration), que es una especie de localizador dnde se pueden especificar las descripciones de los servicios web y su localizacin en internet. Es algo lgo fundamental tener un medio de localizar esos servicios, tarea ms difcil conforme crece el nmero de servicios disponibles. Si quiero buscar Servicios Web en internet, tendr que utilizar la tecnologa UDDI para poder acceder a la informacin que necesito sito encontrar. De esta forma, si tuviramos varios Web Services tales como: x x x Estado de tiempo Descripcin de productos comerciales, Operaciones de transacciones financieras
Sera posible publicarlos a un directorio UDDI, permitiendo que sean descubiertos descubierto en un directorio conocido y centralizado.
Directorio UDDI (Description Discovery and Integration)

UDDI apareci en el entorno tenolgico con la intencin de centralizar web services comunes, as como ofrecer un deposito central donde se puede acudir a realizar bsquedas de web services especficos. UDDI ha sido desarrollado por un grupo de empresas entre las que figuran principalmente Microsoft, IBM y SAP, estas compaias as como algunos otros consorcios se encargan de mantener y ofrecer este tipo de servicios en Internet. UDDI es uno de los estndares bsicos de los servicios Web cuyo objetivo es ser accedido por los mensajes SOAP y dar paso a documentos WSDL, en los que se describen los requisitos del protocolo y los formatos del mensaje solicitado para ara interactuar con los servicios Web del catlogo de registros. La especificacin UDDI simplifica la tarea de publicacin de Web Services, permitiendo a una organizacin publicar informacin sobre los servicios que ofrece y localizar informacin sobre servicios ser web que necesita utilizar. UDDI describe el interfaz externo de un Web Service y como debera ser utilizado. Podemos definir un archivo WSDL como un documento XML que describe un conjunto de mensajes SOAP y la forma en que stos se intercambian. Puesto sto que la notacin que utiliza WSDL es XML, esto significa que es un idioma de programacin neutral, basado en estndares (W3C) y que puede utilizarse desde una gran variedad de plataformas y lenguajes. Un servicio UDDI, adems de describir el contenido WSDL, WSDL, define todos los elementos necesarios para utilizar el servicio, es decir, interfaz, lugar en el que est disponible, protocolo de comunicaciones, etc. UDDI es, simplemente, un repositorio de documentos XML con sus Schemas XML que define un mensaje SOAP AP para el registro y peticin de informacin. Un fichero de registro es un documento XML-UDDI XML UDDI que consta de tres elementos principales: x Pginas blancas: Indican la direccin, contactos, e identificadores de empresa la empresa que ofrece el Servicio Web.
x x
Pginas ginas amarillas: Ofrecen la categora industrial basada en la estructura propuesta por el repositorio UDDI. Pginas verdes: Contienen la informacin tcnica que describe los servicios web.
Caractersticas de los directorios UDDI

x x x x x x UDDI es un sistema ideado para describir servicios, junto con WSDL, y localizar empresas que ofrezcan estos servicios. UDDI significa Descripcin, Localizacin e Integracin Universales. Es un directorio para almacenar informacin sobre servicios web. Entre otras caractersticas, caracterstica guarda las interfaces de esos servicios descritas en el documento WSDL. UDDI utiliza SOAP para llevar a cabo las comunicaciones. Est desarrollado e integrado en la plataforma .NET de Microsoft. UDDI ha sido propuesto por Dell, Fujitsu, HP, Hitachi, IBM, IBM, Intel, Microsoft, Oracle, SAP y Sun, entre otros fabricantes.
Gracias al directorio UDDI, podemos realizar una sera de operaciones que nos sera imposible sin tener un repositorio de Web Services: x x x x x Podemos descubrir la empresa ms adecuada a nuestra lgica de negocio de entre las muchas presentes en Internet. Podemos obtener informacin sobre cmo contactar con esa empresa Conseguir nuevos clientes y facilitar el acceso a los actuales Incremento de los servicios ofertados y extendiendo el mercado al que que se puede acceder Describir servicios y procesos empresariales en un entorno seguro y fcil de utilizar.
Un ejemplo de cmo se podra utilizar el repositorio UDDI sera el siguiente: Pongamos un ejemplo en el que se creara un estndar UDDI para reserva y venta de entradas de cine. Los cines podran registrar sus servicios en un directorio UDDI siguiendo ese estndar e interface UDDI. De esta forma, las pginas web de reserva de entradas online, podran obtener acceso al repositorio UDDI a travs de la interfaz, nterfaz, y podran comunicarse con el servicio ofrecido por cualquier cine para hacer las reservas y ventas de entradas, manteniendo la misma estructura para todos. La estructura de UDDI para acceder a los servicios como para publicarlos es la siguiente:
El Servicio UDDI contiene seis entidades:
x x x x x x x x x x x
Provider Persona, grupo u organizacin que ofrece una serie de Servicios Web XML. Contact Persona de contacto para informar sobre los temas relacionados con los Servicios del proveedor correspondiente. Service El propio Servicio Web Binding El punto de acceso al Servicio Web o URL del Servicio. Instace info Referencia a un tModel que contiene informacin tcnica relevante sobre un Binding. tModel
Informacin tcnica sobre la interfaz, incluida dentro del documento docum WSDL. Tambin puede representar una unidad organizativa con datos descriptivos, como un identificador.
Otros Repositorios de Servicios Web

ebXML es otro tipo de registro para Web Services que surgi previo a UDDI y fue desarrollado por OASIS ("Organization for the Advancement of Structured Information Standards") asi como la divisin de las Naciones Unidas CEFACT ("United Nations Centre for the Facilitation of Procedures and Practices in Administration, Commerce and Transport"). nsport"). Para accesar un directorio UDDI o ebXML generalmente se utiliza cualquier navegador de internet para dar de alta los respectivos web services por lo que su uso es relativamente sencillo. Aunque un Navegador sea la forma clsica de acceder a los Directorios Directorios para web services, existen otros mecansimos como JAXM ("Java API for XML Registries") que permiten el acceso a este tipo de directorios de una manera programtica.
WSIL-Web Web Service Inspection Language

WSIL es una especificacin muy reciente iniciada iniciada por IBM y Microsoft que ofrece un mecanismo complementario a UDDI y ebXML para encontrar web services en una red como Internet. Existen dos razones principales por las que surgi WSIL: x Falta de Moderacin: Debido a la misma escalabilidad con la que fue diseado UDDI, existe una clara falta por moderar los web services que son publicados en este tipo de Directorios, lo anterior trae consigo la publicacin de "Web Services Description Language/(WSDL)" invalidos, la duplicidad de WSDL e incluso la publicacin publicacin de Servicios Web que no estn disponibles. Falta de Calidad de Servicio (QoS) : Este punto aunque relacionado con el anterior se refiere a la garantia del servicio ofrecido por el proveedor del web service, esto es, debido a que UDDI es un directorio o pblico en Internet, nadie garantiza que el web service utilizado o comprado cumpla con determinados requisitos.
Esto nos lleva al antiguo concepto de negocios: Comprar o adquirir a quien ya conocemos, y es precisamente en este principio en el que esta basado WSIL.
A diferencia de UDDI donde se realizan busquedas en un directorio centralizado, mediante WSIL se inspecciona un "Web-Server" Server" conocido realizando una bsqueda por web services y es mediante archivos escritos en WSIL que se logra su descubrimiento. descubrimie
Sin embargo, es tan reciente dicha especificacin que sus implementaciones son minimas.
Publicacin de Servicios Web en UDDI

Actualmente los servicios UDDI estn desapareciendo de las pginas debido a alojamientos Web que contienen toda la informacin in sobre servicios y se han especializado en bsquedas y alojamiento sin utilizar la tecnologa de directorio, por lo que pondremos este caso a modo de informacin en la unidad. Otra de las razones del desgaste en su uso es la falta de control de los servicios, ser adems de la aparicin de nuevas tecnologas en el momento de la creacin de Servicios Web como son los Servicios RestFul, que son servicios que no utilizan protocolo SOAP. Si queremos descubir sitios web SOAP, existen multitud de sitios que se han especialidado en exponer servicios web y su disponibilidad, tales como: http://webservices.seekda.com/ La publicacin en UDDI es un proceso relativamente sencillo. El primer paso consiste en determinar informacin bsica sobre cmo definir la empresa y los l servicios en UDDI. El siguiente paso, una vez determinada esta informacin, consiste en llevar a cabo el registro, ya sea mediante programacin o a travs de una interfaz de usuario basada en el Web. Por ltimo, se debe probar la entrada para asegurar que se registr correctamente y que aparece tal y como se esperaba en diferentes tipos de bsquedas y herramientas. Definir la entrada de UDDI Partiendo del modelo de datos descrito anteriormente, se debe recopilar cierta informacin importante antes de establecer una entrada de UDDI. Determinaremos los tModels (archivos WSDL) que utilizan las implementaciones del servicio Web. Al igual que sucede ede en el desarrollo de un componente COM, el servicio Web se ha desarrollado a partir de una interfaz existente o de una interfaz de diseo propio. En el caso de un servicio Web basado en una interfaz WSDL existente, deberemos determinar si el archivo WSDL DL se ha registrado en UDDI. Si es as, debemos comprobar su nombre y tModelKey, que es el identificador GUID que gener UDDI cuando se produjo el registro. Si el servicio Web se basa en un archivo WSDL que no se ha registrado en UDDI, debermos crear un nuevo tModel para representar esta interfaz.
El nombre de este tModel debera tener un formato URI (identificador de recursos uniforme), como MiEmpresa-com:EjemploWebService com:EjemploWebService-interface:v1, interface:v1, y sealar la ubicacin del archivo WSDL. Si el servicio Web es un servicio de Microsoft Visual Studio .NET, podremos generar una descripcin WSDL utilizando una cadena de consulta desde el archivo .ASMX. No obstante, el archivo WSDL generado por Visual Studio .NET se relaciona estrechamente con el punto de acceso para la a invocacin del servicio Web, lo cual puede no resultar adecuado cuando la interfaz del servicio tiene varias implementaciones.
Determinaremos el nombre de la empresa y una breve descripcin de la misma en varios idiomas, si es necesario, as como los contactos ontactos principales para los servicios Web que ofrece. UDDI es compatible con el espacio de nombre xml:lang, lo que permite a las empresas ofrecer su descripcin en varios idiomas. Asimismo, UDDI permite enumerar los contactos, incluyendo datos como el correo electrnico, el telfono y la direccin. Esta lista de contactos muestra los recursos de una empresa con los que se puede poner en contacto en relacin con los servicios Web ofrecidos. Por ejemplo, si un usuario desea comenzar a utilizar el servicio servicio Web deber ponerse en contacto con el responsable de relaciones comerciales correspondiente pero, cmo puede llegar a saber quin es? Existe algn contacto para obtener asistencia tcnica a la hora de utilizar los servicios Web de la empresa? Tambin se debera incluir en la lista a esta persona. Resulta importante destacar que no todo el mundo puede obtener acceso a un servicio Web porque ste se haya registrado en UDDI. A una entrada de registro UDDI le pueden acompaar medidas de seguridad, autorizacin autori y autenticacin. No basta que el usuario sepa que existe un servicio Web para que pueda invocarlo. Puede existir una comunicacin fuera de banda entre empresas antes de permitir el acceso a un servicio Web. Registrar la entrada de UDDI Una vez finalizada nalizada la tarea de definicin, el siguiente paso consiste en registrar la empresa. Debemos obtener una cuenta con un registro UDDI. Esta operacin no se puede realizar mediante programacin, ya que deberemos mostrar nuestra conformidad con una declaracin in de condiciones de uso. El nodo de Microsoft utiliza Passport para la autenticacin, as que debemos adquirir una cuenta de Passport (http://www.passport.com/Consumer/default.asp) para continuar con el registro. En este punto se ofrecen dos opciones: podemos utilizar la interfaz de usuario Web del nodo o realizar el registro mediante programacin dirigiendo al propio nodo las llamadas a API de SOAP. Si no pensamos modificar la entrada o sta es relativamente simple, bastar con la interfaz de usuario Web. No obstante, si pretemos actualizar la entrada con frecuencia, o bien, sta es ms compleja, resulta recomendable realizar el proceso de registro con secuencias de comandos. Buscar la entrada en UDDI
Es recomendable realizar tres comprobaciones una una vez registrada la entrada en UDDI.
En primer lugar, utilizando la interfaz de usuario Web. bsqueda de los Servicios Web en el registro UDDI.
Existen multitud de pginas que realizan la
Debemos buscar la empresa por su nombre y categorizaciones para verla entre los conjuntos de resultados devueltos. En segundo lugar, utilizaramos la herramienta de NetBeans para crearnos clientes para Servicios Web. Bastara con hacer una referencia en el e proyecto al archivo WSDL. UDDI y WSDL funcionan como especificaciones gratuitas que facilitar el desarrollo de una coleccin de software basado en servicios Web. WSDL ofrece un modo formal de definir servicios Web, independientemente del proveedor, que permitir realizar llamadas a procedimientos remotos de prxima generacin, mientras que UDDI proporciona una amplia infraestructura estandarizada que permite al usuario describir y descubrir servicios Web. Mediante la combinacin de estos dos estndares, estndares, se podr desarrollar todo un universo de servicios Web
Ver Video: Test Web Service UDDI, en el Mdulo 7. Unidad 7, en la plataforma elearning
Unidad 8: Implementando servicios web mediante Java API para servicios web XML usando la tecnologa (JAX-WS) (JAX
Objetivos
x x Entender el funcionamiento de los servicios web utilizando JAVA-WS. JAVA Creacin y estructura de un Servicio Web JAVA-WS JAVA
Introduccin
Un servicio icio es un procedimiento, un mtodo m o un objeto con una interfaz estable y pblica p que puede ser invocado por un cliente. Los Servicios Web amplian esa idea para permitir que esa invocacin pueda realizarse a travs trav de internet, empleando protocolos Web estndar ya existentes. Utilizan la arquitectura rquitectura Orientada a Servicios (SOA) Es una aproximacin al diseo de e aplicaciones complejas basada en: x x x x x x La identicacin cacin de los servicios que ofrecer. La denicin nicin de esos servicios La organizacin de las interacciones entre esos servicios Importancia de las interfaces Descripcin n de las interfaces Tratamiento automtico para generar cdigo de implementacin de las interfaces mediante clases.
La idea base de cualquier servicio web ser desarrollar el sistema a partir de las interfaces. interfaces La informacin de los servicios comprende un esquema basado en soap y un resultado. Dicha a informacin utiliza el lenguaje XML para expresar los elementos de los que est compuesto el servicio y los datos que devolver como respuesta a un consumidor de dicho servicio.
Servicios JAX-WS JAX

API de Java EE para la publicacin y acceso a servicios web basados en WSDL y SOAP. SOAP Es la implementacin por defecto que se incluye en Java SE 6 La gestin de los documentos XML incluidos en las peticiones y respuestas SOAP se delegan en JAXB. JAX-WS WS define su propio conjunto de anotaciones para definir las clases y mtodos que actan como puntos finales de los mensajes que conforman las invocaciones SOAP para especificar la definicicin del fichero WSDL y del binding SOAP. La implementacin del servicio web puede desplegarse empleando un Servlet como endpoint o un EJB endpoint.
En contenedores que soporten Java EE 6 el despliegue es automtico en ambos casos. Al iniciar la aplicacin el contenedor inspecciona las clases en busca de las anotaciones @WebService y establece establec los mapeos de URL pertinentes. En contenedores que no son Java EE 6, debe configurarse en el descriptor de despliegue de la aplicacin (WEB-INF/web.xml) y en el servlet de "escucha" del API JAX-WS. JAX Definicin de servicios web con JAX-WS JAX El nico requisito es contar con un interfaz y/o una clase de implementacin anotado con @WebService. En el caso de EJB endpoints, , adems deben de estar anotados como @Stateless (los servicios web son sin estado). La clase de implementacin debe ser pblica y no puede ser final ni abstract. abstract La clase de implementacin debe contar con un constructor vaco. vaco La clase de implementacin no puede definir un mtodo finalize(). finalize() Debe garantizarse una implementacin sin estado. estado La clase de implementacin no puede guardar informacin info de estado ado entre llamadas del cliente. Por defecto, para la clase/interface de implementacin implement se generar un elemento WSDL service con el mismo nombre de la clase y el sufijo Service, Service adems se generar un elemento WSDL portType con el nombre de la clase. Para cada mtodo pblico de la clase se generar gen un elemento WSDL operation con el mismo nombre del mtodo y dos elementos WSDL message, uno para la peticin (con el nombre del mtodo) y otro para la respuesta (aadiendo al nombre del mtodo el sufijo respose). respose) Los parmetros y valores de devolucin devoluci deben de ser tipos bsicos Java, clases anotadas con JAXB, arrays, Map, List o Collection de los anteriores. anteriores Tipos de Anotaciones JAX-WS Anotaciones que definen el mapeo WSDL (modifican el comportamiento por defecto): x @WebService:
Seala una clase o interfaz como endpoint de un servicio web. Incluye atributos para modificar el nombre del elemento service, portType, el name space, etc (name, targetNamespace, serviceName, portName, wsdlLocation, endpointInterface) x @WebMethod
in de las operaciones WSDL (atributo operationName) o excluir mtodos de Permite modificar la definicin la clase que no se desean exponer como operaciones del web service (con el atributo exclude=true). x @WebResult
Permite controlar el nombre del elemento message de WSDL que contendr el el valor de retorno (atributo name). x @WebParam
Permite configurar los elementos parameter de WSDL vinculados a los parmetros de una operacin (atributos: name, mode [IN, OU, INOUT], targetNamespace, header, partName) x @OneWay
o tendr valor de retorno. Permite indicar que un mtodo no
Existen tambin anotaciones que definien el binding SOAP de las operaciones y los mtodos: x @SOAPBinding
Para un mtodo de la clase endpoint especifica el estilo de codificacin de los mensajes (RPC vs. document) y el tipo de codificacin ficacin de los parmetros a usar (encoded vs.literal). Atributos: style, use, parameterStyle. x @SOAPMessageHandler
Especifica detalles de la gestin de los mensajes (peticin y respuesta). Atributos: name, className, initParams, roles, heards Vamos a visualizar ualizar un ejemplo para la creacin de un servicio web bsico. Mostraremos una lgica en la que recibiremos una fecha (String) desde el cliente y le enviaremos el da de la semana a la que corresponde dicha fecha. Comenzaremos crendonos un nuevo proyecto Web Application.
Lo llamaremos AplicacionWebServices.
Vamos a utilizar el servidor GlassFish, que como hemos ledo en la documentacin, utiliza servicios web JAX-WS.
No seleccionaremos ningn framework aadido para la aplicacin.
A continuacin, agregaremos un nuevo objeto sobre el proyecto. Sobre la carpeta de Web Services, seleccionamos un objeto Web Service.
Lo llamaremos PrimerWebService y lo incluiremos en un paquete llamado paqueteservicios. Indicaremos la opcin Web Service from Scratch, lo que quiere decir que generaremos el Web Service en una clase y no en un EJB Stateless.
Como vemos, ya ha incluido la anotacin @WebService indicando el tipo de clase que hemos generado. Nos marcar un error debido a que tenemos que incluir un mtodo o varios de operacin para el servicio.
Podemos incluir operaciones de dos formas diferentes, desde el cdigo pulsando sobre la ayuda de la izquierda del cdigo o sobre el designer del servicio web.
Vista desde el diseador del servicio (pestaa Design) Design
Al seleccionar Add Operation, nos mostrar una nueva ventana en la que realizaremos la cabecera del mtodo web service e incluiremos parmetros si los necesitaramos. Llamaremos a nuestro mtodo GetDiaNacimiento y le indicaremos que recibir un parmetro parmetr de la clase String llamado fecha.
Una vez que pulsamos sobre OK, veremos en el diseador el mtodo de forma grfica.
Y podremos comprobar que hemos aadido un mtodo con anotaciones sobre el servicio en nuestro cdigo.
Estas son las anotaciones que hemos utilizado para el servicio web: x x x x x x @WebService identifica a la clase como un servicio Web. Al incluir este descriptor en la clase el editor del netbeans nos avisa que debemos importa la clase javax.jws.Webservice. @WebMethod identifica a una operacin como parte del servicio web. Al igual que con WebService se debe importar la clase WebMethod de mismo paquete. @WebParam asigna un nombre a los parametros de una operacin. Son opcionales pero conviene utilizarlos para que el descriptor de nuestro servicio Web sea legible para los programadores. programadores
Implementamos el cdigo del Web Service para devolver el da a partir de una fecha: package paqueteservicios; import java.text.DateFormat; import java.text.ParseException; import java.text.SimpleDateFormat; import javax.jws.WebService;
import java.util.*; import javax.jws.WebMethod; import javax.jws.WebParam; @WebService() public class PrimerWebService { @WebMethod(operationName = "getDiaNacimiento") public String getDiaNacimiento(@WebParam(name = "fecha") String fecha) throws ParseException { Date date; Calendar calendario = GregorianCalendar.getInstance(); SimpleDateFormat formatoDeFecha = new SimpleDateFormat("dd/MM/yyyy"); SimpleDateFormat("dd/MM/yyyy"); date = formatoDeFecha.parse(fecha); calendario.setTime(date); int dia, mes, anyo; int op1, op2, op3, op4, op5, op6, resultado; dia = calendario.get(Calendar.DAY_OF_MONTH); mes = calendario.get(Calendar.MONTH); mes++; anyo = calendario.get(Calendar.YEAR); System.out.println("dia " +dia); System.out.println("mes " +mes); System.out.println("ao " +anyo); if (mes == 1) { mes = 13; anyo -= 1; } else if (mes == 2) { mes = 14; anyo -= 1; } op1 = ((mes + 1) * 3) / 5; System.out.println(op1); op2 = anyo / 4; System.out.println(op2); op3 = anyo / 100; System.out.println(op3); op4 = anyo / 400; System.out.println(op4); op5 = dia + (mes * 2) + anyo + op1 + op2 + op4 + 2 - op3; System.out.println(op5); op6 = op5 / 7; System.out.println(op6); resultado = op5 - (op6 * 7); System.out.println(resultado); String dianacimiento = ""; switch (resultado)
{ case 0: dianacimiento = "sbado"; break; case 1: dianacimiento = "domingo"; break; case 2: dianacimiento = "lunes"; break; case 3: dianacimiento = "martes"; break; case 4: dianacimiento = "mircoles"; break; case 5: dianacimiento = "jueves"; break; case 6: dianacimiento = "viernes"; break; } return dianacimiento; } } Ahora veremos que tenemos una carpeta llamada Web Services en nuestro proyecto. Vamos a probar el servicio para visualizar el formato de la respuesta y la entrada de datos. Sobre nuestro servicio, seleccionaremos la opcin Test Web Service.
Se nos abrir el explorador mostrandonos la ubicacin ubicaci web del servicio.
http://localhost:8089/AplicacionWebServices/PrimerWebServiceService?Tester
Ahora ya podemos incluir una fecha con el formato formato que hemos elegido en el cdigo y ya tenemos el formato soap del servicio y la respuesta xml.
SOAP Response <?xml version="1.0" encoding="UTF-8"?> 8"?> <S:Envelope xmlns:S="http://schemas.xmlsoap.org/soap/envelope/"> <S:Body> <ns2:getDiaNacimientoResponse cimientoResponse xmlns:ns2="http://paqueteservicios/"> <return>mircoles</return> </ns2:getDiaNacimientoResponse> </S:Body> </S:Envelope> Y esta es la accin que realizar el servicio web en el servidor expresada de forma grfica:
Ver Video: Servicio Web Tabla de Multiplicar, en el Mdulo 7. Unidad 8, en la plataforma elearning Laboratorio: Servicio Validacin Objetivos
x x Conocer el funcionamiento de los servicios JAVA-WS. JAVA Acceso y consumo de recursos de un servicio web.
Enunciado
En este laboratorio vamos a crearnos un Servicio S Web que validar, mediante dos mtodos, el cdigo ISBN y el cdigo EAN a travs JAVA-WS.
Lo primero de todo ser crearnos un nuevo proyecto Web Application.
Lo llamaremos ProyectoValidacion
Utilizaremos ilizaremos el servidor GlassFish Server.
No agregaremos ningn Framework.
Vamos a agregar un nuevo servicio web.
Lo llamaremos ServicioValidacion
Lo primero que vamos a realizar es una operacin operacin para validar el cdigo ISBN. Para validar el cdigo ISBN tenemos que hacer lo siguiente:
EJEMPLO DE ISBN CORRECTO: 8441513929 Debemos descomponer la cadena y multiplicar multiplica cada nmero por la posicin que ocupa en la cadena 8*1 4*2 4*3 1*4 5*5 9 * 10 Despus, con la suma total de todas estas multiplicaciones mul se divide el resultado entre 11 y, si el resto es cero, el nmero ISBN es correcto. Agregaremos una nueva operacin sobre el Web Service llamada validarNumeroIsbn() que recibir un String con el nmero ISBN a validar y devolver true o false:
A continuacin, nuestro servicio contendr otro mtodo para poder validar el cdigo EAN, que es el formato que se utiliza en los cdigos de barras. Para validar un cdigo EAN debemos realizar los siguientes pasos: Por ejemplo, para validar el cdigo EAN8 EAN "12345678" (Obviamente es inventado) 1. Separar el dgito de control. Nos quedamos con "1234567" y "8"
2. Sumar pares: sumapares=2+4+6=12 3. Sumar impares: sumaimpares=1+3+5+7=16
4. Multiplicamos ultiplicamos los impares por 3. 5. sumaimpares=16*3=48 6. Sumar el resultado de pares e impares: 12+48=60 7. Hallar el resto de la division por 10: 60 mod 10 = 0
8. Hacer 10-resto: 10-0=10 9. Como nos ha salido 10, el dgito de control es 0.
10. Comparar el dgito de control que hemos calculado con el que tena el cdigo: Nos sale 0 y el cdigo digo tena un 8. Es incorrecto. Nos crearemos otra nueva operacin sobre el Servicio que llamaremos validarEan() que recibir un String con el dato del cdigo y devolver true o false.
Ahora debemos implementar la lgica para cada mtodo en el servicio y para la validacin de cada tipo de cdigo. Escribiremos el siguiente cdigo en la clase del Web Service: package paquetews; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService; @WebService() public class ServicioValidacion { /** * Web service operation */ @WebMethod(operationName = "validarNumeroISBN") public boolean validarNumeroISBN(@WebParam(name = "isbn") String isbn) { if (isbn.length() != 10) { return false; } else { char letra; int sumanumeros = 0; for (int i = 0; i < isbn.length(); i++) { letra = isbn.charAt(i); int numero = Integer.parseInt(String.valueOf(letra)); int resultado = numero * (i + 1); sumanumeros += resultado; } if (sumanumeros % 11 == 0) { return true;
} } return false; } /** * Web service operation */ @WebMethod(operationName = "validarEan") public boolean validarEan(@WebParam(name = "ean") String ean) { char letra; char digitocontrol; digitocontrol = ean.charAt(ean.length()-1); ean.charAt(ean.length() int sumapares = 0; int sumaimpares = 0; for (int i = 0; i < ean.length()-1; 1; i++) { letra = ean.charAt(i); System.out.println("Letra: " + letra); int numero = Integer.parseInt(String.valueOf(letra)); if (numero%2==0) { sumapares += numero; } else { sumaimpares += numero; } } sumaimpares = sumaimpares * 3; int total = sumapares + sumaimpares; int resto = total%10; resto = 10 - resto; if (resto == 10) { resto = 0; } int dc = Integer.parseInt(String.valueOf(digitocontrol)); if (resto == dc) { return true; }else { return false; } } } Ahora es el momento de probar el servicio:
Veremos la pantalla de presentacin del Web Service:
Podremos visualizar los resultados de las operaciones:
Unidad 9: Desarrollando servicios Web cliente

Objetivos
x x x Conocer los conceptos de los clientes de Servicios Web. Aprender a consumir cualquier lquier tipo de Servicio desde la plataforma Java. Creacin de clientes de Servicios Web SOAP y Servicios REST.
Introduccin
Dentro de toda la tecnologa de Web Services, sin ninguna duda, la parte ms importante es el consumo de dicho servicio. Por muy bien bien que hagamos una aplicacin, si no tenemos a nadie que sea capaz de consumirla, no servira de nada. Aqu es dnde entra el papel de los clientes de los Servicios Web. El consumo de los servicios web es una tarea muy sencilla si se tienen editores tales tales como NetBeans o Eclipse, ya que nos ofrecen funcionalidad y herramientas grficas para poder obtener acceso a cualquier tipo de Web Service. Tenemos que saber que no todos los Servicios Web son iguales, por lo que tampoco su consumo es el mismo. Depender del tipo de servicio expuesto, que su consumo se realice de una forma determinada. Java utiliza los servicios JAVA-WS WS por defecto, su consumo es particularmente fcil, debido a que utiliza el protocolo SOAP. Como hemos aprendido, los servicios web basados en SOAP, indican al cliente mediante el fichero WSDL cuales son sus mtodos y caractersticas, por lo que un Web Service SOAP escrito en Visual Studio .Net ser consumido exactamente igual que un Web Service SOAP escrito en Java. Pero existen otro tipo de Web Services que estn apareciendo ahora y cuyo consumo es diferente, debido a que utilizan el protocolo HTTP para su comunicacin. Son los Servicios Web RestFul.
Web Services REST

Los os servicios web RESTful han venido a simplificar el desarrollo de de servicios web y a implementar un nuevo modelo de interaccion con servicios web. La Transferencia de Estado Representacional (Representational State Transfer) o REST describe una interfaz web simple utilizando peticiones HTTP y datos XML, XML pero sin capas adicionales a como SOAP, frecuentemente usadas en los servicios web. web Los servicios web RESTful se basan en la simplicidad de su uso debido a que estos son accesibles via protocolo HTTP a diferencia de los servicios web basados en SOAP en donde existe un nivel de abstraccion adicional, lo que significa que podremos consumir un servicio web con un simple formulario html, siempre y cuando sigamos el modelo de trabajo de RESTful donde, mediante las llamadas HTTP a sus metodos podemos acceder a los recursos de un web service, como por ejemplo hacer una solicitud HTTP via POST a un recurso, lo cual es totalmente distinto a hacer una solicitud HTTP via DELETE a otro metodo del mismo recurso. La Transferencia de Estado Representacional (REST - Representational State Transfer) T fue ganando amplia adopcin en toda la web como una alternativa ms simple a SOAP y a los servicios web basados en el Lenguage de Descripcin de Servicios Web (Web Services Descripcion Language - WSDL).
Grandes randes proveedores de Web 2.0 estn migrando migran a esta tcnologa, ga, incluyendo a Yahoo, Google, Facebook, Flickr, quienes han marcado marca como obsoletos a sus servicios SOAP y WSDL y han pasado a utilizar un modelo ms facil de usar, orientado a los recursos. REST define un set de principios arquitectnicos arquitectnicos por los cuales se disean servicios web haciendo foco en los recursos del sistema, incluyendo cmo se accede al estado de dichos recursos y cmo se transfieren por HTTP hacia clientes escritos en diversos lenguajes. REST ha crecido en los ltimos aos como el modelo predominante para el diseo de servicios. De hecho, REST ha logrado un impacto tan grande en la web que prcticamente ha logrado desplazar a SOAP y las interfaces basadas en WSDL por tener un estilo bastante ms simple de utilizar. Los 4 principios de REST Una implementacin concreta de un servicio web REST sigue cuatro principios de diseo fundamentales: x x x x Utiliza tiliza los mtodos HTTP de manera explcita No mantiene estado Expone xpone URIs con forma de directorios Transfiere XML, JavaScript Object Notation (JSON), o ambos
A continuacin vamos a ver en detalle estos cuatro principios, y explicaremos porqu son importantes a la hora de disear un servicio web REST. REST utiliza los mtodos HTTP de manera explcita Una de las caratersticas sticas claves de los servicios web REST es el uso explcito de los mtodos HTTP, siguiendo el protocolo definido por RFC 2616. Por ejemplo, HTTP GET se define como un mtodo productor de datos, cuyo uso est pensado para que las aplicaciones cliente obtengan ngan recursos, busquen datos de un servidor web, o ejecuten una consulta esperando que el servidor web la realice y devuelva un conjunto de recursos. REST hace que los desarrolladores usen los mtodos HTTP explcitamente de manera que resulte consistente con on la definicin del protocolo. Este principio de diseo bsico establece una asociacin uno-a-uno uno uno entre las operaciones de crear, leer, actualizar y borrar y los mtodos HTTP. De acuerdo a esta asociacin, , podemos exponer los mtodos del Servicio de cuatro cua formas diferentes: x x x x POST para crear un recurso en el servidor GET para obtener un recurso PUT para cambiar el estado de un recurso o actualizarlo DELETE para eliminar minar un recurso
Un fallo de diseo que tienen muchas APIs web es el uso de mtodos HTTP para otros propsitos. Por ejemplo, la peticin del URI en un pedido HTTP GET, en general, general identifica a un recurso especfico. O el string de consulta en el URI incluye un conjunto de parmetros parmetros que definen el criterio de bsqueda que usar el servidor para encontrar un conjunto de recursos. Pero hay muchos casos de APIs web poco elegantes que utilizan el mtodo HTTP GET para ejecutar algo transaccional en el servidor; por ejemplo, agregar registros a una base de datos.
En estos casos, no se utiliza adecuadamente el URI de la peticin HTTP, o al menos no se usa "en " la forma REST". REST no mantiene estado Los servicios web REST necesitan escalar para poder satisfacer una demanda demanda en constante consta crecimiento. Se usan clusters de servidores con balanceadores de carga y alta disponibilidad, proxies, y gateways de manera de conformar una topologa serviciable, que permita transferir peticiones de un equipo a otro para disminuir el tiempo total de respuesta de una invocacin al servicio web. El uso de servidores intermedios para mejorar la escalabilidad hace necesario que los clientes de servicios web REST envien peticiones ones completas e independientes, es decir, se deben enviar peticiones que incluyan todos los datos necesarios para cumplir el pedido, de manera que los componentes en los servidores intermedios puedan redireccionar y gestionar la carga sin mantener el estado localmente entre las peticiones. Una peticin completa e independiente hace que el servidor no tenga que recuperar ninguna informacin de contexto o estado al procesar la peticin. Una aplicacin o cliente de servicio web REST debe incluir dentro del encabezado y del cuerpo HTTP de la peticin todos los parmetros, contexto y datos datos que necesita el servidor para generar la respuesta. De esta forma, al no mantener el estado, estado mejora el rendimiento de los servicios web y simplifica el diseo e implementacin de los componentes del servidor, ya que la falta en el estado del servidor elimina la necesidad de sincronizar los datos de la sesin con una aplicacin externa.
REST expone URIs con forma de directorios Desde el punto de vista del cliente de la aplicacin que accede a un recurso, la URI determina lo intuitivo que va a ser el web service REST, y si el servicio va a ser utilizado tal como fue pensado en el momento de disearlo. La tercera caracterstica de los servicios web REST es justamente sobre las URIs. Las URI de los servicios web REST deben ser intuitivas, hasta hasta el punto de que sea facil adivinarlas. Pensemos en las URI como una interfaz auto-documentada auto documentada que necesita de muy poca o ninguna explicacin o referencia para que un desarrollador pueda comprender a lo que apunta, y a los recursos derivados relacionados. Una forma de lograr este nivel de usabilidad es definir URIs con una estructura al estilo de los directorios. Este tipo de URIs es jerrquica, con una nica ruta raiz, y va abriendo ramas a travs de las subrutas para exponer las reas principales del l servicio. De acuerdo a esta definicin, una URI no es slamente una cadena de caracteres delimitada por barras, sino ms bien un rbol con subordinados y padres organizados como nodos.
Por ejemplo, en un servicio de biblioteca de libros que contiene diversos versos libros, libros se podra definir una estructura de URIs como esta: http://www.midireccion.es/biblioteca/libros/{libro} REST transfiere XML, JSON, o ambos La representacin de un recurso, en general, general refleja el estado actual del mismo y sus atributos en el momento en que el cliente de la aplicacin realiza la peticin. La representacin del recurso son simples "instantaneas" " en el tiempo. Esto podra ser una representacin de un registro de la base de datos que consiste en la asociacin entre columnas y tags XML, donde los valores de los elementos en el XML contienen los valores de las filas. O partiendo de la misma base, si el sistema tiene ene un modelo de datos, la representacin de un recurso es una fotografa de los atributos de una de las cosas en el modelo de datos del sistema. Estos s son los elementos que son ofrecidos con los servicios web REST. La ltima restriccin en el momento de disear un servicio web REST tiene que ver con el formato de los datos que la aplicacin y el servicio intercambian en las peticiones/respuestas. Los objetos del modelo de datos, generalmente, generalmente se relacionan de alguna forma, forma y las relaciones entre los objetos etos del modelo de datos (los recursos) deben reflejarse en la forma en la que se representan en el momento de transferir los datos al cliente. Por ltimo, es bueno construir los servicios de manera que usen el atributo HTTP Accept del encabezado, en donde e el valor de este campo es del tipo MIME. De esta manera, los clientes pueden pedir por un contenido en particular que pueden analizar de una forma ms ptima. Algunos de los tipos MIME ms usados para los servicios web REST son:
Esto permite que el servicio sea utilizado por distintos clientes escritos en diferentes lenguajes, corriendo en diversas plataformas y dispositivos. El uso de los tipos MIME ME y del encabezado HTTP Accept es un mecanismo conocido como negociacin de contenido, ido, el cual le permite a los clientes elegir qu formato de datos pueden leer y, minimiza el acoplamiento de datos entre el servicio y las aplicaciones que lo consumen. Debido a su simplicidad de uso, es facil consumir estos servicios web desde otros lenguajes leng que ofrezcan funcionalidad para realizar solicitudes HTTP, como PHP con su libreria CURL, JAVA con su librera de clases para ejecutar solicitudes HTTP. Sin embargo, los desarrolladores de Jersey (que han impulsado el trabajo en la tecnologa de servicios serv web RESTful) han desarrollado una API mediante la cual nos facilitan el consumo de servicios web RESTful ya que proveen funcionalidad para setear los parmetros que se le mandan en una llamada y procesar en automatico el resultado si conocemos el tipo tip de retorno. Es importante reconocer que muchas empresas han implementado plataformas de web services basadas en RESTful, tales s como el servicio S3 de amazon o Google Maps. Vamos a crearnos un Servicio Web que utiliza la tecnologa RestFul en Java.
Nos creamos reamos un nuevo proyecto Web.
Lo llamaremos ServicioWebRestFul
No utilizaremos ningn Framework y utilizaremos el servidor Glasshfish. Nos crearemos un Servicio Web que expondr los Empleados de nuestra base de datos en diferentes direcciones Web via http. Para poder realizar la accin lo haremos mediante Unidades de Persistencia que se comunicarn con la base de datos Oracle y que nos devolver los registros. Debemos crearnos una nueva unidad de persistencia:
Debemos crearnos una nueva fuente de datos dato para conectarnos a Oracle
En la siguiente pantalla, debemos utilizar un nuevo proveedor Oracle que es el proporcionado en la documentacin. Para ello, seleccionaremos de la lista desplegable la opcin Nuevo Controlador
Configuramos las propiedades de la conexin para poder comunicarnos con Oracle
Nos mostrar el esquema que deseamos visualizar (SYSTEM) y pulsamos en Aceptar, nos habr creado la conexin correctamente.
Es importante seleccionar la opcin de Ninguno en la generacin de las tablas, debido a que sino, los datos los perderamos, ya que nuestra unidad de persistencia puede crear objetos adems de recuperarlos. Ya nos habr creado la Unidad de persistencia:
Es el momento de crearnos un Servicio Web RestFul utilizando la unidad de persistencia y la base de datos Oracle.
Ahora nos pedir la tabla o tablas que deseamos utilizar para nuestro Servicio Web. Seleccionamos la tabla EMP.
Dejamos los parmetros de recursos y conversiones con los nombres de los paquetes originales origi que nos ofrece NetBeans.
Nos crear unos paquetes de la siguiente forma:
Ahora es el momento de probar nuestro Servicio Web, para ello, pulsaremos sobre el proyecto y seleccionaremos la opcin Test RESTful Web Services.
Veremos la pantalla para testear el Web Service Restful, en la zona de la izquierda podremos visualizar todos los datos de empleados o hacer consultas para un empleado en concreto, depende de nuestra solicitud.
Podremos realizar consultar y visualizar que los datos nos son devueltos devueltos correctamente.
Tambin nos puede devolver los datos en formato JSON y con una URL en la que podremos acceder a todos los registros a travs del protocolo Http, que es el protocolo que utilizan los servicios Web Restful.
Si seleccionamos cualquier direccin Web, veremos el registro ofrecido correctamente mediante un localhost.
Consumir Servicio Web RestFul Crear un servicio Web RestFul no sirve de nada si no somos capaces de aprender a consumirlo. Un servicio web Restful se consume de forma forma diferente a un servicio web convencional, debido a que su protocolo no es SOAP, es HTTP. Con NetBeans ms el complemento Jersey, se nos hace muy fcil consumir servicios REST. Para integrarlo con el IDE, necesitamos registrar el fichero WADL. El fichero chero WADL es la base de los Web Services REST, as como el fichero WSDL es la base del protocolo SOAP. La URL para el acceso al WADL la podemos obtener as: http://host:puerto/contexto-web/resources/application.wadl web/resources/application.wadl El fichero WADL es el homnimo de WSDL en Servicios Web RestFul. Vamos a consumir un Servicio Web simple que nos devolver el valor factorial de un nmero que nos enviarn via HTTP. Lo primero ser crearnos un nuevo proyecto Java Web Web Application y lo llamaremos ServicioFactorial. Utilizaremos remos el Servidor GlasshFish Server 3 y no utilizaremos ningn Framework. Ahora nos agregaremos una clase Java que llamaremos FactorialResource.
Crearemos un mtodo para calcular el factorial de un nmero en nuestra clase: public class FactorialResource { public long factorial(long base) { if (base >= 1) { return factorial(base - 1) * base; } return 1; } } Cada vez que agreguemos una anotacin o un elemento sobre la clase que vamos a exponer en el servicio web, debemos pulsar sobre el proyecto y seleccionar la opcin Limpiar y Generar. Agregaremos la notacin @Stateless al inicio de la clase. Esto convierte te automticamente a nuestra clase en un EJB. . El espacio de nombre que debemos importar es javax.ejb.Stateless.
A continuacin de la anterior anotacin, aadiremos la a anotacin @Path("/factorial") del espacio de nombres javax.ws.rs.Path. Esto indica que este recurso ser accesible desde la ruta "/factorial" via web. En el momento en el que seleccionemos Limpiar y Construir sobre el proyecto, proyecto, NetBeans detectar que se ha creado un recurso REST, entonces pedir activar esta caracterstica en la aplicacin, aplicacin por lo que debemos pulsar sobre Aceptar.
La clase que ya hemos creado es un recurso REST.
Ahora ser el momento de incluir mtodos en nuestro servicio RestFul. Solo podremos emos crear un mtodo de tipo GET, POST, PUT y DELETE. Como omo el mtodo factorial nos n deber un nico valor segn el parmetro que le especificamos, usaremos el tipo GET. Para ello agregamos la anotacin @GET antes del mtodo factorial en la clase del espacio de nombres javax.ws.rs.GET. Y con esto, nuestro recurso REST ya tiene un mtodo. mtodo
Los os valores que se reciben desde el recurso REST deben ser objetos. Por lo tanto, nuestro mtodo debe cambiar para que no devuelva un dato long, sino un java.lang.String. Adems, debemos indicar que el parmetro base del mtodo Java factorial ser recibido via URL con el nombre base. Es decir, se llamar a la direccin URL de la siguiente forma: ..../resources/factorial?base=5 Para ello usaremos la notacin @QueryParam del espacio de nombres javax.ws.rs.QueryParam, javax.ws.rs.QueryParam antes de la declaracin del parmetro. La clase, finalmente, quedar con el siguiente cdigo: package paqueteservicio; import javax.ejb.Stateless; import javax.ws.rs.GET; import javax.ws.rs.Path; import javax.ws.rs.QueryParam; @Stateless @Path("/factorial") public class FactorialResource { @GET public String factorial(@QueryParam("base") long base) { return Long.toString($factorial(base)); } long $factorial(long base) { if (base >= 1) { return $factorial(base - 1) * base;
} return 1; } } Una vez que tenemos el proyecto listo, debemos pulsar sobre el proyecto y seleccionar Deploy. Ahora, para acceder a nuestro proyecto como clientes y probar su funcionalidad, bastar con mostrar la URL de acceso a nuestro Servicio RestFul. http://localhost:8080/ServicioFactorial/resources/factorial?base=5 localhost:8080/ServicioFactorial/resources/factorial?base=5 Como podremos comprobar, se ha creado el Servicio via HTTP y el acceso nos devuelve el resultado en la pgina:
Como nuestro recurso es va http, tambin podemos acceder mediante cualquier cliente client HTML, por ejemplo una pgina JSP. Escribiremos el siguiente cdigo en la pgina index.jsp del proyecto: <body> <h1>Llamada factorial REST</h1> <form action="resources/factorial"> Introduzca el nmero: <input name="base" type="text" ty /> <input type="submit" value="Mostrar Factorial"/> </form> </body> El resultado ser la llamada a nuestro servicio Rest y realizar la operacin segn nuestro cdigo. Otra forma de acceso sera mediante el fichero WADL. Para recuperar dicho fichero, debemos pulsar sobre el proyecto y seleccionar Test RESTful WebService. Veremos una pgina dnde podremos probar el servicio y su resultado:
Hemos visto que podemos consumir el Servicio desde cualquier lenguaje que sea capaz de soportar HTML y protocolo HTTP, por lo que el consumo de Servicios Rest son una alternativa que se est extendiendo muy rpidamente por Internet. Para consumir el Servicio RestFul desde cualquier cualquier aplicacin de Java, debemos utilizar el archivo WADL. Dicho fichero se genera en el momento de probar el servicio.
http://localhost:8080/ServicioFactorial/resources/application.wadl Lo primero que tenemos que realizar para consumirlo, es registrar el servicio en el IDE de NetBeans. Para ello, debemos ir a la ventana Prestaciones y aadir el Servicio Web.
Indicaremos la ruta al fichero WADL del servicio REST:
Ya tendremos el servicio registrado en nuestro IDE de NetBeans.
Para consumir el servicio, , vamos a hacerlo desde un Cliente en lnea de comandos. Nos crearemos un nuevo proyecto Java Java Application llamado ClienteRestFul. Ahora nos crearemos una clase que ser el cliente del servicio, para ello, agregamos sobre el proyecto un nuevo elemento to y, en la pestaa Web Services, seleccionamos la opcin RESTFul Java Client.
Como hemos registrado nuestro servicio en el IDE de NetBeans, seleccionaremos la opcin IDE Registered y en Browse marcaremos nuestro Servicio.
Llamaremos a nuestra clase ClienteFactorial.
Nos habr creado la clase para acceder a los datos del Servicio RestFul. Para probar su funcionalidad y acceso, nos crearemos una clase llamada ConsumoFactorial dentro del mismo paquete del Cliente, y escribiremos el siguiente cdigo: package clienterestful; public class ConsumoFactorial { public static void main(String[] args) { ClienteRest c = new ClienteRest(); long base = 5; String resultado = c.factorial(String.class, String.valueOf(base)); System.out.println("Resultado del factorial de 5: " + resultado); } }
Como podremos comprobar, el resultado es correcto y consumimos el servicio REST desde un cliente:
Consumir Servicio Web SOAP Para consumir un Servicio Web con protocolo SOAP es muy simple si se tiene un editor grfico estilo NetBeans o Eclipse. Para ello, lo primero ser localizar la direccin dnde est alojado el Servicio Web que deseamos consumir. Vamos a mostrar un ejemplo de consumo de Web Services basados en SOAP. Podemos encontrar ntrar multitud de Web Services en la siguiente direccin: http://www.xmethods.net Vamos a consumir el siguiente Servicio Web: http://footballpool.dataaccess.eu/data/info.wso?WSDL Debemos crearnos un proyecto que haga de cliente. Para ello, nos crearemos un nuevo proyecto Java Application llamado ClienteSOAP.
Sobre el proyecto aadiremos un nuevo elemento Web Service Client.
Debemos indicar la direccin a nuestro servicio web:
Nos mostrar un listado con todos los mtodos disponibles para acceder al servicio. Ahora bastar con dirigirnos a la clase Main.java y arrastar el mtodo que deseemos probar del Web Service.
Nos crear un mtodo para poder consumir el Servicio. Bastar con realizar la llamada desde el mtodo main al mtodo del Web Service y mostrar los resultados. package clientesoap; import eu.dataaccess.footballpool.ArrayOfString; import java.util.*; public class Main { public static void main(String[] args) { ArrayOfString jugadores = allMidFields("Spain"); List<String> > datos = jugadores.getString(); for (String s:datos) { System.out.println("Mediocentros: " + s); } }
private static ArrayOfString allMidFields(java.lang.String sCountryName) { eu.dataaccess.footballpool.Info .Info service = new eu.dataaccess.footballpool.Info(); eu.dataaccess.footballpool.InfoSoapType port = service.getInfoSoap(); return port.allMidFields(sCountryName); } } Y el resultado ser el siguiente:
Ver Video: Creacion de un cliente cliente para consumir servicios web, en el Mdulo 7. Unidad 9, en la plataforma elearning
Laboratorio: Cliente Servicio Web Mundial
Objetivos
x x Conocer el funcionamiento de acceso a clientes web utilizando la tecnologa JAVA-WS. JAVA Acceso y consumo de recursos de un servicio web.
Enunciado
Para nuestra prctica vamos a utilizar un servicio web ya creado y gratuito que contiene informacin y datos sobre el mundial 2010. http://footballpool.dataaccess.eu/data/info.wso?WSDL ccess.eu/data/info.wso?WSDL
Lo primero de todo ser crearnos un nuevo proyecto Web Application.
Lo llamaremos ConsumoServicioWeb
Utilizaremos el servidor GlassFish Server.
No agregaremos ningn Framework.
Vamos a agregar un cliente de servicio web. Para ello, seleccionamos sobre nuestro proyecto New Other
Y en la carpeta Web Services, marcamos Web Service Client
Marcamos la opcin WSDL y escribimos la direccin direccin al servicio web del mundial 2010. El estilo del cliente ser utilizando la tecnologa JAVA-WS JAVA
Veremos que nos ha creado una carpeta llamada Web Service Reference en la que tenemos la informacin n de todos los mtodos que ofrece el servicio web.
Ahora vamos a crearnos una nueva clase para consumir los datos del d servicio.
La llamaremos BeanWebService.
Sobre nuestra clase, bastar con arrastrar el mtodo mtodo que necesitemos para poder realizar la llamada al servicio. Hemos seleccionado el mtodo AllGoalKeepers.
Si nos fijamos en la estructura, ya nos ha generado generado la llamada al servicio y los import necesarios. Adems, pod.0 emos comprobar que nos pide un String para poder invocar al mtodo. Tambin podemos comprobar que devuelve un objeto del tipo ArrayOfString. import eu.dataaccess.footballpool.ArrayOfString; eu.dataaccess.footballpool.ArrayOfStr import eu.dataaccess.footballpool.ArrayOftTeamInfo; private static ArrayOfString allGoalKeepers(java.lang.String sCountryName) { eu.dataaccess.footballpool.Info service = new eu.dataaccess.footballpool.Info(); eu.dataaccess.footballpool.InfoSoapType llpool.InfoSoapType port = service.getInfoSoap(); return port.allGoalKeepers(sCountryName); } Vamos a implementar el mtodo para visualizar todos todos los porteros de un equipo. En nuestro ejemplo utilizaremos Spain. package paquetebeans; import eu.dataaccess.footballpool.ArrayOfString; import eu.dataaccess.footballpool.ArrayOftTeamInfo; import java.util.List; public class BeanWebService { private static ArrayOfString allGoalKeepers(java.lang.String sCountryName) { eu.dataaccess.footballpool.Info service = new eu.dataaccess.footballpool.Info(); eu.dataaccess.footballpool.InfoSoapType port = service.getInfoSoap(); return port.allGoalKeepers(sCountryName); } public void miMetodo() { ArrayOfString porteros = allGoalKeepers("spain"); List<String> datos = porteros.getString(); for (int i=0;i<datos.size();i++) { System.out.println(datos.get(i)); } } } Si ejecutamos nuestra clase, , podremos comprobar que muestra los nombres de los porteros de la seleccin Spain.
Laboratorio: Servicio RestFul Google Maps Objetivo

Visualizar el funcionamiento de los Servicios Web REST y su consumo.
Enunciado
Realizaremos una aplicacin que nos mostrar unas direcciones mediante los Servicios Web de Google Maps. Lo que haremos ser un Web Service escalar, es decir, nosotros expondremos direcciones desde una tabla a travs de un Web Service REST propio y mostraremos informacin en ese servicio mediante med Google Maps. Lo primero que debemos hacer es crearnos la tabla ESTADIOS en Oracle mediante el siguiente script: CREATE TABLE ESTADIOS (ESTADIO_COD INT , NOMBRE VARCHAR2(40) , DIRECCION VARCHAR2(150) , CONSTRUCCION INT , AFORO INT); INSERT INTO ESTADIOS VALUES (1,'SANTIAGO BERNABEU' ,'Avenida de Concha Espina, 1 28036 Madrid' ,1947, 85000); INSERT INTO ESTADIOS VALUES (2,'MESTALLA' , 'Av de Suecia, 46010 Valencia, Comunidad Valenciana' ,1923, 53000); INSERT INTO ESTADIOS VALUES (3,'MARTINEZ VALERO' , 'MANUEL MARTNEZ VALERO, 3 03208 ELCHE' ,1976, 39000); INSERT INTO ESTADIOS VALUES (4,'ALFONSO PEREZ' , 'Avenida Teresa de Calcuta, S/N, 28903 Getafe' ,1998, 14400);
COMMIT; ALTER TABLE ESTADIOS ADD CONSTRAINT PK_ESTADIOS PRIMARY KEY (ESTADIO_COD); SELECT * FROM ESTADIOS Creamos un nuevo proyecto Web
Llamaremos al proyecto ProyectoGoogleMaps y utilizaremos el servidor de aplicaciones GlasshFish.
Tenemos que crearnos una nueva unidad de persistencia para recuperar la tabla de estadios de Oracle mediante Entidades.
Nos conectamos con Oracle como hemos visto en la documentacin.
Marcamos la opcin de Ninguno para que no nos genere las tablas de nuevo.
Y ya tendremos la unidad de persistencia para conectarnos a nuestra tabla Estadios.
Ahora nos creamos un nuevo Servicio Web RestFul from Database
Seleccionaremos la tabla Estadios
Incluimos la tabla en un paquete nuevo.
Nos dir si deseamos crear los paquetes para los recursos, dejamos todo como est por defecto.
Ahora ya podremos probar nuestro servicio y visualizar los datos de los estadios. Sobre el proyecto, seleccionamos Test RESTful Web Services.
Veremos la pgina de presentacin y podr hacer consultas pulsando sobre Test.
Ahora vamos a integrar la funcionalidad del servicio Web Google Maps RestFul dentro de nuestro Servicio de estadios para que nos aparezca el mapa de dnde estn ubicados cada uno de los Estadios. Lo primero que debemos hacer es conseguir la API KEY de Google para poder realizar la prctica. Debemos s ir a esta direccin, validarnos con una cuenta de GMail y registrar la direccin de nuestro Servicio, por ejemplo: http://localhost:8082 http://code.google.com/intl/es-ES/apis/maps/signup.html ES/apis/maps/signup.html Una vez que tenemos la API KEY, volvemos al IDE de NetBeans. Debemos abrir la clase EstadiosResource del paquete service:
Y agregaremos un mtodo nuevo para realizar las bsquedas: @GET @Produces(value="text/html") public String getGoogleMap(){ return ""; } En nuestro IDE, presionemos emos Ctrl+5 para ver el panel de servicios. Abriremos el nodo Web Services, luego Google, despus Map Service: Service
Arrastremos el nodo getGoogleMap y soltmoslo en el mtodo que acabamos de crear, justo j antes del return "".
El IDE nos mostrar una ventana con datos con ejemplo para ser utilizado en nuestra aplicacin.
El IDE nos crear un cdigo de ejemplo automtico para probar la funcionalidad. @GET @Produces(value = "text/html") public String getGoogleMap() { try { String address = "16 Network Circle, Menlo Park"; java.lang.Integer zoom = 15; String iframe = "false"; RestResponse result = GoogleMapService.getGoogleMap(address, zoom, iframe); //TODO - Uncomment nt the print Statement below to print result. //System.out.println("The SaasService returned: "+result.getDataAsString()); } catch (Exception ex) { ex.printStackTrace(); } return ""; } El IDE tambin ha creado reado los paquetes org.netbeans.saas y org.netbeans.saas.google que contienen las siguientes clases y recursos: x x x x RestConnection - Una clase que envuelve a HttpUrlConnection RestResponse - Un clase que envuelve las respuestas HTTP googlemapservice.properties - Un archivo de propiedades que almacenar la clave para manejar el GoogleMap GoogleMapService - Un servicio que envuelve los mtodos que usa RestConnection y llama al servicio GoogleMap.
En el bloque try de getGoogleMap() reemplacemos las lneas comentadas comentadas con lo siguiente: return result.getDataAsString(); Abrimos el archivo googlemapservice.properties y pegamos la clave del API que hemos recuperado al validarnos en la pgina de Google.
Escribimos la clave que nos han proporcionado.
Todava no hemos incluido las direcciones de nuestra tabla, pero vamos a comprobar que todo est correcto y que nos muestra la direccin de prueba que nos ha proporcionado Google Maps. Volvemos a probar los Servicios Test RESTful. Cuando haya cargado la pgina, pulsamos sobre el enlace Estadios del lado izquierdo. Luego hacemos clic en el botn "Test".
Se mostrar la tabla de los Estadios con sus respectivas direcciones URI que se han creado. Desde esta tabla de resultados, hagamos clic justo donde dice /estadioss/1/.
Se abrir una pgina para probar el resultado de este cliente. Seleccionamos de la lista desplegable MIME la opcin text/html. Y le damos clic en Test.
El GoogleMap se mostrar en la calle que le indicamos.
Ahora es el momento de recuperar los los datos y enviar la direccin de cada uno de los estadios a nuestro Servicio Web RestFul. Para ello, debemos modificar el mtodo getGoogleMaps() de la siguiente forma, dnde recuperaremos la direccin del estadio que hayamos seleccionado. @GET @Produces(value = "text/html") public String getGoogleMap() { try {
Estadios c = getEntity(); String direccion = c.getDireccion(); java.lang.Integer zoom = 15; String iframe = "false"; RestResponse result = GoogleMapService.getGoogleMap(direccion, zoom, iframe); return result.getDataAsString(); } catch (Exception ex) { ex.printStackTrace(); }finally{ PersistenceService.getInstance().close(); stance().close(); } return ""; } Ahora volvemos a probar el Servicio RestFul y comprobaremos que nos muestra el mapa correspondiente a cada Estadio que hayamos seleccionado:

Java Modulo 7

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

Java Modulo 7

Uploaded by

Copyright:

Available Formats

Profesional en Plataforma Java

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Unidad 1: Identificando la construccin de bloques de servicios Web

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Definicin de e Servicios Web

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Protocolos de Servicios Web

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Documentos de Datos XML

<Informacion> <Nombre> </Informacion>

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Utilizacin de web services

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Ventajas e inconvenientes de los servicios Web Ventajas

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Seguridad de los Servicios Web

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Laboratorio: Servicio Web DNI Objetivo

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Vamos a agregar una nueva operacin:

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

0=T 1=R 2=W 3=A

4=G 5=M 6=Y 7=F

8=P 9=D 10=X 11=B

12=N 13=J 14=Z 15=S

16=Q 17=V 18=H 19=L

20=C 21=K 22=E 23=T

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Veremos la pantalla de presentacin del servicio:

Si invocamos el servicio, comprobaremos que el dato de la letra es devuelto:

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Unidad 2: Analizando la tecnologa y plataforma de servicios Web

Arquitectura SUN Web Services

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Arquitectura NET Web Services

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

El conjunto de clases del .NET Framework ASP.NET Remoting Windows Forms

NET Framework es la base de cualquier desarrollador de .NET.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Caractersticas Tipos de tecnologa Empresas que lo ofrecen

.NET Producto Microsoft

Libreras de desarrollo Intrprete

caractersticas de Sun. Java Core API JRE (Java Runtime)

Pginas dinmicas Componentes Acceso a bases de datos Servicios Web

Servlets, JSP EJB JDBC, SQL/J SOAP, WSDL, UDDI, RestFul

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

MS DTC ADSI MSMQ C#, Visual Basic, C++otros IL

Comparacin en las arquitecturas de Servicios Web

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Podemos visualizar la solicitud SOAP

Y podremos visualizar la respuesta que nos ofrece el servicio. servici

Ver Video: Arquitectura Web Services, en el Modulo 7. Unidad 2, en la plataforma elearning.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Unidad 3: Aplicando XML

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.

Estructura de documentos XML