Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado)

Transcripción

1 Tecnologías para Desarrollo Orientado a Servicios (posgrado) Desarrollo de Software Orientado a Servicios (pregrado) 1)Mg. Elsa Estévez 2)Universidad Nacional del Sur

2 2 Agradecimiento Este curso se ha desarrollado en base al material de los siguientes cursos: 1) XML Technology and Java, preparado y dictado por Dr. Tomasz Janowski, UNU-IIST 2) Web Services and Java Ambos cursos fueron desarrollados y dictados en United Nations University - International Institute of Software Technology (UNU-IIST), Macao. A Martín Larrea por su colaboración con el testeo del software en el laboratorio.

3 Servicios Web

4 4 Servicios Web: Contenido 1) Introducción 2) SOAP a) introducción b) mensajes c) estructuras de datos d) binding a protocolos e) datos binarios 3) WSDL a) introducción b) el lenguaje c) primitivas de transmisión d) extensiones de WSDL e) WSDL y Java 4) AXIS a) conceptos b) invocación de servicios c) herramientas y configuración d) deploy de servicios e) ciclo de vida de servicios 5) UDDI a) introducción b) conceptos c) tipos de datos d) registros UDDI 6) Seguridad a) conceptos de seguridad b) seguridad en web services c) firmas digitales

5 5 Páginas de Consulta 1) W3C World Wide Web Consortium, 2) OASIS Organization for the Advancement of Structured Information Standards, 3) Apache Apache Software Foundation,

6 6 Especificaciones 1) SOAP - 2) AXIS - 3) WSDL - 4) UDDI - 5) WS-Security -

7 Introducción

8 8 Introducción: Contenido 1) Definiciones 2) Arquitectura Orientada a Servicios 3) Servicios Web (WS) 4) Relacionando SOA y WS 5) Arquitectura de WS 6) Detalles de Implementación 7) Resumen

9 9 Definición de Servicio Definición de W3C: Un servicio es un recurso abstracto que representa una capacidad de realizar tareas que conformar una funcionalidad coherente desde el punto de vista de las entidades proveedoras y consumidoras. Para ser usado, un servicio debe ser realizado por un agente proveedor concreto. [Web Services Glossary

10 10 Conceptos Un servicio: 1) es un recurso y tiene un dueño 2) es provisto por una persona o una organización 3) debe ser realizado por un agente proveedor (software) 4) realiza una o más tareas 5) es usado por un agente que lo requiere Ejemplo: un servicio para actualización de software

11 11 Servicio Web (WS) Un servicio web es una aplicación de software que aplica XML para intercambiar datos con otras aplicaciones en otras computadoras. Características de los servicios web: 1) los servicios web operan sobre cualquier red (Internet o una Intranet privada) para lograr tareas específicas. 2) las tareas realizadas por un servicio web son métodos o funciones que otras aplicaciones pueden invocar y usar. 3) los requerimientos/respuestas a/de un web service pueden ser enviadas/recibidas entre diferentes aplicaciones en diferentes computadoras pertenecientes a diferentes organizaciones.

12 12 Definición de Servicio Web Definición de W3C: Un Servicio Web es un sistema de software diseñado para mantener interacciones interoperables de máquina-a-máquina sobre una red: 1) tiene una interface descripta en un formato procesable por una máquina (específicamente WSDL). 2) otros sistemas interactúan con el servicio web de una manera prescripta por su descripción usando mensajes SOAP, generalmente usando HTTP con una serialización de XML en conjunto con otros estándares de Web. [Web Services Glossary

13 13 Ejemplo de Servicio Web Un servicio web de Google para búsquedas -

14 14 Tarea: Búsquedas en Google Objetivo: búsqueda automática en Google usando un WS 1) cd demos\ws\primer Ejemplo 2) dir googleapi.jar GoogleApiDemo.class GoogleSearch.wsdl 1) copy googleapi.jar \j2sdk1.4.2_04\jre\lib\ext 2) java cp \demos\ws\firstexample GoogleApiDemo Macao

15 15 Descripción de Servicio Una descripción de servicio son datos que describen las capacidades de un web service: 1) toda la información necesaria en orden a invocar un servicio web 2) el concepto clave para Arquitecturas Orientadas a Servicios (SOA) El estándard para escribir descripciones de servicios es WSDL.

16 16 Tarea : Descripción de Google 1) cd demos\ws\primer Ejemplo 2) doble-click GoogleSearch.wsdl 3) aparece la siguiente ventana: aplicación de un servicio web 4) abrir el archivo con un browser documento WSDL describiendo el servicio

17 17 Introducción: Contenido 1) Definiciones 2) Arquitectura Orientada a Servicios 3) Servicios Web (WS) 4) Relacionando SOA y WS 5) Arquitectura de WS 6) Detalles de Implementación 7) Resumen

18 18 Definición de SOA SOA = Service-Oriented Architecture SOA es una arquitectura de software donde todas las tareas y procesos de software son implementados como servicios para ser consumidos sobre una red. Palabras Claves: 1) arquitectura 2) servicio

19 19 Enfoque SOA El foco del diseño es la interface del servicio. Un servicio: 1) tiene una interface bien definida 2) puede ser potencialmente invocado sobre una red 3) puede ser reusado en múltiples contextos de negocios Una aplicación: 1) es integrada en el nivel de interface y no en el nivel de implementación 2) es construida para trabajar con cualquier implementación de un contrato, resultando en sistemas más flexibles y menos acoplados

20 20 Componentes de SOA 1) roles Registro de a) proveedor de servicios Servicios b) solicitante de servicios c) registro de servicios encontrar publicar 2) operaciones a) publicar Solicitante de Servicios bind Proveedor de Servicios b) ligar (bind) c) encontrar

21 21 SOA-Roles: Proveedor de Servicios Qué hace un proveedor de servicios? 1) crea una descripción de servicios 2) entrega un servicio en un entorno de ejecución para hacerlo disponible a otras entidades sobre una red 3) publica la descripción del servicio en uno o más registros de servicios 4) recibe mensajes invocando servicios de los solicitantes de servicios Una entidad que hostea un servicio web accesible a través de una red es un proveedor de servicios.

22 22 SOA-Roles: Solicitante de Servicios Qué es un solicitante de servicios? 1) encuentra una descripción de servicio publicada en un registro de servicios 2) aplica la descripción del servicio para ligar e invocar el servicio web hosteado en un proveedor de servicios Un solicitante de servicios puede ser cualquier consumidor de un servicio web.

23 23 SOA-Roles: Registro de Servicios Qué hace un registro de servicios? 1) acepta las solicitudes de los proveedores de servicios para publicar y publicitar las descripciones de servicios 2) permite a los solicitantes de servicios buscar en la colección de descripciones de servicios contenida en el registro de servicios El rol del registro de servicios es permitir el match entre los proveedores de servicios y los solicitantes de servicios. Una vez que se encontró el servicio buscado, las interacciones se llevan a cabo directamente entre el solicitante del servicio y el proveedor del servicio.

24 24 SOA-Operaciones: Publicar La operación de publicar es un acto de registración o publicación de servicios. Cuando un proveedor de servicios publica su servicio web en un registro de servicios, está publicitando el servicio a toda la comunidad de potenciales solicitantes del servicio. Los detalles de la operación de publicar depende de cómo el registro de servicios está implementado. Registro de Servicios publicar Proveedor de Servicios

25 25 SOA-Operaciones: Encontrar La operación de encontrar es un acto de buscar un servicio que satisface ciertas condiciones: Service Registry 1) el solicitante del servicio establece un criterio de búsqueda, tal como: el tipo de servicio, la calidad, etc. 2) El registro de servicios matchea los criterios de búsqueda con las descripciones de servicio publicadas find Service Requestor El resultado es una lista de descripciones de servicios que matchean el criterio de selección. Los detalles de la operación dependen de la implementación del registro de servicio.

26 26 SOA-Operaciones: Ligar La operación de ligar crea la relación cliente-servidor entre el solicitante del servicio y el proveedor del servicio. La operación puede ser: 1) dinámica creando un proxy del lado del cliente on the fly- basado en la descripción del servicio para invocar el servicio web 2) estática el desarrollador hard-codea la forma en que el cliente invoca el servicio web Solicitante del Servicio ligar Proveedor del Servicio

27 27 Propiedades de SOA 1 SOA es una forma de arquitectura de sistemas distribuidos. Está caracterizada por: 1) visión lógica un servicio es una abstracción, es lo que los programas, bases de datos, procesos de negocios, etc. actuales son capaces de hacer. 2) intercambio de mensajes un servicio está definido en términos de los mensajes intercambiados entre los agentes proveedores y solicitantes y no en términos de las propiedades de los agentes en sí mismos.

28 28 Propiedades de SOA 2 3) abstracción SOA esconde los detalles de implementación de los lenguajes de implementación, procesos, estructuras de bases de datos, etc. 4) meta-datos un servicio es descripto via meta-datos procesables por una máquina 5) número pequeño de operaciones un servicio tiende a tener un número pequeño de operaciones con mensajes relativamente grandes y complejos 6) orientado a redes los servicios están orientados a ser usados sobre una red 7) plataforma neutral los mensajes son enviados en un formato estandarizado entregado a través de interfaces. Se usa XML.

29 29 Beneficios de SOA 1 SOA permite a los agentes que participan en el intercambio de mensajes que sean mínimamente acoplados, que a su vez permite mayor flexibilidad: 1) un cliente está sólo acoplado a un servicio, no a un servidor la integración del servidor tiene lugar fuera del alcance de la aplicación cliente 2) los componentes funcionales y sus interfaces están separados se pueden añadir fácilmente nuevas interfaces 3) funcionalidad nueva y vieja puede ser encapsulada como componentes de software que proveen y solicitan servicios

30 30 Beneficios de SOA 2 4) se puede aislar el control de los procesos de negocios: a) motores de reglas de negocios pueden controlar el workflow de un proceso de negocios b) dependiendo del estado, el motor invoca diferentes servicios 5) los servicios pueden ser incorporados dinámicamente durante el tiempo de ejecución 6) los bindings de servicios son especificados usando archivos de configuración y pueden ser fácilmente adaptados para satisfacer nuevas necesidades

31 31 Descripción de Servicios en SOA La clave de SOA es la descripción del servicio: 1) es publicada por el proveedor del servicio en un registro de servicios 2) es entregada al solicitante del servicio como resultado de una operación de búsqueda 3) especifica al solicitante del servicio: a) cómo hacer el binding e invocar al servicio web b) qué información es devuelta como resultado de la invocación

32 32 Introducción: Contenido 1) Definiciones 2) Arquitectura Orientada a Servicios 3) Servicios Web (WS) 4) Relacionando SOA y WS 5) Arquitectura de WS 6) Detalles de Implementación 7) Resumen

33 33 Componentes de WS Un servicio web incluye tres componentes básicos: 1) un mecanismo para encontrar y registrar un servicio 2) una definición de los parámetros de input y de output del servicio 3) un mecanismo de transporte para acceder al servicio Los servicios web tambien incluyen otras tecnologías que pueden ser usadas para proveer características adicionales tales como seguridad, procesamiento de transacciones, y otras.

34 34 Proceso de WS 1) un proveedor de servicio publica un servicio en un repositorio externo 2) un cliente busca por un servicio en el repositorio 3) el repositorio devuelve información sobre el servicio: formato de llamada dirección del proveedor 4) el cliente hace la unión con el servicio (binding) 5) el cliente llama y accede al servicio [courtesy Al Saganich]

35 35 WS y Otras Tecnologías Los servicios web no introducen nueva funcionalidad. Funcionalidad similar es provista por: 1) Sun/RPC 2) DCOM 3) Enterprise Java Beans 4) etc. La diferencia es cómo esta funcionalidad es provista.

36 36 Aplicación CORBA - Ejemplo Un cliente requiere un archivo de un servidor. El servidor envía el archivo al cliente. Cuando lo recibe, el cliente salva el archivo en la máquina local. Los pasos involucrados son: 1) definir una interface de servicio en IDL 2) mapear la interface de IDL interface a Java (automático) 3) implementar la interface (FileInterface.idl) 4) desarrollar el servidor (FileServer.java) 5) desarrollar el cliente (FileClient.java) 6) ejecutar el servicio de nombres, el servidor, y el cliente

37 37 CORBA Ejemplo 1 Ejecutar la aplicación: 1) El servidor corre en una PC auxiliar: - ejecutar el servicio de nombres de CORBA: tnameserv -ORBInitialPort inicializar el servidor: java FileServer ORBInitialPort ) el cliente corre en la PC actual: run_corba_client.bat pide descargar un archivo envía el archivo

38 38 CORBA Ejemplo 2 Qué sucede si habilitamos un firewall del lado del servidor? Probemos de ejecutar la aplicación cliente: firewall

39 39 Aplicación con Servicios Web Considerar la misma aplicación desarrollada usando un servicio web. Un cliente requiere un archivo del servidor. El servidor envía el archivo al cliente. Cuando lo recibe, el cliente salva el archivo en la máquina local. Los pasos involucrados: 1) setear el servidor SOAP 2) desarrollar el servidor 3) desarrollar el cliente 4) inicializar el servidor web 5) entregar el servidor como un servicio web 6) ejecutar la aplicación cliente

40 40 Servicios Web Ejemplo 1 Ejecutar la aplicación: 1) El servidor corre en una PC auxiliar inicializar el servidor web 2) El cliente corre en la PC actual run_client.bat pide descargar un archivo mensajes SOAP envía el archivo

41 41 Servicios Web Ejemplo 2 Qué sucede si habilitamos un firewall del lado del servidor? Probemos de ejecutar la aplicación cliente: firewall pide descargar un archivo mensajes SOAP envía el archivo

42 42 Comparación: Comunicación Cuál es la diferencia observable entre las aplicaciones CORBA y WS? Con el firewall habilitado, la aplicación CORBA no puede ejecutar satisfactoriamente. Una ventaja de SOAP es la definición explícita del binding con HTTP a través de esconder otro protocolo dentro de los mensajes HTTP. Esto permite a los mensajes SOAP pasar sin impedimentos a través de un firewall. Los firewalls habitualmente permiten el protocolo HTTP a través del puerto 80, mientras que restringen el uso de otros puertos o protocolos.

43 43 Comparación: Funcionalidad La misma funcionalidad en CORBA y WS. La diferencia está en cómo los WS proveen esa funcionalidad: 1) los datos son formateados para transferirlos usando XML 2) los datos se pasan usando protocolos de comunicación estándar 3) el servicio expuesto está bien definido en un vocabulario XML 4) los servicios se encuentran en formato estándar usando vocabularios XML WS provee un diseño más flexible que CORBA.

44 44 Comparación: Estándares La principal diferencia con los entornos de computación distribuida anteriores es la adopción de estándares: 1) un servicio estándar de búsqueda UDDI 2) un mecanismo de definición estándar WSDL 3) una forma estándar de comunicación de dos partes SOAP La tecnología fundacional para los tres (y más) es XML.

45 45 Web Service: Mensaje Un mensaje de solicitud: <soapenv:envelope xmlns:soapenv= xmlns:xsd= xmlns:xsi= > <soapenv:body> <ns1:downloadfile soapenv:encodingstyle= xmlns:ns1= > <ns1:arg0 xmlns:soapenc= xsi:type= soapenc:string > name_of_file </ns1:arg0> </ns1:downloadfile> </soapenv:body> </soapenv:envelope>

46 46 Implementación de Servicios Web Los estándares usados por los servicios web son definidos sin interesarse por los mecanismos de implementación. Por consiguiente: un servicio web escrito en C y corriendo en Microsoft IIS puede acceder a un servicio web escrito en Java corriendo en un BEA WebLogic Server. WS written in C MS-IIS WS written in Java BEA-Weblogic Server

47 47 Entornos de Servicios Web Existen varios entornos para construir, entregar y acceder a servicios web. Los más conocidos: 1) Plataforma Microsoft s.net 2) Plataforma Sun s Java 2

48 48 Comunicación Tradicional La comunicación tradicional en los sistemas: 1) los sistemas son altamente dependientes 2) los datos son transferidos de tal forma que los dos sistemas deben acordar de antemano el formato 3) varias formas normales de redes fueron creadas para decidir cómo codificar bytes, enteros, etc. para transferirlos.

49 49 Comunicación Basada en XML Antes no había un mecanismo común para definición de datos. Con XML: 1) representación de datos común y bien definida 2) conjunto bien definido de reglas de validación y de bien-formado La comunicación de servicios web confía en la sintaxis de XML para escribir mensajes.

50 50 WS Perspectiva Comercial Servicios web y objetivos de negocios y de procesos: 1) un servicio web es una implementación de un proceso de negocio o de un paso dentro de un proceso de negocio 2) un servicio web se pone disponible en una red para socios de negocios internos y/o externos para lograr objetivos de negocios específicos Los servicios web promueven la integración de aplicaciones dentro de una organización y entre diferentes partes del negocio. Rasgo clave: permitir la contrucción rápida de aplicaciones comerciales combinando los servicios web construidos internamente con aquellos de las otras partes del negocio.

51 51 Uso de Servicios Web Dos escenarios principales de uso: 1) integración de aplicaciones 2) integración de partes en B2B sobre Internet

52 52 WS Uso: Integración de Aplicaciones Los sistemas legados pueden envolverse (wrapped) como servicios web y hacerse disponibles para integrarlos con otros sistemas. Las aplicaciones expuestas como servicios web son accedidas por otras aplicaciones corriendo en diferentes plataformas de hardware y escritas en diferentes lenguajes.

53 53 WS Uso: Integración B2B Integración de partes Business-to-Business (B2B) sobre Internet. B2B integra sistemas comerciales de dos o mas empresas para soportar procesos de negocios multi-empresas, por ejemplo: administración de la cadena de provisionamiento. Empresa A Empresa B

54 54 Propiedades de WS 1 1) auto-contenido - no se requiere software adicional para WS: a) lado-cliente: un lenguaje de programación con soporte a clientes XML/HTML b) lado-servidor: se necesita un servidor web y un servidor SOAP 2) mínimamente acoplado el cliente y el servidor sólo saben de mensajes un simple nivel de coordinación que permite reconfiguraciones más flexibles 3) habilitados-en-la-web WS son publicados, ubicados, e invocados a través de la web usando estándares de Internet 4) independiente-del-lenguaje e interoperable el cliente y el servidor pueden estar implementados en diferentes entornos y en diferentes lenguajes

55 55 Propiedades de WS 3 5) para-componer los WS pueden agregarse usando técnicas de workflow para realizar funciones de negocio de alto-nivel 6) dinámicamente ligados - con UDDI y WSDL, se puede automatizar el descubrimiento y el binding de servicios web 7) accedidos-por-programas el enfoque de servicios web no provee una interface gráfica pero opera a nivel de comandos 8) envoltura para aplicaciones existentes aplicaciones stand-alone pueden integrarse fácilmente implementando un servicio web como interface

56 56 Beneficios de Servicios Web 1) integración de plataformas la neutralidad de plataforma de los WS permite combinar sistemas comerciales usando diferentes dispositivos (PDAs, teléfonos celulares, PCs) con proveedores de servicios de todos los tamaños y formas 2) integración de software sistemas soportando procesos de negocios nuevos o modificados pueden ser fácilmente entregados envolviendo funcionalidad existente 3) tecnología estándar estándares abiertos permiten a los desarrolladores elegir entre diferentes productos, evitando la dependencia del proveedor 4) integración de pequeños negocios el bajo costo de WS permite a pequeñas empresas entregar y participar en aplicaciones de WS 5) fácil integración el desarrollo basado en interfaces usando las descripciones de WS reduce el tiempo de integración de aplicaciones

57 57 Introducción: Contenido 1) Definiciones 2) Arquitectura Orientada a Servicios 3) Servicios Web (WS) 4) Relacionando SOA y WS 5) Arquitectura de WS 6) Detalles de Implementación 7) Resumen

58 58 SOA y WS Arquitectura Orientada a Servicios: 1) provee un enfoque para construir sistemas basados en un conjunto de componentes (servicios) mínimamente acoplados que pueden ser compuestos dinámicamente 2) promueve integración de software transparente (seamless) como ventajas o beneficios comerciales Servicios Web: 1) un enfoque para construir SOA 2) provee un estándar para un conjunto de tecnologías basadas en XML que pueden ser usadas para construir sistemas con SOA

59 59 Enfoque Basado en WS para SOA [courtesy IBM]

60 60 Usando SOA y WS SOA y WS son los enfoques más apropiados para aplicaciones que: 1) pueden operar sobre Internet, aceptando que la confiabilidad y la performance de comunicaciones no pueden garantizarse 2) no requieren que los solicitantes de servicios y los proveedores se actualicen al mismo tiempo 3) consisten de componentes ejecutándose remotamente en diferentes plataformas de ejecución y con diferentes productos de fabricantes 4) fueron diseñadas usando tecnología legada pero se necesita exponerlas en una red, usando una envoltura de servicio web

61 61 Introducción: Contenido 1) Definiciones 2) Arquitectura Orientada a Servicios 3) Servicios Web (WS) 4) Relacionando SOA y WS 5) Arquitectura de WS 6) Detalles de Implementación 7) Resumen

62 62 Arquitectura [courtesy W3C]

63 63 Capa de Comunicaciones Los servicios web son esencialmente de transporte-neutral. Un mensaje de un servicio web puede ser transportado usando HTTP o HTTPS, así como otros mecanismos de transporte más específicos, por ejemplo JMS. Los servicios web liberan al diseñador de la mayor parte de los detalles e implicaciones de la capa de transporte de mensajes.

64 64 Capa de Mensajería SOAP = Simple Object Access Protocol Un protocolo para intercambiar información estructurada en un entorno distribuido. Extensiones SOAP: 1) WS-ReliableMessaging un estándar de mensajes entre servicios web para garantizar la recepción de mensajes para los solicitantes y los proveedores 2) WS-Transactions una serie de estándares relacionados con invocaciones de servicios web en transacciones (semántica de atomicidad, consistencia, y persistencia)

65 65 Capa de Descripción WSDL = Web Services Description Language Un lenguaje que permite al proveedor de servicios especificar las características funcionales de sus servicios web. Extensiones de WSDL: 1) WS-Policy aumenta WSDL con restricciones no-funcionales de los WS 2) WS-ResourceProperties describe cómo definir y acceder a las propiedades de los recursos a través de WS

66 66 Capa de Procesos: Descubrimiento Discovery ubicar una descripción de un servicio web procesable por una máquina que podría ser previamente desconocido y que satisface ciertos criterios. UDDI = Universal Description, Discovery and Integration UDDI define una forma de almacenar y buscar información sobre servicios web.

67 67 Capa de Procesos: Coreografía Choreography define cómo múltiples agentes independientes cooperan intercambiando mensajes para realizar una tarea o lograr un objetivo. WS-CDL = WS Choreography Description Language WS-CDL describe colaboraciones peer-to-peer donde un intercambio de mensajes ordenado produce el cumplimiento de un objetivo de negocio común.

68 68 Interoperabilidad de WS Los servicios web resuelven el conjunto de problemas relacionados con computación distribuida heterogénea configurada dinámicamente y mínimamente acoplada. Especificaciones de WS: 1) una serie de especificaciones pequeñas, orientadas a un propósito resolviendo problemas específicos (seguridad, transacciones, etc.) en forma separada 2) cada especificacón de WS está diseñada para ser compuestar con las otras 3) los diseñadores de WS determinan qué especificaciones necesitan sus sistemas y las implementan en consecuencia.

69 69 Organización WS-I Web Services Interoperability organization (WS-I): 1) WS-I es para estandarizar combinaciones de especificaciones de WS que pueden ser usadas para aumentar el nivel de interoperabilidad entre servicios web 2) WS-I promueve el Basic Profile guías de implementación de cómo las especificaciones no propietarias, tales como SOAP, WSDL, UDDI se deben usar en forma conjunta para una mejor interoperabilidad. WS-I website -

70 70 Introducción: Contenido 1) Definiciones 2) Arquitectura Orientada a Servicios 3) Servicios Web (WS) 4) Relacionando SOA y WS 5) Arquitectura de WS 6) Detalles de Implementación 7) Resumen

71 71 Apache Axis Apache y Axis: 1) Apache es un servidor HTTP de código abierto - 2) Axis es un motor SOAP de código abierto - Axis convierte objetos Java a datos SOAP para enviar/recibir mensajes.

72 72 Apache Axis - Módulos Axis implementa la API standard de Java para servicios Web - JAX-RPC. Axis: 1) es compilado en el archivo JAR axis.jar 2) implementa la API JAX-RPC declarada en: a) jaxrpc.jar b) saaj.jar Todos estos archivos pueden ser empaquetados en una aplicación web llamada axis.war que puede ser desplegada en un contenedor de servlets. Servlet Clase de Java que puede responder a requerimientos de HTTP.

73 73 Apache Axis - Requerimientos Qué se necesita? 1) Java 1.4 2) Tomcat 4.x

74 74 Tomcat Qué es Tomcat? 1) un contenedor de servlets usado en la Implementación de Referencia oficial de las tecnologías Java Servlet y JavaServer Pages 2) una implementación libre y de código abierto 3) fue desarrollado en el proyecto Jakarta en Apache Software Foundation 4) referencias a Tomcat -

75 75 Instalar Apache Axis Pasos para instalar Apache Axis: 1) actualizar la variable JAVA_HOME 2) instalar Tomcat 3) instalar Apache Axis 4) desplegar Axis 5) validar la instalación

76 76 Tarea: Actualizar JAVA_HOME 1) seleccionar My Computer, oprimir botón derecho y seleccionar Properties 2) seleccionar Advanced y Environment Variables 3) seleccionar System Variables y modificar JAVA_HOME para contener el path al directorio de instalación de j2sdk1.4

77 77 Task: Instalar Tomcat 1 1) visitar 2) seleccionar Download - Binaries 3) seleccionar Download - Tomcat 4) seleccionar Tomcat 4 5) seleccionar Binary exe 6) salvar el archivo: jakarta-tomcat exe en su directorio local

78 78 Tarea: Instalar Tomcat 2 7) ejecutar jakarta-tomcat exe 8) responder del siguiente modo: a) Using Java Development Kit found in j2sdk1.4.2_04 OK b) To the window about Apache License I Agree c) Setup Installation Options: 1)Tomcat 2)JSP Development Shell Extensions 3)Tomcat Start Menu Group 4)Documentation and Examples Next d) Destination Folder: D:\Tomcat 4.1 or E:\Tomcat 4.1 Install Next e) HTTP/1.1 Connector Port: 8080 User name: admin Finish

79 Tarea: Verificar Instalación 79

80 80 Tarea: Instalar Axis 1 1) visitar 2) seleccionar Axis 1.2 RC2 release

81 81 Tarea: Instalar Axis 2 3) seleccionar el Apache download mirrors 4) salvar el archivo: axis-1_2rc2-bin.zip a su directorio local

82 82 Tarea: Instalar Axis 3 5) descomprimir: axis-1_2rc2-bin

83 Tarea: Verificar Instalación 83

84 84 Tarea: Desplegar Axis En orden a desplegar Axis en Tomcat: 1) en E:\axis-1_2RC2\webapps, copiar la carpeta: axis 2) en E:\jakarta-tomcat \webapps, pegar la carpeta: axis

85 85 Tarea: Validar Instalación 1 Iniciar Tomcat - doble-click E:\jakarta-tomcat \bin\startup.bat

86 86 Tarea: Validar Instalación 2 Al iniciar Tomcat aparece la siguiente ventana: (los colores están invertidos)

87 87 Tarea: Validar Instalación 3 Navegar a la página de inicio de la webapp

88 88 Tarea: Validar Instalación 4 Validar la instalación de Axis seguir el link Validate

89 89 Tarea: Validar Instalación 5 Si la instalación fue satisfactoria, luego se displaya la siguiente página:

90 90 Tarea: Ejecutar WS 1 Navegar a la página de inicio y clickear en View para ver la lista de servicios web desplegados:

91 91 Tarea: Ejecutar WS 2 Se displaya la página: Cliquear en AdminService (wsdl).

92 92 Tarea: Ejecutar WS 3 Presenta una descripción de WS en WSDL:

93 93 Tarea: Testear WS 1 Invocamos el servicio getversion que devuelve un mensaje con el número de versión de la instalación de Axis. Abrir el navegador en:

94 94 Tarea: Testear WS 2 Como respuesta, se obtiene el siguiente mensaje: Un envelope de SOAP!

95 95 Desplegar un Servicio Web Axis usa un deployment descriptor para desplegar un servicio web. Un deployment descriptor es un archivo XML específico de Axis, que le dice a Axis cómo desplegar (o des-desplegar?) un servicio, y cómo configurar Axis en sí mismo. Desplegar un servicio web: 1) copiar la clase que se desea desplegar como servicio web en: \Tomcat 4.1\webapps\axis\WEB-INF\classes 2) escribir el deployment descriptor 3) ejecutar AdminClient

96 96 WS Deployment Descriptor 1 Para desplegar un servicio web, el elemento raiz del documento XML deployment descriptor debe ser el tag <deployment>. El hijo obligatorio del elemento <deployment> es: <service name= nombre provider= proveedor > </service> Se usa para desplegar o eliminar un servicio Axis, donde: 1) name nombre del servicio web 2) provider especifica el proveedor particular del servicio web como por ejemplo: Java-RPC, Java-EJB, etc.

97 97 WS Deployment Descriptor 2 Las diferentes opciones del servicio pueden especificarse de la siguiente manera: <parameter name= nombre" value="valor"/> y las más comunes incluyen: 1) classname la clase de implementación en el punto final 2) allowedmethods cada proveedor puede determinar qué métodos exponer como servicios web