Java Modulo 8

Profesional en Plataforma Java
Mdulo 8: Diseando servicios web Java
Contenido
Mdulo 8: Diseando servicios web Java
Unidad 1. Analizando oportuniudades con los servicios web Unidad 2. Diseando buenas prcticas y patrones para los servicios web Unidad 3. Manejando excepciones en los servicios web Unidad 4. Seguridad en los servicios web
www.ceticsa.com Para uso exclusivo de los alumnos de CETICSA S.L.
Unidad 1: Analizando Oportunidades con los Servicios Web

Objetivos
x x Describir la arquitectura orientada a servicios. Entender los servicios web como una implementacin de SOA. SOA
Introduccin
El trmino servicios Web designa una tecnologa que permite que las aplicaciones se comuniquen en una forma que no depende de la plataforma ni del lenguaje de programacin. Un servicio Web es una interfaz de software que describe un conjunto de operaciones a las cuales se puede acceder por la red a travs de mensajera XML estandarizada. Usa protocolos basados en el lenguaje XML con el objetivo de describir escribir una operacin para ejecutar o datos para intercambiar con otro servicio Web. Un grupo de servicios Web que interacta de esa forma define la aplicacin de un servicio Web especfico en una arquitectura orientada a servicios (SOA). La arquitectura en capas se complementa entonces con la arquitectura orientada a servicios (SOA), ya que se hace necesaria una forma de comunicacin eficiente y escalable, independientemente del lenguaje de programacin y plataforma de cada una de las aplicaciones. Es necesario nec entonces desarrollar los servicios que se presentan y son utilizados. Un servicio es una funcin que acepta una llamada y devuelve una respuesta mediante una interfaz bien definida. La manera en la que un servicio procesa internamente la llamada para par producir la respuesta es independiente de la definicin del servicio. La arquitectura orientada a servicios proporciona, adems, la posibilidad de orquestacin de los servicios, esto es, secuenciacin, orden y control de los servicios, aadiendo la lgica lgic de datos necesaria para el proceso. Los elementos bsicos que conforman SOA son: x x x Proveedores de servicios Consumidores de servicios Bus de Servicios Empresariales.
En la siguiente unidad estudiaremos la arquitectura en servicios, servicios web implementando implementa SOA y el anlisis de casos tpicos de SOA. Algunas implementaciones comunicaciones dinmicas. SOAP tambin usan WSDL durante la ejecucin para soportar
Tipos de comunicacin entre aplicaciones plicaciones en Web Services: Services x x x x Protocolo de Transporte: o HTTP/HTTPS Codificacin de datos o Protocolo SOAP (Simple Object Access Protocol) y Esquema XML (DTD/XSD) Descripcin de interfaces o puntos de acceso a aplicacin o WSDL (Web Services Description Language) Descripcin de servicio y descubrimiento o UDDI (Universal Description, Descrip Discovery and Integration)
Seguridad o WS-Security, Security, XML Signature y XML Encription (Especificaciones JSR)
Las APIs de Java para los Web Services son las siguientes: x x x x x x x JDOM JAXP: Java API for XML processing JAXB: Java API for XML binding JAX-RPC: Java API for RPC JAXR: Java API for UDDI registry SAAJ: SOAP API with Attachements JAX-WS: WS: Java API for WebServices o API de ms alto nivel o Usa todas las dems por debajo o Permite manejo de WS sin conocimientos de XML, SOAP, etc
Servicios JAX-RS
API de Java que define una infraestructura (clases e interfaces) para implementar una arquitectura REST (paquete javax.ws.rs). Vamos a visualizar primer que es una arquitectura REST: REST (Representational presentational State Transfer): Se define como un "estilo arquitectnico" para el desarrollo de aplicaciones distribuidas. Caractersticas de REST: x x x x x Forma de construir aplicaciones distribuidas. Centrada en el concepto de RECURSO Mecanismos ecanismos RPC centrados en concepto de operacin El estado de los recursos reside en el servidor Los clientes es acceden al estado de recurso mediante REPRESENTACIONES del mismo transferidas desde el servidor o desde el cliente empleando el protocolo HTTP como mecanismo de transporte (podran emplearse otros, REST no es especfico de un protocolo) Cada aplicacin puede utilizar diferentes formatos para la representacin de los recursos o HTML para navegadores web o XML, JSON para aplicaciones
x x x x x x
Con el parmetro Content-Type Content Type de las cabeceras HTTP se especifica el tipo MIME de los datos intercambiados (text/html, application/xml, applicat application/json) o El cliente puede informar al servidor del tipo de representacin que necesita (parmetro Accept en cabecera de las peticiones HTTP) Los recursos son identificados y estn accesibles mediante uno o varios URI (Uniform Resource Identifier). Incluye un conjunto de anotaciones para especificar el mapeo entre las URIs de los recursos y los mtodos HTTP con los mtodos Java de una clase de implementacin (endpoint) Gestiona automticamente las representaciones de los recursos intercambiados. intercambi Emplea JAXB para el tipo MIME application/xml Emplea la librera BadgerFish para mapeo de XML a JSON en el caso del tipo MIME application/json La generacin y tratamiento de otros tipos de representaciones debe manejarse manualmente (imgenes, PDF, ...) ..) implementando las interfaces javax.ws.rs.ext.MessageBodyReader, javax.ws.rs.ext.MessageBodyWriter en una clase anotada con @jax.ws.rs.ext.Provider. o
ANOTACIONES JAX-RS @Path La clase de implementacin de los recursos REST (resource class) debe sealarse con una anotacin @Path, especificando el path de alto nivel dentro del que se enmarcan las URIs gestionadas por la clase de implementacin (context root).
Pueden anotarse clases Java "normales" o EJBs sin estado. En el caso de anotar clases "normales" ormales" se deber especificar en el web.xml de la aplicacin web el uso del Servlet de JAX-RS. En los mtodos de dicha clase se puede especificar el path (dentro del path de la clase de implementacin) al que se vinculan los mtodos Java. Podemos asociar nombres a los distintos fragmentos que componen el path, path dichos nombres irn sealados entre los signos {...}.
Podemos especificar los fragmentos del de path empleando expresiones regulares. . Anotaciones de mtodos http Especifican el mtodo HTTP al que se vinculan vi los mtodos Java anotados para compatibilidad con los servicios web JAX-RS. @GET Vincula ncula al mtodo anotado las peticiones HTTP GET dirigidas al path correspondiente a ese mtodo. mtodo @PUT Vincula incula al mtodo anotado las peticiones HTTP PUT dirigidas al path pa correspondiente a ese mtodo. mtodo @DELETE Vincula incula al mtodo anotado las peticiones HTTP DELETE dirigidas al path correspondiente a ese mtodo. mtodo @POST Vincula incula al mtodo anotado las peticiones HTTP POST dirigidas al path correspondiente a ese mtodo. mtodo
Existe otro ro tipo de servicios web en java que son JAVA-WS JAVA WS y que describiremos en mdulos posteriores.
Estndares Principales de Web Services

Los estndares principales y tecnologas para construir y habilitar Web services son:
XML
Es el estndar de facto para estructurar ructurar datos, contenido y formatos para documentos electrnicos. Es el lenguaje universal para intercambio de informacin entre aplicaciones, sistemas y dispositivos sobre Internet.
SOAP
Es una especificacin de un protocolo que define una forma uniforme de pasar datos codificados en XML. Tambin define una forma de invocar procedimientos remotos (RPC: Remote Procedure Call) usando a HTTP como el protocolo de comunicacin. SOAP parte de la premisa que no importa si el middleware es simple o complejo, todos requieren un WAN wrapper (envoltorio). El envo de mensajes como texto XML plano tiene ventajas en trminos de que asegura la interoperabilidad y en el middleware se acepta el costo del parsing y la serializacin XML, para su visibilidad en todas las redes. Es un protocolo simple de mensajera XML sobre los protocolos HTTP, SMTP, FTP y otros de Internet. Permite el intercambio de informacin entre dos o mas pares y permite que se comuniquen en un ambiente de aplicacin distribuida. Es independiente del l modelo de objetos de la aplicacin, del lenguaje y de la plataforma o dispositivo sobre el cual corre Es un protocolo del W3C y de Sun Microsystems, IBM, HP, SAP, Oracle y Microsoft. Estas empresas participan en el W3C XML protocol-working group. ebXML de e UN/CEFACT usa SOAP. Usa XML Infosets como formato para los mensajes y sus reglas de codificacin para representar datos y mensajes.
WSDL
Define a los servicios como colecciones de extremos de la red (network endpoints) o puertos (ports). Un documento WSDL L usa los siguientes elementos en la definicin de servicios: Types un contener de definiciones de tipos de datos usando algn tipo de sistema (tal como XSD). Message una definicin abstracta con tipos de los datos que se transmiten. Operation una descripcin scripcin abstracta de una accin soportada por el servicio Port Type un conjunto abstracto de operaciones soportadas por uno o mas endpoints. Binding un protocolo concreto y especificacin de datos para un port type en particular.
Port un endpoint en particular, definido como una combinacin de un binding y una direccin de red Resumiendo, WSDL es una plantilla (template) de cmo se describen servicios y los usan los clientes
UDDI
Provee un mecanismo para que los clientes dinmicamente puedan encontrar encontrar otros web services. Usando una interface UDDI, una aplicacin comercial se puede conectar dinmicamente con los servicios provistos por una aplicacin comercial externa de otra empresa. Un UDDI registry tiene dos tipos de clientes: Aplicaciones comerciales iales que quieren publicar un servicio y sus interfaces de uso, y clientes que quieren obtener servicios de un cierto tipo y vincularse por medio de programas a ellos. Es una capa superior sobre SOAP y asume que requerimientos y respuestas son objetos UDDI enviados como mensajes SOAP. No soporta descubrimiento con todas las opciones (por ejemplo bsquedas limitadas geogrficamente o vinculacin y negociacin de contratos tipo eLance). Se espera que UDDI sea la base para servicios de capas superiores soportadas por otros estndares. El UDDI working group incluye a Sun Microsystems,IBM, HP, SAP, Oracle y Microsoft.
ebXML
Define un mercado electrnico global en el cual las empresas se encuentran unas a otras y realizan operaciones comerciales y transacciones transacci cooperativamente. Define un conjunto de especificaciones para empresas para conducir negocios electrnicos sobre Internet estableciendo un estndar comn para especificar procesos de negocio, modelado de informacin comercial, colaboracin en procesos de negocio, perfiles de colaboracin de socios, acuerdos y mensajera. Es una iniciativa de United Nations Center for Trade Facilitation and Electronic Business (UN/CEFACT) y la Organization for the Advancement of Structured Information Standards (OASIS). Otras organizaciones de estndares como Open Travel Alliance (OTA), Open Application Group, Inc. (OAGI), Global Commerce Initiative (GCI), Health Level 7 (HL7, una organizacin de estndares dedicados a la salud), y RosettaNet (un comit de estndares XML ) lo han adoptado.
Framework de ebXML
ebXML Business Process Service Specifications (BPSS). ebXML CPP/CPA. ebXML Messaging Service Handler (MSH) ebXML registry ebXML Core components
Arquitectura orientada a servicios

La Arquitectura Orientada a Servicios de cliente, es un concepto de arquitectura de software que define la utilizacin de servicios para dar soporte a los requisitos del negocio. Permite la creacin de sistemas altamente escalables que reflejan el negocio de la organizacin, a su vez brinda una na forma bien definida de exposicin e invocacin de servicios (comnmente pero no exclusivamente servicios web), ), lo cual facilita la interaccin entre diferentes sistemas propios o de terceros. SOA define las siguientes capas de software: Aplicaciones bsicas - Sistemas desarrollados bajo cualquier geogrficamente dispersos y bajo cualquier figura de propiedad; arquitectura o tecnologa,
De exposicin de funcionalidades - Donde las funcionalidades de la capa aplicativa son expuestas en forma de servicios (generalmente generalmente como servicios web); De integracin de servicios - Facilitan el intercambio de datos entre elementos de la capa aplicativa orientada a procesos empresariales internos o en colaboracin; De composicin de procesos - Que define el proceso en trminos trminos del negocio y sus necesidades, y que vara en funcin del negocio; De entrega - donde los servicios son desplegados a los usuarios finales. SOA proporciona una metodologa y un marco de trabajo para documentar las capacidades de negocio y puede dar soporte a las actividades de integracin y consolidacin.
Los puntos de entrada definidos por -- basados en experiencias reales de clientes -- pueden ayudar su empresa a beneficiarse con la implementacin de soluciones SOA predefinidas. Esos puntos de entrada son impulsados por necesidades empresariales (puntos de entrada relacionados con personas, procesos e informacin) y necesidades de TI (puntos de entrada relacionados con conectividad y reutilizacin). He aqu algunas descripciones generales de los cinco puntos de entrada:
Personas: Este punto de entrada a SOA enfoca la experiencia del usuario para ayudar a generar innovacin y ms colaboracin, lo que posibilita la interaccin consistente entre personas y procesos y, consecuentemente, aumenta la productividad productividad empresarial. Al usar SOA se puede, por ejemplo, crear portlets basados en servicios para aumentar esa colaboracin. Procesos: El punto de entrada relacionado con procesos ayuda las compaas a saber qu est sucediendo en los negocios, lo que les les permite mejorar los modelos empresariales ya existentes. Al usar SOA, puede transformar sus procesos empresariales en servicios reutilizables y flexibles, lo que le permite mejorar y optimizar los nuevos procesos. Informacin: Al usar ese punto de entrada entrada a SOA, puede sacar provecho a las informaciones de su compaa en forma consistente y visible. Al facilitar informaciones consistentes y confiables a todas las reas de la empresa, habilita todas las reas de la compaa a innovar y, consecuentemente, puede pu competir con ms eficiencia. Al usar SOA, se tiene un control mejor sobre sus informaciones; al alinear las informaciones a sus procesos empresariales, puede descubrir relaciones nuevas e interesantes. Conectividad: Aproveche el punto de entrada relacionado relacionado con la conectividad para conectar su infraestructura con eficiencia, integrando todas las personas, procesos e informaciones de su compaa. Al tener conexiones flexibles de SOA entre los servicios y en todo el entorno, puede tomar un proceso empresarial rial ya existente y ofrecerlo sin mucho esfuerzo a travs de otro canal empresarial. Puede incluso conectarse a socios externos fuera de su firewall en una forma segura. Reutilizacin: La reutilizacin de servicios con SOA permite aprovechar servicios que ya existen en la compaa. Al basarse en los recursos ya existentes, puede optimizar sus procesos empresariales, asegurar la consistencia en toda la compaa y reducir el tiempo de desarrollo. Todo ello ahorra tiempo y dinero. Usted tambin reduce la duplicacin duplicacin de funcionalidades en sus servicios y tiene la oportunidad de aprovechar las aplicaciones centrales comprobadas con las cuales el personal de su compaa est familiarizado.
Propiedades de soa
Algunas de las ms importantes propiedades de SOA son: Orientacin a la conversacin. El foco de atencin no est en los nodos sino en los mensajes que se intercambian entre los mismos. Vista Lgica: El servicio es una abstraccin (vista lgica) de los programas, bases de datos, procesos de negocio, etc. Orientacin tacin a Mensajes: El servicio se define formalmente en trminos de los mensajes que se intercambian entre agentes proveedores y solicitantes. Esto posibilita que se incorpore un componente decorando estos componentes con software de gestin y conversin. conversin Abstraccin del agente. La estructura interna del agente (lenguaje de programacin, BD, etc.) se abstrae en SOA, un nodo es una entidad computacional que participa en conversaciones con otros nodos. No es necesario conocer las particularidades del lenguaje lenguaje de implementacin. Esto evita problemas arquitectnicos derivados de la necesidad de conocer determinados sistemas a nivel estructural. Metadatos. SOA se asocian con metadatos, los mismos son descripciones acerca de la forma y tipo de los elementos que transportan los mensajes, el orden de los mensajes, el significado de los mensajes, etc. Orientacin a la Internet: Los servicios tienden a usarse a travs de la red, aunque este no es un requisito absoluto. Granularidad: Los servicios tienden a usar un un pequeo nmero de operaciones con mensajes complejos.
Neutral a la Plataforma: Los mensajes se envan en un formato estndar y neutral a la plataforma, utilizando XML Un sistema distribuido es un conjunto de agentes software que colaboran entre si para implementar una determinada funcionalidad. SOA es un tipo de sistema distribuido ya que los agentes rara vez trabajan en el mismo entorno, necesitando alguna forma de comunicacin entre ellos. En SOA los agentes son servicios que realizan una operacin determinada determinada y que puede ser invocado desde afuera del contexto de una gran aplicacin.
Desarrollo de servicios web con tecnologa java

Un servicio web ofrece una infraestructura nfraestructura independiente de lenguaje y plataforma para comunicacin. Un servicio web tiene las siguientes caractersticas: Independiente de lenguaje y plataforma: Separacin de la especificacin y la Implementacin. Desacoplada: Basa en mensajes con interaccin sncrona y asncrona. asncrona Sobre una Internet: No existe control centralizado, se usan protocolos pro bien establecidos y consideraciones de seguridad. seguridad Interoperable: Basado en estndares. estndares Aplicacin Aplicacin: Internet tradicional es Aplicacin Humano (SMTP, FTP, HTTP); esquemas RPC (procedural), ORB y COM (objetos), MOM (mensajes jms/mq) para aplicacin aplicacin dentro de una Internet sin considerar interoperar con otros sistemas.
Ejemplo de desarrollo web con tecnologa java

En este ejemplo resalizaremos un servicio web que devuelva un simple mensaje, el servicio web lo consumiremos desde una aplicacin java, y posteriormente se consumir a travs de una aplicacin web: Crear un proyecto Web Services con un mtodo que devuelva un String. Realizar un proyecto cliente que consuma el servicio web.
1.
Abrir un proyecto de tipo web y llamarlo llamar WSNombre.
2.
Elegir el servidor GlassFish para que posteriormente nos resulte ms sencillo enlazarnos al explorar sitios web.
3.
Agregamos un archivo de tipo WebService, le damos un nombre y un paquete donde guardarlo.
4.
En la pestaa diseo agregamos una nueva operacin. Esta opcin nos crear un mtodo pblico que ofreceremos a los clientes que quieran consumir el servicio.
5. Modificamos el cdigo que nos genera para devolver un mensaje predeterminado. @WebMethod(operationName ationName = "Nombre") public String Nombre() { return "Hola Pepe"; } EJECUTAR EL PROYECTO PARA QUE GENERE LOS ARCHIVOS NECESARIOS. 6. Creacin de un cliente que consuma el servicio. Seleccionamos un proyecto de tipo java application y le llamaremos remos ConsumirWSNombre.
7.
Agregamos un archivo de tipo Web Service Client.
8. 9.
Pulsamos sobre la opcin examinar y elegimos el servicio web recin creado.
10. Pulsamos botn derecho en cdigo sobre la clase que tiene el mtodo main y seleccionamos insert code y Call Web Service Operation. Por ltimo, elegimos el mtodo nombre.
11. Nos generar el cdigo necesario para invocar al mtodo. Probarlo llamando desde el mtodo main. public static void main(String[] args) { System.out.println(nombre()); } private static String nombre() { consumirwsnombre.WebService1Service service = new consumirwsnombre.WebService1Service(); consumirwsnombre.WebService1 port = service.getWebService1Port(); return port.nombre(); }
CONSUMIR EL SERVICIO WEB DESDE UN PROYECTO WEB

Crear un proyecto web y en la pgina jsp insertar el mismo cdigo que nos gener en la aplicacin cliente.
<%@page contentType="text/html" pageEncoding="UTF-8"%> pageEncoding="UTF <!DOCTYPE HTML PUBLIC "-//W3C//DTD //W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" Type" content="text/html; charset=UTF-8"> charset=UTF <title>JSP Page</title> </head> <body> <% consumirwsnombre.WebService1Service service = new consumirwsnombre.WebService1Service(); consumirwsnombre.WebService1 port = service.getWebService1Port(); %> <%= port.nombre()%> </body>
</html> Resultado:
API Java para Servicios Web XML (JAX-WS)

La especificacin JAX-WS WS proporciona soporte para servicios web que utiliza la API JAXB para vincular datos XML en objetos Java. La especificacin JAX-WS JAX WS define APIs clientes para acceder a servicios web as como tcnicas para implementar puntos puntos finales de servicios web. Los servicios web para la especificacin J2EE describen el despliegue de servicios basados en clientes JAX-WS. JAX La especificacin EJB y servlet tambin describe aspectos de ese desarrollo. Esto debe posibilitar el despliegue de aplicaciones basadas en JAX-WS WS utilizando cualquiera de estos modelos de despliegue. La especificacin JAX-WS WS describe el soporte para los manejadores de mensajes que pueden procesar mensajes de solicitud y respuesta. En general, estos manejadores de mensajes mensajes se ejecutan en el mismo contenedor y con los mismo privilegios y contextos de ejecucin que el JAX-WS JAX cliente o en el componente punto final con el que esta asociado. Estos manejadores de mensajes tienen acceso a el mismo espacio de nombres JNDI java:comp/env como su componente asociado. Serializadores y deserializadores a la medida, si son soportados, son tratados de la misma forma que los manejadores de mensaje. 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 d 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(). finaliz 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 un elemento WSDL operation con el mismo nombre del mtodo y dos elementos WSDL message, uno para la a 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 deben de ser tipos bsicos Java, clases anotadas con JAXB, arrays, Map, List o Collection de los anteriores. anter Tipos de Anotaciones JAX-WS Anotaciones que definen el mapeo WSDL (modifican el comportamiento por defecto): @WebService: Seala eala una clase o interfaz como endpoint de un servicio web. web Incluye ncluye atributos para modificar el nombre del elemento service, portType, el name space, etc (name, targetNamespace, amespace, serviceName, portName, wsdlLocation, endpointInterface) @WebMethod ermite modificar la definicin de las operaciones WSDL (atributo operationName) o excluir mtodos de Permite la clase que no se desean exponer como operaciones del web service (con el atributo exclude=true). exclude=true) @WebResult Permite ermite controlar el nombre del elemento message de WSDL que contendr el valor de retorno (atributo name). @WebParam Permite ermite configurar los elementos parameter de WSDL vinculados a los parmetros de una operacin (atributos: name, mode [IN, OU, INOUT], targetNamespace, header, partName) @OneWay Permite ermite indicar que un mtodo no tendr valor de retorno. retorno Existen tambin anotaciones notaciones que definien el binding SOAP de las operaciones y los lo mtodos: @SOAPBinding Para ara un mtodo de la clase endpoint especifica el estilo de codificacin de los mensajes (RPC vs. document) y el tipo de codificacin de los parmetros a usar (encoded vs.literal). Atributos: style, use, parameterStyle. @SOAPMessageHandler specifica detalles de la gestin de los mensajes (peticin y respuesta). Especifica
Atributos: name, className, initParams, roles, heards En el siguiente ejemplo consumiremos el servicio web que devuelve el tiempo meteorolgico
Servicio web tiempo po meteorolgico

Crear una aplicacin java que utilice el servicio web que nos devuelve la previsin meteorolgica en tiempo real. Utilizar los dos mtodos del servicio web.
Agregamos el archivo de tipo Web Service Client a nuestro proyecto de tipo java application.
Referencia al servicio web: http://www.webservicex.net/globalweather.asmx?WSDL Probamos el servicio recin referenciado.
public static void main(String[] args) { String tiempo=getWeather("MADRID","SPAIN"); System.out.println(tiempo); } private static String getCitiesByCountry(java.lang.String countryName) { MisServicios.GlobalWeather service = new MisServicios.GlobalWeather(); MisServicios.GlobalWeatherSoap port = service.getGlobalWeatherSoap(); return port.getCitiesByCountry(countryName); } private static String getWeather(java.lang.String cityName, java.lang.String countryName) { MisServicios.GlobalWeather service = new MisServicios.GlobalWeather(); MisServicios.GlobalWeatherSoap .GlobalWeatherSoap port = service.getGlobalWeatherSoap(); return port.getWeather(cityName, countryName); }
Ver Video: Analizando ServiciosWeb, en el Mdulo 8. Unidad 1, en la plataforma elearning
Laboratorio: Analizando ServiciosWeb

Objetivo
Consumir un proyecto Web Service de ASP.Net desde una aplicacin Java.
Enunciado
SERVICIO WEB MONEDAS ASP.NET Realizar un Servicio Web con ASP.NET cuya funcionalidad ser convertir Monedas. Podremos convertir entre diversas monedas a euros y viceversa, de euros a monedas. Las Monedas que vamos a convertir son: x DOLAR = 1,26201 Euros x PESOS = 14,4762 Euros x RUPIAS = 75,6061 Euros x YENES = 135,861 Euros x PESETAS = 166,386 Euros
SERVICIO WEB MONEDAS 1. Crear un servicio web con Visual Studio .Net con el cdigo siguiente: public double[] valores = new double[] { 1.26201, 14.4762, 75.6061, 135.861, 166.386 }; [WebMethod] public double convertirMonedaEuro(double valor, int indice) { return (valor * valores[indice]); } [WebMethod] public double convertirEuroMoneda(double valor, int indice) { return (valor / valores[indice]); } 2. Ejecutar el servicio.
EJEMPLO PRUEBA CONVERSIN DE MONEDAS 1. 2. Crear un proyecto en NetBeans de tipo java application y agregar un archivo de tipo WebService Client. Enlazarnos al servicio web recin creado. Colocamos la direccin del servicio seguido de WSDL.
http://localhost:2920/ServicioConvertirMonedas/Service.asmx?WSDL
public static void main(String[] args) { double resultado = convertirMonedaEuro(121,2); System.out.println(resultado); } private static Double convertirMonedaEuro(double valor, int indice) { ConsumirWS.NewWebServiceService service = new ConsumirWS.NewWebServiceService(); ConsumirWS.NewWebService port = service.getNewWebServicePort(); return port.convertirMonedaEuro(valor, indice); }
Unidad 2: Diseando Buenas Prcticas y Patrones para los Servicios Web

Objetivos
x x x Comprender los patrones de diseo en el contexto de los servicios web. Describir los patrones de diseo basados en servicios web. Implemetar patrones de diseo.
Introduccin
Un Patrn de Diseo (design pattern) es una solucin repetible a un problema recurrente en el diseo de software. Esta solucin no es un diseo terminado que puede traducirse directamente a cdigo, sino ms bien una descripcin sobre cmo resolver el problema, la cual puede ser utilizada en diversas situaciones. Los patrones de diseo reflejan todo el rediseo y remodificacin que los desarrolladores han ido haciendo a medida que intentaban conseguir mayor reutilizacin y flexibilidad en su software. Los patrones documentan y explican problemas de diseo, y luego discuten una buena solucin a dicho cho problema. Con el tiempo, los patrones comienzan a incorporarse al conocimiento y experiencia colectiva de la industria del software, lo que demuestra que el origen de los mismos radica en la prctica misma ms que en la teora. La definicin de Christopher Christopher Alexander sobre patrones: cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, as como la solucin a ese problema, de tal modo que se pueda aplicar esta solucin un milln de veces, sin hacer lo mismo dos veces. Si bien sta ta definicin es sobre patrones de ciudades y edificios la idea es aplicable a la industria del software: encontrar una solucin a un problema dentro de un contexto. Un patrn de diseo nomina, abstrae e identifica los aspectos clave de una estructura de diseo d comn, lo que los hace tiles para crear un diseo orientado a objetos reutilizable. El patrn de diseo identifica las clases e instancias participantes, sus roles y colaboraciones, y la distribucin de responsabilidades. Cada patrn de diseo se centra ntra en un problema concreto, describiendo cundo aplicarlo y si tiene sentido hacerlo teniendo en cuenta otras restricciones de diseo, as como las consecuencias, ventajas e inconvenientes de su uso. En los ltimos aos los patrones han ido ganando aceptacin, acept y se fueron extendiendo a otras reas dentro del desarrollo y mantenimiento de software. Su utilizacin, si bien todava le queda mucho camino por recorrer, comienza a tener suficiente madurez. Los patrones de diseo proveen una forma efectiva para compartir experiencia con la comunidad de programadores de software orientado a objetos. El trmino patrn de diseo no es extremadamente preciso pero s muy til. En la forma en la que se suele entender actualmente fue acuado en Gamma y col.(1994), importante importante referencia que se suele designar abreviadamente como GoF1. Por la manera en que se emplea este concepto en esta referencia bsica y en la mayora de usos posteriores, se refiere a una manera especialmente inteligente y perspicaz de resolver un tipo o general de problema. A pesar de constar el trmino diseo no se suele considerar que se refiera nicamente a la fase de diseo de un programa, es una solucin completa que incluye anlisis, diseo e implementacin. Un patrn de diseo no se considera considera bien especificado hasta que se ha podido plasmar en forma de cdigo en algn lenguaje, pero claramente no es una convencin o receta idiomtica, ligada a un lenguaje concreto, como podra la relacionada con cmo recorrer de forma eficiente un vector en e C empleando aritmtica de punteros, por poner un ejemplo. Sin embargo, en GoF se remarca que un patrn puede serlo, tener sentido identificarlo como tal o no, dependiendo del lenguaje utilizado. En el lenguaje de implementacin elegido en GoF, C++, un patrn patrn como herencia no tiene sentido (ya est implcito en el propio lenguaje) mientras que sera una solucin general muy adecuada a numerosos
problemas si el lenguaje de implementacin fuese C, por ejemplo. Tampoco hay que confundir patrn de diseo con un algoritmo adecuado para resolver un tipo concreto de problema que, lgicamente, se tendra que implementar de forma distinta segn el lenguaje. Un patrn de diseo debe ser una especificacin muy general, una especie de invariante que se cumple en problemas de mbitos diversos y que define una solucin general y muy estable. Los desarrolladores de software han aprendido a reutilizar cdigo y de esa manera tendrn su marco de trabajo bsico para usar cuando se enfrenten a problemas de similares caractersticas. carac Una de las formas de solucionar estos problemas de manera eficiente y efectiva es la utilizacin de los Patrones de Diseo. Una notacin prctica y aceptada para la especificacin, visualizacin, construccin y documentacin de sistemas de software software es UML que permite la construccin de una serie de diagramas que facilitan el desarrollo y comunicacin de un proyecto de software. . Dado que UML es un lenguaje que permite ser extendido y que los Patrones de Diseo aportan buenas soluciones a problemas emas recurrentes, este Trabajo Final tiene como objetivo extender UML e incorporarle el uso de Patrones de Diseo para ampliar las potencialidades de este lenguaje y brindar al desarrollador de software la posibilidad de incorporar Patrones de Diseo en sus su proyectos. Actualmente, los patrones de diseo son, sin duda, alguna la herramienta ms importante de la que disponemos los ingenieros, arquitectos, analistas, desarrolladores, etc., para la creacin de sistemas robustos, escalables, fcilmente adaptables adaptables y con grandes cotas de reutilizacin. Se han escrito miles y miles de lneas sobre las ventajas de los patrones de diseo, pero sin embargo, pocos han sido los anlisis de los problemas asociados a su uso. Son una forma de formalizar la reusabilidad de cdigo ante situaciones similares a las ya conocidas. . Se plantean como una buena herramienta para el diseo y la documentacin de aplicaciones y frameworks. . Son descripciones de objetos y clases que se comunican y que son capaces de solucionar un problema lema de diseo en general, en un contexto en particular. . "Cada patrn describe un problema que ocurre una y otra vez en nuestro entorno, para describir despus el ncleo de la solucin a ese problema, de tal manera que esa solucin pueda ser usada ms de un milln de veces sin hacerlo ni siquiera dos veces de la misma forma". (Alexander Christopher) Proponen una forma de reutilizar la experiencia de los programadores. Contribuyen a dar flexibilidad y extensibilidad a los diseos. Contribuyen a reutilizar reutilizar diseo, identificando aspectos claves de la estructura de un diseo que puede ser aplicado en una gran cantidad de situaciones. Mejoran (aumentan, elevan) la flexibilidad, modularidad y extensibilidad.. Incrementan el vocabulario de diseo, ayudando a disear sear desde un mayor nivel de abstraccin.
Elementos: x x x x x x x Nombre: resume la esencia del patrn. . Clasificacin: segn el propsito - Qu hacen? - y el alcance - Dnde se aplican? - . Sinopsis: responde a Qu hace el patrn? . Contexto: ejemplo que ilustra el problema y cmo se estructuran clases y objetos para solucionarlo. . Aplicabilidad: situaciones en las que puede aplicarse el patrn. . Estructura: representacin grfica de las clases que intervienen y sus relaciones. . Participantes: Participan clases, objetos y responsabilidades. . Consecuencias: resultados y cambios al usar el patrn. . Diagrama de Ejemplo: diagrama del modelo del usuario que usa el/los estereotipo/s que forma/n el patrn y en el que se cumplen las Reglas OCL.
Clasificacin: Segn el Propsito: Qu hacen?
x x x x x x
. Creacionales: relacionados con el proceso de creacin de objetos. . de Comportamiento: relacionados con la interaccin de clases y objetos y la distribucin de responsabilidades. . Estructurales: relacionados con la l composicin de clases y objetos. Segn el Alcance: Dnde se aplican? . Clase: tratan la relacin entre subclases a travs de herencia. . Objeto: tratan la relacin entre objetos que cambian en tiempo de ejecucin.
Disear una arquitectura basada en patrones patrones de diseo es una tarea compleja, que reporta muchos beneficios, pero prcticamente imposible sin un estudio previo del dominio del problema que estamos tratando. El uso de lenguajes de modelado como UML nos ayuda a ver mejor las propiedades del sistema a que estamos diseando y harn aparecer relaciones entre los componentes que a primera vista eran difusas o que simplemente no habamos visto. El mero hecho de utilizar patrones de diseo y comenzar a realizar su implementacin sin tener en cuenta el dominio dominio de nuestro modelo, es un error gravsimo y degenera en la prctica de ir esparciendo patrones por las diferentes partes de un proyecto sin ningn criterio general. Estos patrones no representarn ningn concepto de nuestro dominio, probablemente no reflejarn re ningn significado a alguien que no est familiarizado con nuestro proyecto, y dificultarn notablemente la extensibilidad de nuestro proyecto obligando a una refactorizacin continua. Antes de abordar un proyecto con patrones hemos de analizar minuciosamente minuciosamente qu patrones nos pueden ser tiles, cules son las relaciones entre los diferentes componentes de nuestro sistema, cmo podemos relacionar los patrones entre s de modo que formen una estructura slida, cules son los patrones que refleja nuestro tro dominio, etc. Esta tarea obviamente es mucho ms compleja que el mero hecho de ponerse a codificar patrones. Existen cientos y cientos de patrones que han ido apareciendo con el tiempo y que se han convertido en soluciones estndar para diferentes problemas, problemas, y por supuesto no limitados al mbito informtico sino que podemos encontrar patrones de arquitectura, de economa, etc. As que la clave de todo es la experiencia puede que hayamos realizado un anlisis fantstico y que hayamos estudiado los patrones patro ms avanzados en el mbito que estamos afrontando, sin embargo, sin la experiencia adecuada nuestro proyecto fracasar. Sea como sea, la experiencia se adquiere con el tiempo y a base de tropiezos. Seguramente nuestros primeros proyectos no queden como los habamos ideado en su concepcin, y con el tiempo, nos demos cuenta de que podramos haber utilizado otros mtodos para abordar de un modo ms eficiente los problemas con los que nos habamos enfrentado. La primera regla de los patrones de diseo coincide coincide con la primera regla de la optimizacin: retrasar. Del mismo modo que no es aconsejable optimizar prematuramente, no se deben utilizar patrones de diseo antes de tiempo. Seguramente sea mejor implementar algo primero y asegurarse de que funciona, para ra luego utilizar el patrn de diseo para mejorar las flaquezas; esto es cierto, sobre todo, cuando an no ha identificado todos los detalles del proyecto (si comprende totalmente el dominio y el problema, tal vez sea razonable utilizar patrones desde el principio, de igual modo que tiene sentido utilizar los algoritmos ms eficientes desde el comienzo en algunas aplicaciones). Los patrones de diseo pueden incrementar o disminuir la capacidad de comprensin de un diseo o de una implementacin, disminuirla la al aadir accesos indirectos o aumentar la cantidad de cdigo, disminuirla al regular la modularidad, separar mejor los conceptos y simplificar la descripcin. Una vez que aprenda el vocabulario de los patrones de diseo le ser ms fcil y ms rpido comunicarse c con otros individuos que tambin lo conozcan. Por que atraviesa una estructura y realiza llamadas de retorno, en tanto que algunos mtodos deben estar presentes y son llamados de este modo y en este orden. La mayora de las personas utiliza patrones patrones de diseo cuando perciben un problema en su proyecto algo que debera resultar sencillo no lo es o su implementacin como por ejemplo, el rendimiento.
Examine un cdigo o un proyecto de esa naturaleza. Cules son sus problemas, cules son sus compromisos? ompromisos? Qu le gustara realizar que, en la actualidad, es muy difcil lograr? A continuacin, compruebe una referencia de patrn de diseo y busque los patrones que abordan los temas que le preocupan.
Componentes fundamentales
Para que una solucin sea ea considerada un patrn debe poseer ciertos componentes fundamentales: x x Nombre del patrn. Permite describir en pocas palabras un problema de diseo junto con sus soluciones y consecuencias. Problema (o fuerzas no balanceadas). Indica cundo aplicar el patrn. En algunas oportunidades el problema incluye una serie de condiciones que deben darse para aplicar el patrn. Muestra la verdadera esencia del problema. Este enunciado se completa con un conjunto de fuerzas, trmino que se utiliza para indicar cualquier cualquier aspecto del problema que deba ser considerado a la hora de resolverlo, entre ellos: - Requerimientos a cumplir por la solucin. - Restricciones a considerar. - Propiedades deseables que la solucin debe tener.
Son las fuerzas las que ayudan a entender el problema problema dado que lo exponen desde distintos puntos de vista. x Solucin. No describe una solucin o implementacin en concreto, sino que un patrn es ms bien como una plantilla que puede aplicarse en diversas situaciones diferentes. El patrn brinda una descripcin cripcin abstracta de un problema de diseo y cmo lo resuelve una determinada disposicin de objetos. Que la solucin sea aplicable a diversas situaciones denota el carcter recurrente de los patrones. Consecuencias. Resultados en trminos de ventajas e inconvenientes.
Tipos de patrones
Segn el nivel de abstraccin los patrones de diseo pueden clasificarse de la siguiente forma: x Patrones arquitectnicos. Centrados en la arquitectura del sistema. Definen una estructura fundamental sobre la organizacin del sistema. Proveen un conjunto predefinido de subsistemas, cules son sus responsabilidades y como se interrelacionan. Patrones de diseo. Esquemas para refinar los subsistemas o componentes de un sistema de software, o sus relaciones. Describen una estructura estructura recurrente y comn de componentes comunicantes que resuelven un problema de diseo dentro de un contexto.
Ejemplo: el patrn singleton asegura que exista slo una instancia de una determinada clase. Patrones de codificacin o modismos (idioms). Patrones Patrones que ayudan a implementar aspectos particulares del diseo en un lenguaje de programacin especfico. Ejemplo: en Java implementar una interface en una clase annima. Los patrones arquitectnicos podran considerarse estrategias de alto nivel que abarcan abarc componentes a gran escala, propiedades y mecanismos del sistema. Tienen implicancias muy amplias que afectan tanto a la estructura como a la organizacin del sistema. Los patrones de diseo son tcticas de medio nivel para profundizar en la estructura y comportamiento de ciertos componentes y sus relaciones. Los patrones de diseo no influencian la estructura del sistema sino que definen micro-arquitecturas micro para los subsistemas y componentes. Por ltimo, los modismos son tcnicas especficas del paradigma paradigm y lenguaje de programacin que complementan detalles de bajo nivel (internos o externos) de la estructura de un componente.
Patrones Creacionales. Los patrones creacionales abstraen el proceso de instanciacin de objetos, ayudando a que el sistema sea independiente dependiente de cmo se crean, componen y representan sus objetos. Estos patrones encapsulan el conocimiento sobre las clases concretas que utiliza el sistema. En otras palabras, estos patrones brindan soporte a una de las tareas mas comunes dentro de la programacin pr orientada a objetos: la instanciacin. Estos patrones brindan las siguientes caractersticas: x x x Instanciacin genrica: permite que los objetos sean creados dentro del sistema sin especificar clases concretas en el cdigo. atrones facilitan la creacin de objetos, evitando que el cliente deba tener Simplicidad: algunos patrones cdigo complejo sobre como instanciar un determinado objeto. Restricciones creacionales: algunos patrones ayudan a establecer restricciones sobre la creacin de objetos, tales como mo qu objeto crear, cundo, cmo, etc.
Por lo general, son alternativas de diseo bajo estrategias de herencia o delegacin que encapsulan el mecanismo de creacin, independizando los tipos de objetos producto que se manejan. Los patrones creacionales son los siguientes: 1. Singleton: asegura que ue una determinada clase sea instanciada una y slo una vez, proporcionando un nico punto de acceso global a ella. 2. Abstract Factory: provee una interfaz para crear familias de objetos producto relacionados o que dependen entre si, sin especificar sus clases cla concretas. 3. Factory Method: define una interfaz para crear un objeto delegando la decisin de qu clase crear en las subclases. Este enfoque tambin puede ser llamado constructor virtual. 4. Builder: separa la construccin de un objeto complejo de su representacin, representacin, de forma que el mismo proceso de construccin pueda crear diferentes representaciones. Simplifica la construccin de objetos con estructura interna compleja y permite la construccin de objetos paso a paso. Ejemplo: este patrn se encuentra en los restaurantes de comidas rpidas que preparan mens infantiles. Generalmente estos mens estn formados de un plato principal, un acompaamiento, una bebida y un juguete. Si bien el contenido del men puede variar, el proceso de construccin es siempre siempre el mismo: el cajero indica a los empleados los pasos a seguir. Estos pasos son: preparar un plato principal, preparar un acompaamiento, incluir un juguete y guardarlos en una bolsa. La bebida se sirve en un vaso y queda fuera de la bolsa. 5. Prototype: facilita acilita la creacin dinmica de objetos mediante la definicin de clases cuyos objetos pueden crear duplicados de si mismos. Estos objetos son llamados prototipos. Ejemplo: un escenario frecuente es contar con GUIs (Interfaz Grfica de Usuario) que cuenten con un gran nmero de controles similares, los cuales deben ser inicializados a un determinado estado comn para mantener consistencia. El proceso de inicializacin se repite varias veces por cada control de manera que las lneas de cdigo se incrementan. Con el fin de optimizar estas partes del cdigo se puede contar con un objeto inicializado en un determinado estado estndar y luego obtener clones de l ya inicializados. Patrones estructurales. Se encargan de cmo se combinan clases y objetos parar formar ar estructuras ms grandes. Los patrones estructurales de clases utilizan la herencia para componer interfaces o implementaciones. En lugar de combinar interfaces o implementaciones, los patrones estructurales de objetos describen formas de componer objetos s para obtener nuevas funcionalidades. La flexibilidad aadida mediante la composicin de objetos viene dada por la capacidad de cambiar la composicin en tiempo de ejecucin, que es imposible con la composicin de clases. Ejemplos tpicos son cmo comunicar comunic dos clases incompatibles o cmo aadir funcionalidad a objetos. Los patrones estructurales son los siguientes: 6. Adapter: oficia de intermediario entre dos clases cuyas interfaces son incompatibles de manera tal que puedan ser utilizadas en conjunto. Ejemplo: Ejemplo: en la vida cotidiana se ven ejemplos de este patrn, quiz el ms comn de ellos sea el de los adaptadores de enchufes el cual permitira utilizar un enchufe de dos patas planas adaptndolo a un toma corriente de dos patas redondas.
7. Bridge: disocia un componente complejo en dos jerarquas de clases: una abstraccin funcional y la implementacin interna, para que ambas puedan variar independientemente. Ejemplo: los electrodomsticos y sus interruptores de encendido pueden ser considerados como ejemplos ejemplo de este patrn donde el interruptor de encendido es considerado la abstraccin y el electrodomstico en si la implementacin. El interruptor podra ser un simple interruptor de encendido/apagado, un regulador de velocidades u alguna otra opcin, mientras que el electrodomstico puede ser una lmpara, un ventilador de techo, etc. 8. Composite: compone objetos en estructuras de rboles para representar jerarquas parte-todo. parte Permite que los clientes traten de manera uniforme a los objetos individuales y a los complejos. Ejemplo: en una grfica de Gantt existen tareas simples (con una actividad) y compuestas (que contienen varias tareas). Modelar estos dos tipos de tareas en una jerarqua de clases donde ambas son subclases de una clase que cuente con un mtodo calculTiempoUtilizado permitira tratar de forma uniforme a tareas simples y compuestas para calcular el tiempo utilizado por cada una de ellas. Concretamente una tarea simple informa el tiempo dedicado a ella, mientras que una compuesta lo hace sumando sumando los tiempos insumidos de cada una de las tareas que contiene. 9. Decorator: agrega o limita responsabilidades adicionales a un objeto de forma dinmica, proporcionando una alternativa flexible a la herencia para extender funcionalidad. Ejemplo: si bien es cierto que se pueden colgar pinturas, cuadros y fotos en las paredes sin marcos, stos suelen ser utilizados a menudo y son ellos los que se cuelgan en la pared en lugar de su contenido (pinturas, cuadros, etc.). Al momento de colgarse los cuadros junto con co su marco pueden formar un solo componente visual 10. Facade: proporciona una interfaz simplificada para un conjunto de interfaces de subsistemas. Define una interfaz de alto nivel que hace que un subsistema sea ms fcil de usar. Ejemplo: En un sistema de compras los clientes contactan a un responsable de ventas que acta como Facade al momento de realizar un pedido. Este representante de ventas acta como Facade proveyendo una interface con los departamentos (subsitemas) de pedidos, pedidos, facturacin y envos. 11. Flyweight: permite el uso de un gran nmero de objetos de grano fino de forma eficiente mediante compartimiento. Ejemplo: La red telefnica pblica conmutada es un ejemplo de este patrn ya que hay diversos componentes, como por ejemplo nodos de conmutacin, conmutaci que se deben compartir entre los distintos usuarios. Los usuarios no conocen cuntos componentes de cada tipo hay disponibles al momento de realizar la llamada. Lo nico por lo que se preocupan los usuarios es por obtener tono para marcar, poder discar y efectuar la llamada. 12. Proxy: Provee un sustituto o representante de un objeto para controlar el acceso a ste. Este patrn posee las siguientes variantes: - Proxy remoto: se encarga de representar un objeto remoto como si estuviese localmente. - Proxy virtual: se encarga de crear ar objetos de gran tamao bajo demanda. - Proxy de proteccin: se encarga de controlar el acceso al objeto representado. Patrones de comportamiento Tienen que ver con algoritmos y asignacin de responsabilidades. Estos patrones se focalizan en el flujo de control dentro de un sistema. Ciertas formas de organizar los controles dentro del sistema pueden llevar a grandes beneficios en cuanto a mantenibilidad y eficiencia. Algunos ejemplos de estos patrones incluyen la definicin de abstracciones de algoritmos, las colaboraciones entre objetos para realizar tareas complejas reduciendo las dependencias o asociar comportamiento a objetos e invocar su ejecucin. Los patrones de comportamiento basados en clases utilizan la herencia para distribuir el comportamiento entre clases, ellos son: Template Method e Interpreter. Mientras que los basados en objetos utilizan la composicin. Los patrones de comportamiento son los siguientes: 13. Chain of responsibility: establece una cadena de mensajes dentro del sistema de manera tal que dicho mensaje sea manejado en el mismo nivel donde fue emitido, o redirigido a un objeto capaz de manejarlo. Evita acoplar el emisor del mensaje con un receptor, dando a ms de un objeto la posibilidad de responder al mensaje. 14. Command: representa una solicitud con un objeto, de manera tal de poder parametrizar a los clientes con distintas solicitudes, encolarlas o llevar un registro de las mismas, y poder deshacer
15.
16.
17.
18.
19.
20.
21.
las operaciones. Estas solicitudes, al ser representadas como un objeto tambin pueden puede pasarse como parmetro o devolverse como resultados. Interpreter: en un contexto donde se repite una determinada clase de problemas y el dominio es bien conocido, se pueden caracterizar estos problemas como un lenguaje y, a su vez, estos problemas pueden n ser tratados por un motor de interpretacin. Este patrn busca definir un intrprete para dicho lenguaje, para el cual define una gramtica y un intrprete de la misma para poder resolver los problemas. Ejemplo: distintos motores de bases de datos (Oracle, (Ora SQL Server, Sybase, DB2, etc.) utilizan distintos cdigos de error para indicar fallas (errores de clave duplicada, violacin de restricciones de integridad referencial, longitud de datos, etc.). La utilizacin de ste patrn permitira definir un intrprete intrprete de errores para cada motor de base de datos con el cual se determinara la falla y tomaran las acciones pertinentes en funcin de la misma. El sistema debe configurarse para utilizar el interprete adecuado segn el motor de base de datos. Iterator: r: provee un modo de acceder secuencialmente a los elementos de un objeto agregado (una coleccin) sin exponer su representacin interna. El iterador est altamente acoplado al objeto agregado. Ejemplo: Los rboles-B rboles B pueden recorrerse de tres formas distintas: distin pre-orden, en-orden y post-orden. orden. La aplicacin de este patrn permitira definir un iterador para cada tipo de recorrido, pudiendo ser utilizados para recorrer el rbol sin exponer su contenido. Mediator: simplifica la comunicacin entre objetos dentro dentro del sistema mediante la introduccin de un objeto mediador que administra la distribucin de mensajes entre objetos. Promueve bajo acoplamiento al evitar que los objetos se referencien unos a otros explcitamente, permitiendo variar la interaccin entre e ellos independientemente. Ejemplo: Este patrn puede verse en las torres de control de los aeropuertos. Los pilotos de los aviones que se encuentran por despegar o aterrizar se comunican con la torre en lugar de hacerlo explcitamente entre ellos. La torre tor de control regula quien puede aterrizar y despegar, pero no se encarga de controlar todo el vuelo. Memento: preserva una fotografa instantnea del estado de un objeto con el fin de permitirle volver a su estado original, sin revelar su contenido al mundo exterior. Ejemplo: una funcionalidad muy importante de los editores de texto es Deshacer o Undo, esta funcionalidad puede implementarse va Memento. Para realizar esto se debe considerar al contenido del documento como estado del editor y ante cada cada cambio del documento se debe tomar una nueva fotografa del estado del documento antes de la modificacin, para poder volver al mismo. Dos factores importantes deben ser tenidos en cuenta: el orden de guardado de los cambios, para poder deshacerlos correctamente ectamente y cuando limpiar el registro de estados intermedios ya que esto puede consumir muchos recursos. Observer: brinda un mecanismo que permite a un componente transmitir de forma flexible mensajes a aquellos objetos que hayan expresado inters en l. Estos mensajes se disparan cuando el objeto ha sido actualizado, y la idea es que quienes hayan expresado inters reaccionen ante este evento. Ejemplo: este patrn puede verse en las subastas donde cada ofertante (Observer) tiene un indicador con su nmero, nmero, el cual es utilizado para indicar la aceptacin de una oferta. El subastador(Subject, objeto observado) comienza la subasta con una oferta inicial, cuando un ofertante toma esa oferta el subastador les retransmite a todos los ofertantes que el precio ha cambiado. State: permite que un objeto modifique su comportamiento cada vez que cambie su estado interno. El objeto parecer que cambi de clase. Ejemplo: este patrn puede observarse en las mquinas expendedoras de golosinas, las cuales pasan por distintos distintos estados: stock disponible, dinero depositado, capacidad para dar vuelto, golosina seleccionada, etc. En cada uno de stos estados la mquina se comporta distinta. Cuando se deposita dinero y se elije una golosina la expendedora puede entregar un producto producto y no cambiar su estado, entregar un producto y cambiar su estado (por ejemplo quedarse sin stock, en cuyo caso no entregar mas golosinas, o no entregar golosinas ya sea por falta de stock o cambio). Strategy: define una jerarqua de clases que representan representan algoritmos, los cuales son intercambiables. Estos algoritmos pueden ser intercambiados por la aplicacin en tiempo de ejecucin. Ejemplo: Se dispone de un programa que encripta y desencripta mensajes de texto
usando distintos algoritmos de encriptacin. encriptacin. Cada uno de estos algoritmos de encriptacin puede modelarse como una clase con servicios de encriptacin (un mtodo encriptaMensaje que recibe el texto llano y una clave, para devolver un texto cifrado y servicios de desencriptacin (un mtodo desencriptaMensaje desencriptaMensaje que recibe una clave y un texto cifrado para devolver uno descifrado). 22. Template Method: define en una operacin el esqueleto de un algoritmo, delegando en las subclases algunos de sus pasos. Permite que las subclases redefinan ciertos pasos del algoritmo sin cambiar su estructura. 23. Visitor: representa una operacin sobre elementos de una estructura de objetos. Permite definir una nueva operacin sin cambiar las clases de los elementos sobre los que opera. Brinda una forma sencilla y mantenible le de realizar acciones sobre una familia de clases. Ejemplo: un compilador interpreta cdigo fuente y lo representa como un rbol de sintaxis abstracta (Abstract Syntax Tree, AST), el cual cuenta con diversos tipos de nodos (asignaciones, expresiones condicionales, icionales, etc.). Sobre este rbol se desean ejecutar algunas operaciones como: revisar que todas las variables fueron declaradas, chequeos de tipos de datos, generacin de cdigo, etc. Una forma de realizar estas operaciones es mediante la implementacin del patrn Visitor, el cual recorrer toda la estructura del rbol. Cuando un nodo acepte al Visitor, ste invocar al mtodo de visita definido en el Visitor que toma por parmetro al nodo siendo visitado.
Patrones atrones de diseo basados en servicios web

Para el desarrollo de aplicaciones orientadas a servicio utilizando arquitecturas SOA, se han desarrollado una serie de patrones de software. Estos patrones se pueden dividir en cinco categoras:
Aprendizaje
Es importante entender el entorno de los servicios Web. Dentro de esta categora podemos encontrar: Service-Oriented Oriented Architecture: Es el patrn que forma la arquitectura de los servicios Web como ya hemos visto anteriormente. Architecture Adapter. Se puede de ver como un patrn genrico que facilita la comunicacin entre arquitecturas. Service Directory: Este patrn facilita la transparencia en la localizacin de servicios, permitiendo realizar robustas interfaces para encontrar el servicio que realmente se s quiere.
Adaptacin
Estos patrones son los llamados bsicos para conocer el funcionamiento del entorno de los Servicios Web. En esta categora nos encontramos: x Business Object: Un business object engloba a un concepto de negocio del mundo real como puede ede ser un cliente, una compaa o un producto, por ejemplo, y lo que pretende este patrn es trasladar el concepto de objeto de negocio dentro del paradigma de los servicios Web. Business Process: Este patrn se utiliza para tratar con procesos de negocio. negocio. En este momento existen dos estndares: o Business Process Execution Lenguaje (BPEL) propuesto por Bea Systems, IBM y Microsoft. o Business Process Modeling Languaje (BPML) propuesto por el resto de compaas que no estn en el grupo anterior como pueden pueden ser WebMethods, SeeBeyond, etc. Bussines Object Collection: Con este patrn se pueden realizar composiciones de procesos de negocio. Asynchronous Bussines Process: Este patrn es la evolucin del patrn anterior Bussines Process.
x x
Determinando Cambios
Aunque los servicios Web permiten llamadas asncronas, las implementaciones del servicio pueden estar basados en paso de mensajes, tambin son importantes los servicios basados en eventos, estos patrones se basan en patrones tradicionales como el Observer o el patrn Publicacin/Suscripcin. En esta categora podemos encontrar: o Event Monitor: Es un patrn para crear formas efectivas para integrar aplicaciones sin la intervencin de otros componentes. El escenario ms comn donde se utiliza este patrn es para aplicaciones EAI (Enterprise Application Integration). Observer Services: Este patrn representa la manera ms natural de detectar cambios y actuar en consecuencia. Publish/Subscribe Services: Es la evolucin del Observer Pattern, mientras que el patrn pa Observer se base en el registro, el patrn Publish/Subscribe se base en notificaciones, esto permite que distintos servicios puedan enviar la misma notificacin.
o o
Redefinicin
Estos patrones te permiten acceder al comportamiento de un servicio que est implementado en un lenguaje. Ayudan a entender el entorno del Servicio Web y a moldear este entorno de acuerdo con nuestras necesidades. En esta categora podemos encontrar: o Physical ical Tires: Este patrn ayuda a estructurar mejor la lgica de negocio de los servicios Web, e incluso se puede utilizar para controlar el flujo de negociaciones que puede llegar a producirse utilizando el patrn Publish/Subscribe. Connector: Este patrn se suele utilizar con el anterior para resolver los posibles problemas que surgen en la subcripcin. Faux Implementation: Es una alternativa para resolver los problemas que surgen en la utilizacin de eventos en los servicios Web. Es simplemente un socket socket abierto que recibe conexiones y aporta las respuestas para los distintos eventos.
o o
Creando flexibilidad
Para crear servicios ms flexibles y optimizados. En esta categora se encuentran: o Service Factory: Es uno de los patrones ms importantes y permite permite la seleccin de servicios y aporta flexibilidad en la instanciacin de los componentes que crean los servicios Web. Este patrn tambin se suele utilizar con el patrn Service Cache para aportar una mayor flexibilidad en el mantenimiento de las aplicaciones aplicaciones que utilizan servicios Web, aportando un mayor ROI a las aplicaciones. Data Transfer Object: Este patrn aporta rendimiento ya que permite recoger mltiples datos y enviarlos en una nica llamada, reduciendo el nmero de conexiones que el cliente tiene ti que hacer al servidor. Partial Population: Este patrn permite a los clientes seleccionar nicamente los datos que son necesarios para sus necesidades y slo recuperar del servidor lo necesario. Este patrn adems de rendimiento aporta mayor ancho de banda en la red. Algunos patrones utilizan otros por ejemplo el Business Process Patern usa el Business Object Patern y el Business Object Collection. Y el Service-Oriented Service Oriented Architecture usa los patrones Service Directory y Architecture Adapter.
Buenas practicas para desarrollar servicios web SOAP

Es importante conocer las prcticas ms recomendables a la hora de desarrollar servicios web SOAP. Comentaremos en este bloque las prcticas ms recomendables:
Analizar qu servicios web y con qu operaciones hay que desarrollar

Debemos analizar y disear servicios web con las responsabilidades bien repartidas, que sean cohesivos, extensibles, escalables y reutilizables.
Escribe tu mismo el fichero WSDL (Contract-First) (

Es el interfaz, el contrato y, en definitiva, definitiva, la clave para una interoperabilidad real e independiente de la tecnologa. Adems los generadores de WSDL pueden introducir dependencias con una tecnologa concreta. Por eso merece la pena aprender a escribir WSDL y schemas XSD.
Ms eficiente un nico co mensaje enorme

A la hora de disear el interfaz de las operaciones, ten siempre en cuenta que un solo mensaje es mucho ms rpido que el equivalente en multiples mensajes.
S coherente con la nomenclatura de namespaces de la organizacin

No hay nada que de peor impresin que un servicio web que no ha cuidado los namespaces.
El WSDL debe ser compatible con el WS-I WS Basic Profile

El WS-I I Basic Profile es un conjunto de especificaciones y buenas prcticas definidas por la industria para obtener servicios web interoperables. interoperables
Usa http://localhost:puerto como direccin url del endpoint

Deja que sea el motor de webservices el encargado de sustituirla por la real. As evitars tener un fichero WSDL por entorno.
Separa la definicin de los mensajes del fichero WSDL. WSD

Disea por separado un schema XSD donde se definan los mensajes y que sea importado por el fichero WSDL. Las principales ventajas son que se reduce el tamao/complejidad del WSDL, permite utilizar editores especializados para el diseo del schema XSD y permite reutilizar schemas y namespaces.
Define los mensajes de forma detallada mediante las restricciones de los schemas XSD
De esta forma podrs validar los mensajes a nivel de XML mediante el api XML u OXM que uses, sin necesidad de implementar cdigo propio.
Crea tipos y elementos globales

A la hora de disear el schema XSD, (a nivel raz) para poder reutilizarlos, tanto a nivel de elementos XML como clases del lenguaje de implementacin del servicio web.
Envio de ficheros adjuntos

Si necesitas enviar r ficheros adjuntos (attachments), hazlo a nivel de http attachment y no como un elemento del mensaje XML.
Automatizacin
Automatizaremos el proceso de generar el Skeleton y las clases OXM de mensajes del servicio web a partir del WSDL (wsdl2code).
Programar ar tus tests a nivel de la clase Skeleton
Para realizar pruebas unitarias del servicio web no necesitas desplegarlo. Ahorraras mucho tiempo y ya desplegars para las pruebas de integracin o alguna demo.
Guarda log
El de los mensajes de entrada y salida junto junto con datos del cliente (ip, usuario), a nivel de fichero o base de datos.
Organizando los archives WSDL (Web Services Definition Language)

WSDL es un archivo XML estndar utilizado para describir totalmente un servicio web x x Los archivos WSDL pueden publicarse icarse en un registro UDDI para simplificar su distribucin La mayora de las herramientas de desarrollo permiten crear un cliente para un servicio a partir del archivo WSDL que lo describe.
Un archivo WSDL est dividido en cuatro secciones que representan: x x x x El protocolo (HTTP, JMS, etc.), ubicacin del servicio y caractersticas del mensaje SOAP Las operaciones soportadas por el servicio web Los mensajes que intercambian cliente y mtodos del servicio web al invocar el servicio La estructura de los datos includos en los mensajes, descritos usando XML-Schema XML Schema
Los archivos WSDL pueden contener hasta cuatro partes
<definitions> <types> Si se intercambian tipos complejos, estos se definen en esta seccin y son referenciados por los mensajes. Un mismo m tipo puede ser referenciado por mltiples mensajes. </types> <message> Un mensaje es la estructura de datos eviado a o regresado por un servicio. Un mensaje puede ser usado por mltiples ports, por lo que el resultado de un servicio puede ser el input de otro servicio. </message> <portType>
Es en esta seccin en la que se describen todas las operaciones del servicio web con referencias a los mensajes de entrada y salida enviados y recibidos por cada operacin. </portType> <binding> Esta seccin define el formato del mensaje SOAP asi como los protocolos de transporte soportados para accesar el servicio </binding> </definitions>
Ejemplo de un archivo WSDL incompleto

<message name="romanNumber"> <part name="term" type="xs:string"/> </message> <message name="decimalNumber"> <part name="value" type="xs:nonNegativeInteger"/> </message> <portType name="romanNumbers"> <operation name="romanToDecimal"> <input message="romanNumber"/> <output message="decimalNumber"/> </operation> <operation name="decimalToRoman"> name="decimalToRoma <input message="decimalNumber"/> <output message="romanNumber"/> </operation> </portType>
Seccin de binding para el anterior archivo WSDL

<binding type="romanNumbers" name="rn"> <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/ transport="http://schemas.xmlsoap.org/soa http" /> <operation> <soap:operation soapAction="http://ejemplos.com/ejer"/> soapAction="http:// <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> <operation> <soap:operation soapAction="http://ejemplos.com/ejer tion="http://ejemplos.com/ejer"/> <input> <soap:body use="literal"/> </input> <output> <soap:body use="literal"/> </output> </operation> </binding>
Ver Video: DiseandoWS, en el Mdulo 8 Unidad 2, en la plataforma elearnig Laboratorio: Buenas prcticas para desarrollar servicios web SOAP.
Objetivo
Desarrollar un proyecto Web Service y consumirlo desde un proyecto Java Application.
Enunciado
Realizar un Servicio Web cuya funcionalidad ser convertir Monedas. Podremos convertir entre diversas monedas a euros y viceversa, de euros a monedas. Las Monedas que vamos a convertir son: DOLAR = 1,26201 Euros PESOS = 14,4762 Euros RUPIAS = 75,6061 Euros YENES = 135,861 Euros PESETAS = 166,386 Euros
CREACIN SERVICIO WEB MONEDAS:

Crear dos mtodos en el servicio web como se muestra en la imagen: imag
Unidad 3: Manejando Excepciones en los Servicios Web

Objetivos
x x x Manejar excepciones en servicios web. Conocer las excepciones relacionada con los servicios web. Utilizar clases de excepciones predefinidas en servicios web.
Introduccin
Una excepcin es una condicin que interrumpe el flujo normal de operaciones dentro de un programa. Imagina una excepcin como una condicin de error, un error de programacin inesperado, como una divisin entre cero o un posible error que ocurra en tiempo de ejecucin, como un "disco completo" mientras escribe un archivo. Cuando ocurre una excepcin, el flujo normal de instrucciones se rompe. En concreto, se lanza la excepcin y el flujo continua en el punto en el que se captur la excepcin. Al arrojarse la excepcin se permite la eliminacin del cdigo controlador de excepciones del flujo regular de operaciones. Si la condicin anormal no se controla adecuadamente, pueden aparecer resultados incorrectos u otras condiciones anormales.
La diferencia entre un buen desarrollo de software y un mal desarrollo desoftware es e a menudo la forma en que los errores y problemas se manejan. Es mucho ms fcil tratar con los procesos en que todo est funcionando adecuadamente de lo que es lidiar con los fracasos. Los lenguajes de programacin estructurados y orientado a objetos proporcionan un montn de tcnicas para el manejo de errores. En Java, los mtodos que suelen producir una excepcin que indica que algo raro ha ocurrido. Un buen software se escribe para esperar r ciertos tipos de errores, y est dispuesta a tomar las medidas oportunas. En la terminologa de SOAP, estos inusuales o circunstancias excepcionales, se llaman fallos. Los fallos se producen cada vez que un mtodo de servicio no es capaz de procesar los parmetros de entrada y devuelven resultados correctamente. Hay infinitas razones por qu esto puede ocurrir. Los problemas comunes que resultan en fallos son el paso de parmetro parmetros a los mtodos, problemas de fondo, y con formato incorrecto mensajes de peticin pet SOAP. En esta unidad veremos los mecanismos para la generacin y el tratamiento de fallos en SOAP. SOAP
Tipos de excepciones con servicios web

Las excepciones podran ser lanzadas lanzad s dentro de un servicio Web por diversas razones. Los posibles tipos de excepciones epciones que puedan ser lanzados son RuntimeException, RemoteException, SOAPFaultException y excepciones definidas por el usuario. El desarrollador de servicios Web podran intentar lanzar una RuntimeException como NullPointerException o ArrayIndexOutOfBoundsException ArrayIndexOutOfBoundsException dentro del servicio Web. Pero, RuntimeException lanzar dentro del servicio Web se considera un ejercicio malo porque RuntimeException siempre se convertir en RemoteException en el lado del cliente. Mientras que el cliente est esperando a coger oger el RuntimeException despus de invocar un servicio Web, recibir slo el RemoteException en lugar de RuntimeException. Finalmente, no puede realizar un correcto manejo de RuntimeException. El problema con el lanzamiento de RemoteException es que las bibliotecas de cliente secundarios diferentes a interpretar esta excepcin en formas diferentes. No es porttil.
SOAPFaultException
La excepcin SOAPFaultException representa lo errores producidos por SOAP 1.1 o 1.2. Un SOAPFaultException envuelve un SAAJ SOAPFault que administra la representacin SOAP especfica de errores.El mtodo createFault de javax.xml.soap.SOAPFactory puede utilizarse para crear una instancia de javax.xml.soap.SOAPFault para uso con el constructor. SOAPBinding contiene un descriptor descr de acceso para los SOAPFactory utilizado por la instancia de enlace. Tenga en cuenta que el valor de getFault es la nica parte de la excepcin que se utiliza cuando se searializa un error de SOAP. La excepcin que proceda la aplicacin de servicio Web podra lanzar es SOAPFaultException. El SOAPFaultException consta de cuatro partes: faultcode, faultstring, el actor, y el detalle. Esta excepcin le puede dar la informacin completa acerca de la condicin condicin de error. El faultcode le puede decir si el error que ha sucedido a causa de el servidor, cliente, o algo ms. Por ejemplo, cuando un cliente no proporciona la informacin de seguridad, tales como nombre de usuario y contrasea en el HTTP / encabezado ezado SOAP, pero los mandatos servicio de ellos, la lgica de tratamiento previo en la implementacin del servicio, obviamente, podra desencadenarse una excepcin de autenticacin. Este tipo de error es considerado como un error del cliente. El faultstring faultstring contiene la descripcin correspondiente de la condicin de error que ha sucedido. Este mensaje de cadena es legible por humanos y el desarrollador puede depurar el problema con la ayuda de la misma. El elemento de detalle contiene el mensaje de excepcin excepcin real y su completo seguimiento de la pila. En realidad, el
elemento de detalle es una instancia de la clase javax.xml.soap.Detail y se pueden crear utilizando el API javax.xml.soap.SOAPFactory.createDetail ().
Ejemplo de control de Excepcin SOAPFaultException Creacin del servicio

Abrir NetBeans y elegir un proyecto nuevo de tipo aplicacin web.
Seleccionamos usar el proyecto con Apache Tomcat
Y por ltimo, no seleccinamos nngn Framework.
Agregamos a nuestro proyecto un archivo de tipo Web Service. Botn derecho sobre nuestro proyecto WSSumando y elegimos File, new y Web Service.
Indicamos que lo guarde en el paquete ControlExcepciones.
Aadimos tres operaciones al servicio como se muestra en el diseadore de WebService:
El cdigo que incluiremos en los tres mtodos que compone nuestro WebService, sern operaciones para sumar, restar y multiuplicar dos nmeros introducidos como parmetros.
package ControlExcepciones; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService; @WebService() public class WSSumador { @WebMethod(operationName = "sumar", action = "sumar") public int sumar(@WebParam(name="a") int a, @WebParam(name="b") int b) { return a + b; } @WebMethod(operationName = "restar", action = "restar") public int restar(@WebParam(name="a") int a, @WebParam(name="b") int b) { return a - b; }
@WebMethod (operationName = "multiplicar") public c int multiplicar (@WebParam(name="x") int a, @WebParam(name="b") int b) { return a * b; } }
Consumir el servicio
Creamos un proyecto web con NetBeans y los llamamos ConsumirWsSumador.
Seleccionamos el servidor Apache Tomcat.
Dejamos sin seleccionar Framework.
Aadiremos a nuestro proyecto web un archivo de tipo Web Service Client, nos pedir el Web Sevrvice al que nos queremos conectar; pulsaremos sobre la opcin proyect, examinaremos y seleccionaremos el Web Service WSSumador.
El archivo WSDL que generar: <?xml version='1.0' encoding='UTF-8'?><! 8'?><definitions ><definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis-200401xmlns:wsu="http://docs.oasis -wss-wssecurity-utility1.0.xsd" xmlns:wsp_ ="http://www.w3.org/ns/ws-policy" policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/po _ xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" _ xmlns:tns="http://ControlExcepciones/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" _ xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://ControlExcepciones/" targetNamespace="http://ControlExcepciones/" _ name="WSSumadorService"> <types> <xsd:schema> <xsd:import namespace="http://ControlExcepciones/" schemaLocation="http://localhost:8084/WSSumador/WSSumador?xsd=1" /> </xsd:schema> </types> <message name="sumar"> <part name="parameters" ame="parameters" element="tns:sumar" /> </message> <message name="sumarResponse"> <part name="parameters" element="tns:sumarResponse" /> </message> <message name="restar"> <part name="parameters" element="tns:restar" /> </message> <message name="restarResponse"> <part name="parameters" element="tns:restarResponse" /> </message> <message name="multiplicar"> <part name="parameters" element="tns:multiplicar" />
</message> <message name="multiplicarResponse"> <part name="parameters" element="tns:multiplicarResponse" element="tns /> </message> <portType name="WSSumador"> <operation name="sumar"> <input wsam:Action="sumar" message="tns:sumar" /> <output wsam:Action="http://ControlExcepciones/WSSumador/sumarResponse" message="tns:sumarResponse" /> </operation> <operation name="restar"> <input wsam:Action="restar" message="tns:restar" /> <output wsam:Action="http://ControlExcepciones/WSSumador/restarResponse" message="tns:restarResponse" /> </operation> <operation name="multiplicar"> <input wsam:Action="http://ControlExcepciones/WSSumador/multiplicarRequest" trolExcepciones/WSSumador/multiplicarRequest" message="tns:multiplicar" /> <output wsam:Action="http://ControlExcepciones/WSSumador/multiplicarResponse" message="tns:multiplicarResponse" /> </operation> </portType> <binding name="WSSumadorPortBinding" type="tns:WSSumador"> type <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="sumar"> <soap:operation soapAction="sumar" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="restar"> <soap:operation soapAction="restar" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> <operation name="multiplicar"> <soap:operation soapAction="" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <service name="WSSumadorService">
<port name="WSSumadorPort" binding="tns:WSSumadorPortBinding"> <soap:address location="http://localhost:8084/WSSumador/WSSumador" /> </port> </service> </definitions>
Agregaremos una pgina html a nuestro proyecto para que el usuarko introduzca en dos cajas de texto los parmetros a pasar a los mtodos del WebService.
<!DOCTYPE HTML PUBLIC "-//W3C//DTD //W3C//DTD HTML 4.01 Transitional//EN"> <html> <head> <title></title> <meta http-equiv="Content-Type" Type" content="text/html; charset=UTF-8"> charset=UTF </head> <body> <h1>Control de excepciones en WebServices</h1> <form name="form1" form1" action="resultado.jsp"> <input type="text" name="caja1" size="3"/>+ <input type="text" name="caja2" size="3"/>= <input type="submit" value="Enviar"/> </form> </body> Al pulsar sobre el botn de submit, llamaremos una pgina jsp que ser la encargada de recoger los valores introducidos en las dos cajas de texto y consumir el mtodo sumar de nuestro Web Service. Al solicitar el Web Service, comprobaremos como estamos controlando la excepcin SOAPFaultException, , sta exception se puede producir habitualmente en el consumo de servicios web si se produce un error al intentar autenticarnos, realizar solicitudes,
<%@page contentType="text/html" pageEncoding="UTF-8" pageEncoding="UTF import="javax.xml.rpc.soap.SOAPFaultException"%> <!DOCTYPE HTML PUBLIC "-//W3C//DTD //W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <meta http-equiv="Content-Type" Type" content="text/html; charset=UTF-8"> charset=UTF <title>JSP Page</title> </head> <body> <h1>RESULTADO: </h1> <% try{ int a = Integer.parseInt(request.getParameter("caja1")); int b = Integer.parseInt(request.getParameter("caja2")); controlexcepciones.WSSumadorService trolexcepciones.WSSumadorService service = new controlexcepciones.WSSumadorService(); controlexcepciones.WSSumador port = service.getWSSumadorPort(); out.println(port.sumar(a, b)); } catch (SOAPFaultException se) { out.println("Fallo de autenticacin"); out.println(""); out.println(se); } %> </body> </html>
Excepciones predefinidas en servicios web

Aunque SOAPFaultException da la informacin necesaria que se necesita para depurar el problema, el cliente de servicio Web puede que quiera realizar algo ms con el error que se ha producido. La opcin que disponemos es tener tener una descripcin de texto configurables y dinmica del error que se produjo. La otra posibilidad podra ser la de contar con el apoyo de internacionalizacin de los mensajes de error. Al proporcionar la descripcin de texto en idiomas distintos del Ingls, se podra tratar de responder sponder a las necesidades de todos los grupos de personas. La lista puede crecer ms y ms. Para lograr los objetivos podramos recurrir a una excepcin definida por el usuario con un formato especfico que fuera lanzado en el servicio. La excepcin definida definida por el usuario lanzado dentro del servicio Web est mapeada en el elemento wsdl: fallo en el Web Services Description Language (WSDL) del servicio web. Se poda ver el elemento de culpa como uno de los elementos secundarios del elemento de operacin de la portType. Los otros dos elementos secundarios de la operacin son de entrada y salida. El elemento fault, define el formato de resumen del mensaje de error que pueden ser lanzados por el servicio Web. El elemento wsdl:messages relativos a WSDL:fault WSDL:fault slo puede contener una parte del mensaje, y la parte del mensaje podra ser un XMLType complexType o simple. En el siguiente ejemplo incluimos una excepcin definida por el usuario, MyCustomException, se dedicar a manejar mejor los mensajes de error. El MyCustomException contiene un mensaje de error apropiado que es como se define en la definicin WSDL. El mensaje de error contiene las tres partes siguientes: Cdigo de error, que contiene una de cinco letras identificativo y un identificador de tres dgitos Por ejemplo, GENEX001 podra significar un error genrico, mientras que AUTEX001 podra significar un error de autenticacin. Texto descriptivo del error, incluyendo variables de sustitucin (mencionado como {0}, {1}, y as sucesivamente) Por ejemplo, la descripcin de texto correspondiente Cdigo de error GENEX001 ser algo as como "El nmero que ha introducido es {0}." Una lista de valores correspondientes a las variables de sustitucin se define en el texto anterior. Por ejemplo, para el caso anterior, la lista de variables que contienen un solo valor (por ejemplo 1) porque la descripcin del texto anterior contiene slo una variable de sustitucin. Despus de procesar el texto usando la lgica pertinentes, la descripcin del texto final fina sera "El nmero que ha introducido es 1." Los fallos pueden ser identificados, utilizando el cdigo de error, sin necesidad de aplicaciones, y adems se podr comprender el independientemente del idioma. La descripcin del texto se puede definir en muchos muchos idiomas, y las variables correspondientes se pueden colocar en consecuencia de manera independiente del lenguaje. Los servicios web ofrecen soporte de internacionalizacin. Las excepciones lanzadas deben usar la anotacin javax.xml.ws.WebFault name: nombre en wsdl. targetNamespace. Espacio de nombres en wsdl. Por la forma en la que JAX-WS WS define el mapping de Exceptions java a WSDL y viceversa, es conveniente que las Excepciones utilizadas cumplan las siguientes reglas:
La informacin encapsulada en la Excepcin debe ir en un objeto separado. Este objeto debe ser obtenido a travs del mtodo getFaultInfo. De esta forma, las excepciones lanzadas por los stubs del cliente sern iguales que las usadas en el servicio.
Ejemplo de servicio web con manejo de excepciones

Este servicio tiene dos entradas: int numero y el mensaje de cadena. Si el nmero es 1,se lanzar un SOAPFaultException. Si el nmero es 2, MyCustomException ser lanzado, de lo contrario, el mtodo devolver xito. package nuevo; import javax.xml.soap.SOAPException; import javax.xml.soap.SOAPFactory; import javax.xml.soap.Detail; public class NewWebService{ public String echo(int number, String message) throws MyCustomException{ System.out.println("Numero: "+number+", Mensaje: " + message); switch(number){ case 2: throw new MyCustomException( "GENEX001", "El nmero que ha introducido es {0}", new String[]{String.valueOf(number)} ); case 1: Detail detail = null; try{ detail = SOAPFactory.newInstance().createDetail(); //aadir mensajes de error detail.addTextNode( "Opcin SOAPFaultException"); }catch(SOAPException ex){ throw new MyCustomException( "SEREX001", "Error al crear el elemento", new String(){}); } throw new javax.xml.rpc.soap.SOAPFaultException( new javax.xml.namespace.QName("env.Server"), "El nmero que ha introducido es "+number, "NO ACTOR", detail); } return "SUCCESS"; } }
Excepciones cepciones personalizadas en Servicios Web

En Java podemos crear una excepcin propia creanco una clase que extienda de la clase Exception. En este ejemplo creamos una exception llama OpcionErroneaException que hereda de la clase exception. public class OpcionErroneaException ionErroneaException extends Exception{ public OpcionErroneaException(){ } public String mensaje(){ return("OPCION ERRONEA"); } }
Podemos crear una clase en Java que lance la excepcin creada por el programador. public class LeerDatos3{ public static void main(String args[]) throws IOException{ BufferedReader teclado=new BufferedReader(new InputStreamReader(System.in)); String numero=""; String continua=""; try{ do{ System.out.println("Introduzca un numero:"); numero=teclado.readLine(); int num=Integer.parseInt(numero); if (num%2==0){ System.out.println("El numero: "+ num +" es par"); }else{ System.out.println("El numero: "+ num +" es impar"); }
System.out.println("Desea rintln("Desea continuar (s/n)?"); continua= teclado.readLine(); if(!continua.equals("s") && !continua.equals("n")){ throw new OpcionErroneaException(); } }while (continua.equals("s") || continua.equals("S")); //Para compara se pone .equals }catch (NumberFormatException e){ System.out.println("Debe introducir numeros"); }catch (OpcionErroneaException e){
System.out.println(e.mensaje()); teclado.readLine(); }
} } Dentro de los Web Service tambin podemos hacer uso de la creacin de excepciones propias.
Podramos crear una excepcin propia con un esqueleto como el que mostramos a continuacin:
public class ErrorWebService extends Exception { public ErrorWebService (String code) { } public String getA() {...} public void setA() {..} public String getB() {...} public void setB() {..} }
Podemos lanzarlo desde el Web Service como en el siguiente ejemplo:
@WebService public class MyWS { public MyWS() { } public Response getSomething(String id) throws ErrorWebService { throw new ErrorWebService (id); } }
Ver Video: Excepciones WebServices, en el Mdulo 8. Unidad 3, en la plataforma elearning
Laboratorio: Excepciones WebServices

Objetivos
x x Crear un proyecto Java Application que nos permita consumir el Web Service del Catastro. Controlaremos las posibles excepciones que se produzcan al consumir el servicio.
Enunciado:
Abrir un proyecto Java Application para poder consumir el servicio web del catastro ubicado en la siguiente direccin: https://ovc.catastro.meh.es/ovcservweb/OVCSWLocalizacionRC/OVCCallejero.asmx?WSDL
1.
Crear un proyecto Java Application y llamarlo ConsumirServicioWebCatastro.
2.
Agregar un nuevo elemento de tipo Web Service Client.
3.
Aadir la direccin al servicio web del catastro.
4.
Incluir la llamada a los mtodos del servicio.
5.
Selecccionar el mtodo ObtenerProvincias que es el que quere mos invocar.
6. Llamar al mtodo obtenerProvincias que nos genera desde el main. package consumirserviciowebcatastro;
public class Principal { /** * @param args the command line arguments */ public static void main(String[] args) { Provincias p=obtenerProvincias(); } private static Provincias obtenerProvincias() enerProvincias() { consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Catas tro service = new_ consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Catas tro(); consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Catas troSoap port =_ service.getCallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020CatastroSoap12(); return port.obtenerProvincias(); } } 7. Si el servicio web est cado obtendremos el siguiente error.
8. Controlaremos el error para avisar al usuario. package consumirserviciowebcatastro;
public class Principal { /** * @param args the command line arguments */ public static atic void main(String[] args) { try{ Provincias p=obtenerProvincias(); }catch(javax.xml.ws.WebServiceException e){ System.out.println("Web Service detenido");
} } private static Provincias obtenerProvincias() { consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Catas tro service = new _ consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Cata consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Catas tro(); consumirserviciowebcatastro.CallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020Catas troSoap port = _ service.getCallejeroX0020DeX0020LaX0020SedeX0020ElectrnicaX0020DelX0020CatastroSoap12(); return port.obtenerProvincias(); ; } }
Unidad 4: Seguridad en los Servicios Web

Objetivos
x x Describir requerimientos y soluciones en seguridad de servicios web. Entender los tipos de protecciones de un servicio web.
Introduccin
Hoy en da, considerar la tecnologa de web services sin considerar los aspectos de seguridad es algo inconcebible, sobre todo si se trata de comunicacin de informacin referida a lgica de negocios, donde la informacin debe ser confiable y segura. A su vez, varios aspectos surgidos desde el mismo momento de la concepcin de la tecnologa de web services deben ser mantenidos al momento de la incorporacin de algn mecanismo de seguridad, como ser por ejemplo de su sencillez y de la interoperabilidad entre plataformas y fabricantes. Con esto en mente surge WS-*. *. Parte importante de este conjunto de especificaciones est directamente vinculada a la seguridad en web services, siendo WS-Security WS Security quiz la piedra fundamental de las dems, ya que las dems especificaciones o bien complementan o bien extienden extien los mecanismos definidos en WS-Security. Security.
WS-Security
WS-Security Security define extensiones a SOAP que permiten el pasaje de security tokens los cuales identifican y autentifican a los clientes de los servicios. De esta forma se puede asegurar la integridad de d los mensajes y la confidencialidad de los mismos; entendiendo como integridad al hecho de que los mensajes enviados se mantengan inalterados durante la transmisin, y como confidencialidad al hecho de que ningn agente externo a la comunicacin pueda obtener obtener de ninguna forma el contenido del mensaje (problema conocido como man-in in-the-middle). WS-Security Security define y estandariza la forma de uso de mecanismos de seguridad ya existentes, adaptndolos a su funcionamiento con los mensajes SOAP. Quizs lo ms fundamental fundamental que define WSWS Security es el elemento que se embebe en el encabezado del mensaje SOAP. La estructura de un mensaje SOAP que incluye este elemento se muestra en el ejemplo 1, a continuacin: <?xml version="1.0" encoding="utf-8"?> 8"?> <s:Envelope xmlns:s="http://schemas.xmlsoap.org/soap/envelope/" xmlns:wsse="http://schemas.xmlsoap.org/ws/2002/12/secext"> <s:Header> <wsse:Security> </wsse:Security> </s:Header> <s:Body> </s:Body> </s:Envelope> La especificacin define asimismo como enviar security tokens, ya sea un username token, un certificado X.509 o un ticket Kerberos, por nombrar los ms conocidos y utilizados actualmente.
El principal problema que enfrenta el receptor de un mensaje es saber quien es exactamente el que le est realizando realizan el pedido. Existen varias formas de verificar la identidad del cliente: con un username token, se debe proveer una pareja usuario/contrasea correcta; un ticket kerberos est encriptado, y el receptor del mensaje puede verificar que es correcto. WS-Security rity es extremadamente flexible en el hecho de no definir que tipo de security tokens utilizar; sin embargo no lo es en lo siguiente: dos sistemas pueden conformar WS-Security, WS Security, pero igualmente ser incapaces de comunicarse entre s. Un sistema por ejemplo podra podra llegar a aceptar solamente tickets Kerberos, mientras que el otro aceptar solamente certificados X.509, por ejemplo, por lo que solamente WS-Security Security no alcanza. Este tipo de problemas son los que intentan atacar WS-SecurityPolicy WS SecurityPolicy y WS-Trust. WS
WS-SecurityPolicy
Siempre que se utilicen mecanismos de seguridad, en cualquier mbito, debe existir algn tipo de polticas de seguridad; una cosa va de la mano con la otra. Estas polticas clarifican los requisitos de seguridad especficos en una situacin particular. particular. Supongamos por ejemplo un servicio web utilizando WS-Security, se deben definir claramente ciertos aspectos con el fin de que un cliente pueda comunicarse efectivamente con el servicio. Aspectos como: que tipo de security tokens acepta, que algoritmo tmo de encriptacin se utiliz para encriptar el mensaje, etc., deben estar claramente definidos por el servicio. Para definir estos aspectos es que se utilizan las polticas. La especificacin WS-Policy Policy define una aproximacin general para la especificacin especificac de todo tipo de polticas para los servicios web. Basndose en esto, WS-SecurityPolicy WS SecurityPolicy define una sintaxis XML para especificar polticas relacionadas con la seguridad. Esta sintaxis define elementos denominados assertions; que permiten a un servicio web web especificar sus polticas en una forma no ambigua. Las assertions definidas por WS-SecurityPolicy SecurityPolicy incluyen las siguientes:
Permiten a un web service especificar que tipos de security tokens aceptar, y, opcionalmente, de quien permitir que procedan.
Permite ermite a un web service especificar varias opciones sobre las firmas digitales que aceptar.
Permite ermite a un web service especificar opciones sobre como la encriptacin se realizar, como por ejemplo que algoritmo de encriptacin se utilizar.
Permite a un web service especificar que ciertas partes de un mensaje no deben estar encriptadas, y cuales son esas partes.
La forma exacta de cmo las polticas son transportadas desde el servicio al cliente interesado no se define en WS-SecurityPolicy. Las assertions pueden ser enviadas en un mensaje SOAP o entregado de cualquier otra forma. WS-Policy Policy define un elemento general, , que puede contener una o ms assertions para las polticas. El elemento puede contener polticas sobre security tokens, integridad, integri
confidencialidad y otras cosas. A continuacin se pasa a detallar la especificacin de WS-Trust, WS Trust, objetivo principal del presente documento.
WS-TRUST
Security define las bases para proveer seguridad al intercambio de mensajes SOAP. WS-Security WS-Trust utiliza estas bases o mecanismos y define primitivas adicionales y extensiones para el intercambio de security tokens para permitir la obtencin y diseminacin de credenciales entre distintos dominios de confianza. Para asegurar la comunicacin entre dos partes, las mismas deben intercambiar credenciales de seguridad, ya sea directa como indirectamente. Para que el intercambio funcione correctamente, cada una de las partes debe poder determinar si pueden confiar en las credenciales de la otra parte. El objetivo principal de WS-Trust Trust es habilitar a las distintas aplicaciones a construir intercambios confiables de mensajes. La confianza es representada a travs del intercambio e intermediacin de security tokens. La especificacin provee una forma para solicitar, renovar renovar y validar estos security tokens. WS-Security, WS-SecurityPolicy y WS-Trust Trust son los cimientos fundamentales para el modelo de Federacin de servicios, definido en WS-Federation, Federation, que queda fuera del alcance de este documento.
Web Services Trust Model

El modelo de seguridad en web services definido en WS-Trust WS Trust est basado en un proceso en el cual un servicio puede requerir que todo pedido que se le haga cumpla con un conjunto de claims. Si el pedido viene sin los claims requeridos, se debe rechazar o ignorar ignorar el mismo. La manera que tiene un servicio de indicar cuales son los claims requeridos es mediante polticas de seguridad definidas sobre el propio servicio. Si el cliente no tiene el(los) token(s) necesarios para cumplir los requisitos de seguridad indicado por el servicio en sus polticas, el mismo puede contactar a las autoridades apropiadas y solicitar los tokens necesarios. Estas autoridades se indican en la poltica del servicio, y son llamadas Security Token Services(STS). n definidas sus propias polticas de seguridad, y el cliente debe cumplirlas para Los STS a su vez tienen realizar el pedido de security tokens. La figura que se muestra a continuacin muestra que cualquier servicio puede ser un cliente, y a su vez que el STS es un Web Service. Las as flechas muestran posibles vas de comunicacin; el cliente (requestor) puede obtener un token del STS o puede haberlo obtenido por otro medio.
Se tiene un servicio web, el cual tiene definida ciertas polticas de seguridad. Dichas polticas establecen que para realizar un pedido al servicio, es necesario que en el pedido haya un security token, pero que adems este token est firmado por un STS determinado, con el cul el servicio tiene una relacin de confianza previamente establecida de alguna forma. El cliente debe solicitar al STS indicado el o los security tokens indicados en la poltica del servicio. Para esto, el cliente debe enviar las claims apropiadas al STS, el cual define cuales son en su propia poltica de seguridad. El STS verifica que los claims sean validos, y de as serlo, enva el token solicitado en mensaje de respuesta. Finalmente, el cliente enva el pedido al servicio, con el token recibido (firmado por el STS). Como el servicio confa en el STS, valida el pedido del cliente.
Relaciones de confianza
Existen varios mecanismos que pueden ser utilizados para verificar las relaciones de confianza de un servicio. Estos mecanismos no son obligatorios y no son requeridos por WS-Trust. WS Trust. O sea, los servicios son libres de verificar las relaciones nes de confianza y de establecer las mismas sobre un dominio o extender las mismas hacia otros dominios mediante cualquier mecanismo. WS-Trust Trust define los siguientes mecanismos: Fixed Trust Roots: El ms simple de todos. El servicio (ms especficamente la trust engine del servicio) contiene una lista de todas sus relaciones de confianza. Si los tokens vienen de un servicio perteneciente a esta lista, el servicio los utiliza. Trust Hierarchies: El servicio confiar en los tokens siempre y cuando provengan de una jerarqua de confianza que lleve a un trusted root. Authentication Service: Este es un servicio especial con el cual el servicio mantiene una relacin de confianza. Cuando el servicio recibe un token, lo enva directamente a este servicio, que es el que va a decidir si es de confianza o no.
Security Token Service

A continuacin se explica el funcionamiento de los STS en un escenario WS-Trust. WS Trust. Un cliente realiza un pedido de un security token al STS; si la poltica y los requerimientos del STS se cumplen, mplen, el cliente recibe un security token response. Este proceso utiliza los siguientes dos elementos: para solicitar al STS un security token y para la respuesta del STS al cliente.
El elemento (RST) debe estar firmado por el que realiza el pedido, utilizando tokens contenidos o referenciados en el propio pedido. La sintaxis del elemento se muestra en el siguiente ejemplo: <wst:RequestSecurityToken Context="..."> <wst:TokenType> ... </wst:TokenType> <wst:RequestType> ... </wst:RequestType> ... </wst:RequestSecurityToken> Como ya se dijo, el elemento es utilizado para
enviar una respuesta a un pedido de un security token. En general, el token retornado por el STS al cliente que realiz el pedido, pedido, no ser modificado de ninguna forma por el cliente. Si puede llegar a ser incluida otra informacin respecto al security token, como ser el tiempo de vida, etc.. La sintaxis de este elemento se muestra a continuacin: <wst:RequestSecurityTokenResponse Context="..."> C <wst:TokenType> ... </wst:TokenType> <wst:RequestedSecurityToken> ... </wst:RequestedSecurityToken> ... </wst:RequestSecurityTokenResponse>
Tcnicas criptogrficas y las firmas digitales

Firmas digitales DSA y DSS
El DSA (Digital Signature Algorithm o Algoritmo Estndar de Firmado) es el algoritmo de firmado digital incluido en el DSS (Digital Signature Standard o Estndar de Firmas Digitales) del NIST Norteamericano. Se public en 1994. El DSA est basado en el problema de los logaritmos discretos discretos y slo puede emplearse para las firmas digitales (a diferencia del RSA, que tambin puede emplearse para encriptar). La eleccin de este algoritmo como estndar de firmado gener multitud de crticas: se pierde flexibilidad respecto al RSA (que adems, ya era un estndar de hecho), la verificacin de firmas es lenta, el proceso de eleccin fue poco claro y la versin original empleaba claves que lo hacan poco seguro. El algoritmo es ms rpido para generar la firma que para validarla, al revs de lo que sucede con el RSA. Emplea claves de 1024 bits (originalmente eran 512 bits, pero se aumento por falta de seguridad). No se conocen ataques eficientes contra este algoritmo, slo existen problemas con un conjunto de nmeros primos, pero son fcilmente fcilmente evitables si se siguen los sistemas adecuados de generacin de claves.
Certificados digitales
Los certificados digitales son el equivalente digital del DNI, en lo que a la autentificacin de individuos se refiere, ya que permiten que un individuo demuestre demuestre que es quien dice ser, es decir, que est en posesin de la clave secreta asociada a su certificado. Para los usuarios proporcionan un mecanismo para verificar la autenticidad de programas y documentos obtenidos a travs de la red, el envo de correo encriptado y/o firmado digitalmente, el control de acceso a recursos, etc. En este apartado explicaremos qu son los certificados digitales, cuales son los formatos estndar, como podemos controlar sus periodos de validez o anularlos si se ven comprometidos, comprometidos, quien los genera y las infraestructuras necesarias para soportarlos. Un certificado de clave pblica es un punto de unin entre la clave pblica de una entidad y uno o ms atributos referidos a su identidad. El certificado garantiza que la clave pblica pbli pertenece a la entidad identificada y que la entidad posee la correspondiente clave privada.
Los certificados de clave pblica se denominan comnmente Certificado Digital, ID Digital o simplemente certificado. La entidad identificada se denomina sujeto del certificado o subscriptor (si es una entidad legal como, por ejemplo, una persona). Los certificados digitales slo son tiles si existe alguna Autoridad Certificadora (Certification Authority o CA) que los valide, ya que si uno se certifica a s mismo mismo no hay ninguna garanta de que su identidad sea la que anuncia, y por lo tanto, no debe ser aceptada por un tercero que no lo conozca. Es importante ser capaz de verificar que una autoridad certificadora ha emitido un certificado y detectar si un certificado ficado no es vlido. Para evitar la falsificacin de certificados, la entidad certificadora despus de autentificar la identidad de un sujeto, firma el certificado digitalmente. Los certificados digitales proporcionan un mecanismo criptogrfico para implementar implementar la autentificacin; tambin proporcionan un mecanismo seguro y escalable para distribuir claves pblicas en comunidades grandes.
Certificados X.509
El formato de certificados X.509 es un estndar del ITU-T ITU T (International Telecommunication UnionUnion Telecommunication ecommunication Standarization Sector) y el ISO/IEC (International Standards Organization / International Electrotechnical Commission) que se public por primera vez en 1988. El formato de la versin 1 fue extendido en 1993 para incluir dos nuevos campos que que permiten soportar el control de acceso a directorios. Despus de emplear el X.509 v2 para intentar desarrollar un estndar de correo electrnico seguro, el formato fue revisado para permitir la extensin con campos adicionales, dando lugar al X.509 v3, publicado ublicado en 1996. Los elementos del formato de un certificado X.509 v3 son: Versin. El campo de versin contiene el nmero de versin del certificado codificado. Los valores aceptables son 1, 2 y 3. Nmero de serie del certificado. Este campo es un entero entero asignado por la autoridad certificadora. Cada certificado emitido por una CA debe tener un nmero de serie nico. Identificador del algoritmo de firmado. Este campo identifica el algoritmo empleado para firmar el certificado (como por ejemplo el RSA o el DSA). Nombre del emisor. Este campo identifica la CA que ha firmado y emitido el certificado. Periodo de validez. Este campo indica el periodo de tiempo durante el cual el certificado es vlido y la CA est obligada a mantener informacin sobre el estado estado del mismo. El campo consiste en una fecha inicial, la fecha en la que el certificado empieza a ser vlido y la fecha despus de la cual el certificado deja de serlo. Nombre del sujeto. Este campo identifica la identidad cuya clave pblica est certificada certif en el campo siguiente. El nombre debe ser nico para cada entidad certificada por una CA dada, aunque puede emitir ms de un certificado con el mismo nombre si es para la misma entidad. Informacin de clave pblica del sujeto. Este campo contiene la clave pblica, sus parmetros y el identificador del algoritmo con el que se emplea la clave. Identificador nico del emisor. Este es un campo opcional que permite reutilizar nombres de emisor. Identificador nico del sujeto. Este es un campo opcional que que permite reutilizar nombres de sujeto. Extensiones. Las extensiones del X.509 v3 proporcionan una manera de asociar informacin adicional a sujetos, claves pblicas, etc. Un campo de extensin tiene tres partes: Tipo de extensin. Es un identificador de objeto que proporciona la semntica y el tipo de informacin (cadena de texto, fecha u otra estructura de datos) para un valor de extensin.
Valor de la extensin. Este subcampo contiene el valor actual del campo. Indicador de importancia. Es un flag que indica a una aplicacin si es seguro ignorar el campo de extensin si no reconoce el tipo. El indicador proporciona una manera de implementar aplicaciones que trabajan de modo seguro con certificados y evolucionan conforme se van aadiendo nuevas extensiones. El ITU y el ISO/IEC han desarrollado y publicado un conjunto de extensiones estndar en un apndice al X.509 v3: Limitaciones bsicas. Este campo indica si el sujeto del certificado es una CA y el mximo nivel de profundidad de un camino de certificacin a travs de esa CA. Poltica de certificacin. Este campo contiene las condiciones bajo las que la CA emiti el certificado y el propsito del certificado. pblica certificada, indicando, por Uso de la clave. Este campo restringe el propsito de la clave pblica ejemplo, que la clave slo se debe usar para firmar, para la encriptacin de claves, para la encriptacin de datos, etc. Este campo suele marcarse como importante, ya que la clave slo est certificada para un propsito y usarla arla para otro no estara validado en el certificado. El formato de certificados X.509 se especifica en un sistema de notacin denominado sintaxis abstracta uno (Abstract Sintax One o ASN-1). 1). Para la transmisin de los datos se aplica el DER (Distinguished (Distinguishe Encoding Rules o reglas de codificacin distinguible), que transforma el certificado en formato ASN-1 ASN en una secuencia de octetos apropiada para la transmisin en redes reales.
Listas de Anulacin de Certificados (CRLs)

Los certificados tienen un periodo o de validez que va de unos meses a unos pocos aos. Durante el tiempo que el certificado es vlido la entidad certificadora que lo gener mantiene informacin sobre el estado de ese certificado. La informacin ms importante que guarda es el estado de anulacin, que indica que el periodo de validez del certificado ha terminado antes de tiempo y el sistema que lo emplee no debe confiar en l. Las razones de anulacin de un certificado son varias: la clave privada del sujeto se ha visto comprometida, la clave ve privada de la CA se ha visto comprometida o se ha producido un cambio en la afiliacin del sujeto (por ejemplo cuando un empleado abandona una empresa). Las listas de anulacin de certificados (Certification Revocation Lists o CRL) son un mecanismo mediante med el cual la CA publica y distribuye informacin a cerca de los certificados anulados a las aplicaciones que los emplean. Una CRL es una estructura de datos firmada por la CA que contiene su fecha y hora de publicacin, el nombre de la entidad certificadora certificadora y los nmeros de serie de los certificados anulados que aun no han expirado. Cuando una aplicacin trabaja con certificados debe obtener la ltima CRL de la entidad que firma el certificado que est empleando y comprobar que su nmero de serie no est incluido en l. Existen varios mtodos para la actualizacin de CRLs: Muestreo de CRLs. Las aplicaciones acceden a la CA o a almacenes de archivos y copian el ltimo CRL a intervalos regulares. La pega de este esquema es que durante el periodo entre actualizaciones ac del CRL podemos aceptar un certificado ya anulado, por lo que el periodo debe ser corto. Anuncio de CRLs. La entidad certificadora anuncia que ha habido un cambio en el CRL a las aplicaciones. El problema de este enfoque es el anuncio puede ser muy costoso y no sabemos que aplicaciones deben ser informadas. Verificacin en lnea. Una aplicacin hace una consulta consulta en lnea a la CA para determinar el estado de revocacin de un certificado. Es el mejor mtodo para las aplicaciones, pero es muy costoso para la CA.
Listas de Anulacin de Certificados X.509

El formato de listas de anulacin de certificados X.509 es es un estndar del ITU-T ITU y la ISO/IEC que se public por primera vez en 1988 como versin 1. El formato fue modificado para incluir campos de extensin, dando origen al al formato X.509 v2 CRL. Los campos bsicos de un formato X.509 CRL (vlidos para las versiones versiones 1 y 2) son: Versin. Debe especificar la versin 2 si hay algn campo de extensin. Firma. El campo contiene identificador del algoritmo empleado para firmar la CRL. Nombre del generador. Este campo contiene el nombre de la entidad que ha generado gener y firmado la CRL. Esta actualizacin. Fecha y hora de la generacin de la CRL. Prxima actualizacin. Indica la fecha y hora de la prxima actualizacin. El siguiente CRL puede ser generado antes de la fecha indicada pero no despus de ella. Certificado del usuario. Contiene el nmero de serie de un certificado anulado. Fecha de anulacin. Indica la fecha efectiva de la anulacin. Existe tambin un conjunto de campos de entrada de extensin en las CRLs X.509 v2, como el cdigo de razn, que identifica la causa de la anulacin: sin especificar, compromiso de clave, compromiso de la CA, cambio de afiliacin, superado (el certificado ha sido reemplazado), cese de operacin (el certificado ya no sirve para su propsito original), certificado certificado en espera (el certificado est suspendido temporalmente) y elimina de la CRL (un certificado que apareca en una CRL previa debe ser eliminado). Adicionalmente tambin se ha aadido un conjunto de extensiones para las X.509v2 CRL con los mismos subcampos s que en los certificados X.509v3. Estas extensiones permiten que una comunidad o entidad se defina sus propios campos de extensin privados.
Autoridades Certificadoras
Una autoridad certificadora es una organizacin fiable que acepta solicitudes de certificados certi de entidades, las valida, genera certificados y mantiene la informacin de su estado. Una CA debe proporcionar una Declaracin de Prcticas de Certificacin (Certification Practice Statement o CPS) que indique claramente sus polticas y prcticas relativas a la seguridad y mantenimiento de los certificados, la responsabilidades de la CA respecto a los sistemas que emplean sus certificados y las obligaciones de los subscriptores respecto de la misma. Las labores de un CA son: Admisin de solicitudes. Un usuario rellena un formulario y lo enva a la CA solicitando un certificado. La generacin de las claves pblica y privada son responsabilidad del usuario o de un sistema asociado a la CA. Autentificacin del sujeto. Antes de firmar la informacin proporcionada por el sujeto la CA debe verificar su identidad. Dependiendo del nivel de seguridad deseado y el tipo de certificado se debern tomar las medidas oportunas para la validacin. Generacin de certificados. Despus de recibir una solicitud y validar validar los datos la CA genera el certificado correspondiente y lo firma con su clave privada. Posteriormente lo manda al subscriptor y, opcionalmente, lo enva a un almacn de certificados para su distribucin. Distribucin de certificados. La entidad certificadora certificadora puede proporcionar un servicio de distribucin de certificados para que las aplicaciones tengan acceso y puedan obtener los certificados de sus
subscriptores. Los mtodos de distribucin pueden ser: correo electrnico, servicios de directorio como com el X.500 o el LDAP, etc. Anulacin de certificados. Al igual que sucede con las solicitudes de certificados, la CA debe validar el origen y autenticidad de una solicitud de anulacin. La CA debe mantener informacin sobre una anulacin durante todo el tiempo iempo de validez del certificado original. Almacenes de datos. Hoy en da existe una nocin formal de almacn donde se guardan los certificados y la informacin de las anulaciones. La designacin oficial de una base de datos como almacn tiene por objeto sealar que el trabajo con los certificados es fiable y de confianza.
Infraestructuras de Clave Pblica

La difusin de las tcnicas de clave pblica requiere una infraestructura que defina un conjunto de estndares, autoridades de certificacin, estructuras estructuras entre mltiples CAs, mtodos para descubrir y validar rutas de certificacin, protocolos operacionales, protocolos de gestin, herramientas que pueden operar entre s y un marco legislativo. Los protocolos operacionales se dirigen al problema del envo de certificados y CRLs a los sistemas que emplean certificados. Los protocolos de gestin tratan de los requisitos para la interaccin de dos componentes de la infraestructura: registro, inicializacin, certificacin, anulacin y recuperacin de claves. Una na estructura entre mltiples CAs proporciona una o ms rutas de certificacin entre un subscriptor y una aplicacin. Una ruta de certificacin (o cadena de certificacin) es una secuencia de uno o ms puntos conectados entre el subscriptor y una CA raz. Una CA raz es una autoridad en la que confa la aplicacin, ya que tiene almacenada de forma segura su clave pblica. Un sistema que emplea certificados necesita obtener una ruta de certificacin entre un subscriptor y un CA raz antes de evaluar el nivel nivel de confianza en el certificado del subscriptor. El problema de determinar una ruta de certificacin entre dos subscriptores arbitrarios en una estructura de interconexiones entre diferentes CAs se denomina descubrimiento de rutas de certificacin. El problema de verificar la asociacin entre el nombre del subscriptor y su clave pblica en una ruta de certificacin se denomina validacin de la ruta de certificacin.
Implementar la seguridad en los servicios web

En la siguiente unidad veremos la forma que tenemos de implementar seguridad en un proyecto creado con el IDE NetBeans. Abrir un proyecto de tipo Java Web, Web Application.
Llamaremos al proyecto WS_Seguridad.
Seleccionamos como servidor GlassFish.
No seleccionaremos ningn Framework, y por ltimo le daremos a finalizar.
Aadiremos a nuestro proyecto web un archivo de tipo Web Service.
En la caja de texto para introducir el nombre del servicio introduciremos ServicioSeguridad. Guardar el servicio en el paquete Servicios.
Aadimos una na nueva operacin para crear un mtodo llamado mensaje, devolver un string con un nombre.
Veremos el cdigo que generado, e introducimos un string con el nombre que devolver el mtodo.
package Servicios; import javax.jws.WebMethod; import javax.jws.WebParam; import javax.jws.WebService;
@WebService() public class ServicioSeguridad {
@WebMethod(operationName = "mensaje") public String mensaje(@WebParam(name = "nombre") String nombre) { return "Hola: "+ nombre; } } Anotaciones creadas: @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 s 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.
Probaremos el servicio antes de implementar seguridad. Sobre la carpeta Web Services, seleccionaremos la opcin Test Web Service.
Cuando comprobemos que el servicio web desplega bien, comenzaremos con la implementacin de seguridad.
WSDL generado. <?xml version='1.0' encoding='UTF-8'?><! 8'?><definitions xmlns:wsu="http://docs.oasis-open.org/wss/2004/01/oasis xmlns:wsu="http://docs.oasis open.org/wss/2004/01/oasis-200401-wsswssecurity-utility-1.0.xsd" _
xmlns:wsp="http://www.w3.org/ns/ws-policy" xmlns:wsp="http://www.w3.org/ns/ws xmlns:wsp1_2="http://schemas.xmlsoap.org/ws/2004/09/policy" _ xmlns:wsam="http://www.w3.org/2007/05/addressing/metad xmlns:wsam="http://www.w3.org/2007/05/addressing/metadata" xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/" xmlns:tns="http://Servicios/" _ xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns="http://schemas.xmlsoap.org/wsdl/" targetNamespace="http://Servicios/" _ name="ServicioSeguridadService"> <types> <xsd:schema> <xsd:import namespace="http://Servicios/" schemaLocation="http://localhost:8084/WS_Seguridad/ServicioSeguridad?xsd=1" /> </xsd:schema> </types> <message name="mensaje"> <part name="parameters" element="tns:mensaje" /> </message> <message name="mensajeResponse"> nsajeResponse"> <part name="parameters" element="tns:mensajeResponse" /> </message> <portType name="ServicioSeguridad"> <operation name="mensaje"> <input wsam:Action="http://Servicios/ServicioSeguridad/mensajeRequest" message="tns:mensaje" /> <output wsam:Action="http://Servicios/ServicioSeguridad/mensajeResponse" Action="http://Servicios/ServicioSeguridad/mensajeResponse" message="tns:mensajeResponse" /> </operation> </portType> <binding name="ServicioSeguridadPortBinding" type="tns:ServicioSeguridad"> <soap:binding transport="http://schemas.xmlsoap.org/soap/http" style="document" /> <operation name="mensaje"> <soap:operation soapAction="" /> <input> <soap:body use="literal" /> </input> <output> <soap:body use="literal" /> </output> </operation> </binding> <service name="ServicioSeguridadService"> <port name="ServicioSeguridadPort" binding="tns:ServicioSeguridadPortBinding"> <soap:address location="http://localhost:8084/WS_Seguridad/ServicioSeguridad" /> </port> </service> </definitions>
Marcamos la opcin de Secure Service en la consola de nuestro servicio. serv
Seleccionamos la opcin avanzadas, para abrir el editor de atributos.
En la seccin de seguridad del servicio, se puede ver que la han seleccionado los siguientes opciones: Compatibilidad de la versin. NET 1.0 o 3.0/Metro. 3.5/Metro NET 1.3. Seleccione la ltima versin que coincide con la versin de Metro o. NET que tenemos instalado. Mecanismo de seguridad. Especifica el mtodo utilizado para asegurar el servicio servicio web. En este caso, la autenticacin de usuario con claves simtricas se selecciona. La autenticacin de usuario con claves simtricas protege a la aplicacin de la integridad y confidencialidad. la criptografa de clave simtrica se basa en una sola tecla, el secreto compartido que se utiliza para firmar y cifrar un mensaje. Las claves simtricas son generalmente ms rpido que la criptografa de clave pblica. Por este mecanismo, el cliente no posee ningn tipo de certificado / clave de su cuenta, cue sino que enva su nombre de usuario / contrasea para la autenticacin. El cliente comparte una clave secreta con el servidor. La clave compartida, se genera en tiempo de ejecucin y cifrados con el certificado del servicio. El cliente debe especificar icar el alias en el almacn de confianza mediante la identificacin de alias del servidor de certificados. Usar valores predeterminados para el Desarrollo. Seleccione esta opcin para importar certificados en el almacn de claves del servidor y almacn de confianza, para que puedan ser utilizados inmediatamente para el desarrollo. Debido a que los certificados por defecto no se encuentran en un formato adecuado uado para ser utilizado en este contexto, esta importacin se hace para usted, de modo que usted no tiene que hacerlo manualmente. Adems de importar certificados, certificados un usuario por defecto se crea con nombre de usuario "wsitUser". En un entorno de produccin, producci es probable que desee ofrecer sus propios certificados y configuracin del usuario, sin embargo, en un entorno de desarrollo es posible encontrar estos valores predeterminados. Como mecanismo de seguridad elegiremos autenticacin de usuario con el mecanismo meca de claves simtricas.
En nuestro ejemplo elegiremos autenticacin de usuario con el mecanismo de claves simtricas, simtricas pero podramos seleccionar cualquiera de las siguientes opciones: Mutual Certificates Security: El mecanismo mutuo de certificados de e seguridad aade seguridad a travs de mensaje de proteccin de autenticacin que garantiza la integridad y confidencialidad. Cuando use certificados mutuos, , el archivo de almacn de confianza debe ser configurado tanto para el lado del cliente y el servidor dor de la aplicacin. Transport Security (SSL): El mecanismo de seguridad de transporte protege su aplicacin durante el uso de SSL de transporte para la autenticacin y confidencialidad. La seguridad de transporte de la capa es proporcionada por los mecanismos ismos de transporte utilizados para transmitir informacin sobre el alambre entre los clientes y proveedores, por lo tanto la seguridad de capa de transporte se basa en garantizar el transporte HTTP (HTTPS) usando Secure Sockets Layer (SSL). Message Authentication over SSL: La autenticacin de mensajes a travs de SSL mecanismo otorga un seguro de identidad criptogrficamente o token de autenticacin con el mensaje y el uso de SSL para la proteccin de la confidencialidad. SAML Authorization over SSL: El mecanismo de autorizacin SAML sobre SSL concede una autorizacin simblica con el mensaje y utiliza SSL para la proteccin de la confidencialidad. confidencialidad. Endorsing Certificate: Este mecanismo utiliza mensajes seguros con la clave simtrica para proteccin de la integridad y la confidencialidad, y utiliza un certificado de cliente para aumentar respaldar las reivindicaciones proporcionada por el smbolo asociado a la firma del mensaje. SAML Sender Vouches with Certificates: Este mecanismo protege los mensajes con los certificados mutuo de la integridad y la confidencialidad y con un remitente da fe de la autorizacin SAML token. SAML Holder of Key: Este mecanismo protege a los mensajes con una asercin de SAML firmada (expedido por una autoridad de confianza) cliente cliente de llevar a la clave pblica y la informacin con la autorizacin y confidencialidad proteccin de la integridad mediante certificados mutuo. Podemos seleccionar las casillas de verificacin de la derecha para el elemento que le gustara firmar, cifrar o requierir.Para Para ello, pulsaremos sobre el botn Message Parts de la seccin Input Message.
Despus dejar configurado el Web Service, crearemos el cliente que consuma el servicio. Crear un proyecto aplicacin java.
Llamamos al proyecto ConsumoWS_Seguridad. ConsumoWS_
Aadir un elemento de tipo Web Service Client.
Seleccionamos el Web Service que queremos consumir y pulsamos sobre finalizar.
Dentro de nuestra clase, pulsaremos botn derecho para que nos genere el cdigo de llmada al mtodo mensaje de e nuestro Web Service. Seleccionar Insert code, como se muestra en en la imagen.
Posteriormente, pulsamos sobre la opcin Call Web Service Operation.
Elegiremos el mtodo mensaje del servicio web que queremos consumir.
Realizaremos en el main la llamada al mtodo mensaje que nos acaba de generar. Pasaremos como parmetro un string que es lo que espera nuestro mtodo mensaje.
package consumows_seguridad; public class Main { /** * @param args the command line arguments */ public lic static void main(String[] args) { System.out.println(mensaje("Rosa")); } private static String mensaje(java.lang.String nombre) { aa.NewWebServiceService service = new aa.NewWebServiceService(); aa.NewWebService port = service.getNewWebServicePort(); return port.mensaje(nombre); } }
Pulsamos sobre edit web Service Attributes para poder incluir validacin al conectarnos al web Service.
Marcamos la opcin Use development default, de esta manera nos validaremos con el usuario por defecto que tiene GlassFish. Debido a que los certificados por defecto no se encuentran en un formato adecuado para ser utilizado en este contexto, , se importan unos por defecto. In addition to importing certificats, a default user is created in the "file" realm, with username "wsitUser". Adems de importar certificados, certificados un usuario puede utilizarlos validndose con el nombre de usuario "wsitUser". In a production environment, you will probably want to provide your own certificates certificates and user settings, however, in a development environment you may find these defaults useful. En un entorno de produccin, es probable que desee ofrecer sus propios certificados y configuracin del usuario, sin embargo, en un entorno de desarrollo es posible encontrar ar estos valores predeterminados. predeterminados
Salida del Consumidor del Servicio:
Ver Video: Seguridad Servicios, en el Mdulo 8. Unidad 4, en la plataforma elearning
Laboratorio: Seguridad Servicios

Objetivo
Implementar seguridad a nuestro servicio web de monedas.
Enunciado
Abriremos un proyecto Web Application para crear el servicio web.
Llamaremos al proyecto WS_Seguridad.
Seleccionamos como servidor GlassFish.
No seleccionaremos ningn Framework, y por ltimo le daremos a finalizar.
Aadiremos a nuestro proyecto web un archivo de tipo Web Service.
En la caja de texto para introducir el nombre del servicio introduciremos ServicioSeguridad. Guardar el servicio en el paquete Servicios.
Aadimos las operaciones del servicio web de monedas.
//Declaramos un array con el valor de cada una de las monedas. monedas public double[] valores=new double[] {1.26201, 14.4762, 75.6061, 135.861, 166.386};
@WebMethod(operationName = "convertirMonedaEuro") public Double convertirMonedaEuro(@WebParam(name = "valor") double valor, @WebParam(name = "indice") int indice) { return (valor * valores[indice]); } @WebMethod(operationName = "convertirEuroMoneda") public Double convertirEuroMoneda(@WebParam(name = "valor") double valor, @WebParam(name = "indice") int indice) { return (valor / valores[indice]); } Marcamos la opcin de Secure Service en la consola de nuestro servicio.
Seleccionamos la opcin avanzadas, para abrir el editor de atributos.
Como mecanismo de seguridad elegiremos autenticacin de usuario con el mecanismo de claves simtricas.
Despus dejar configurado el Web Service, crearemos el cliente que consuma el servicio.
Crear un proyecto aplicacin java.
Llamamos al proyecto ConsumoWS_Seguridad.
Aadir un elemento de tipo Web Service Client.
Seleccionamos el Web Service que queremos consumir y pulsamos sobre finalizar.
Dentro de nuestra clase, pulsaremos botn derecho para que nos genere el cdigo de llmada al mtodo mensaje de nuestro Web Service. Seleccionar Insert code, como se muestra en en la imagen.
Posteriormente, pulsamos sobre la opcin Call Web Service Operation.
Realizaremos en el main la a llamada al mtodo mensaje que nos acaba de generar. Pasaremos como parmetro un string que es lo que espera nuestro mtodo mensaje.
public static void main(String[] args) { double resultado = convertirMonedaEuro(121,2); System.out.println(resultado); } private static Double convertirMonedaEuro(double valor, int indice) { ConsumirWS.NewWebServiceService service = new ConsumirWS.NewWebServiceService();
ConsumirWS.NewWebService port = service.getNewWebServicePort(); return port.convertirMonedaEuro(valor, indice); } Pulsamos sobre edit web Service Attributes para poder incluir validacin al conectarnos al web Service.
Marcamos la opcin Use development default, de esta manera nos validaremos con el usuario por defecto que tiene GlassFish. Debido a que los certificados por defecto no se encuentran en un formato adecuado para ser utilizado en este contexto, , se importan unos por defecto. In addition to importing certificats, a default user is created in the "file" realm, with th username "wsitUser". Adems de importar certificados, certificados un usuario puede utilizarlos validndose con el nombre de usuario "wsitUser". In a production environment, you will probably want to provide your own certificates and user settings, however, in a development dev environment you may find these defaults useful. En un entorno de produccin, es probable que desee ofrecer sus propios certificados y configuracin del usuario, sin embargo, en un entorno de desarrollo es posible encontrar ar estos valores predeterminados. predetermi

Java Modulo 8

Caricato da

Informazioni sul documento

Descrizione originale:

Copyright

Formati disponibili

Condividi questo documento

Condividi o incorpora il documento

Opzioni di condivisione

Hai trovato utile questo documento?

Questo contenuto è inappropriato?

Copyright:

Formati disponibili

Java Modulo 8

Caricato da

Copyright:

Formati disponibili

Profesional en Plataforma Java

Mdulo 8: Diseando servicios web Java

Mdulo 8: Diseando servicios web Java

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

Unidad 1: Analizando Oportunidades con los Servicios Web

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

Seguridad o WS-Security, Security, XML Signature y XML Encription (Especificaciones JSR)

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.

Estndares Principales de 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 orientada a servicios

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.

Desarrollo de servicios web con tecnologa java

Ejemplo de desarrollo web con tecnologa java

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

Abrir un proyecto de tipo web y llamarlo llamar WSNombre.

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

Agregamos un archivo de tipo WebService, le damos un nombre y un paquete donde guardarlo.

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.

Agregamos un archivo de tipo Web Service Client.

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

Pulsamos sobre la opcin examinar y elegimos el servicio web recin creado.

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

CONSUMIR EL SERVICIO WEB DESDE UN PROYECTO WEB

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

API Java para Servicios Web XML (JAX-WS)

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.

Servicio web tiempo po meteorolgico

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

Referencia al servicio web: http://www.webservicex.net/globalweather.asmx?WSDL Probamos el servicio recin referenciado.

Ver Video: Analizando ServiciosWeb, en el Mdulo 8. Unidad 1, en la plataforma elearning

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

Laboratorio: Analizando ServiciosWeb

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.

Unidad 2: Diseando Buenas Prcticas y Patrones para los Servicios Web

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

Clasificacin: Segn el Propsito: Qu hacen?

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.

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

Patrones atrones de diseo basados en 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.

Buenas practicas para desarrollar servicios web SOAP

Analizar qu servicios web y con qu operaciones hay que desarrollar

Escribe tu mismo el fichero WSDL (Contract-First) (

Ms eficiente un nico co mensaje enorme

S coherente con la nomenclatura de namespaces de la organizacin

El WSDL debe ser compatible con el WS-I WS Basic Profile

Usa http://localhost:puerto como direccin url del endpoint

Separa la definicin de los mensajes del fichero WSDL. WSD

Crea tipos y elementos globales

Envio de ficheros adjuntos

Programar ar tus tests a nivel de la clase Skeleton