Web Services Tecnologías asociadas

Transcripción

1 Web Services 274

2 Web Services Tecnologías asociadas SOAP WSDL XML Tecnologías asociadas El modelo de web services está basado en ciertas tecnologías emergente que es el resultado del trabajo de varias compañías y organizaciones entre las cuales se destacan IBM y Microsoft. Estas tecnologías son SOAP, WSDL y XML. 275

3 Web Sevices Tecnologías SOAP Protocolo de intercambio de información para un ambiente descentralizado y distribuido Basado en XML Modelo de comunicación HTTP SOAP es un protocolo para el intercambio de información en un ambiente descentralizado y distribuido. Es el protocolo más utilizado para realizar el intercambio de información en el modelo de web services. Esta basado en XML y potencialmente puede ser utilizado en combinación con una variedad de protocolos de comunicación, siendo el más utilizado HTTP. Por lo tanto se utiliza HTTP para transportar la información, y XML para representar la misma. El protocolo completo se puede encontrar en El modelo de comunicación de SOAP es muy similar al de HTTP. Un cliente hace un requerimiento (request), el servidor que esta escuchando los requerimientos lo atiende y responde (response) brindando la información solicitada o enviando un mensaje de error en caso de que el requerimiento no haya sido válido. El mensaje SOAP consiste en un elemento envelope SOAP obligatorio, un cabezal SOAP opcional y un cuerpo SOAP obligatorio como un documento XML. El cabezal SOAP es utilizado para definir información acerca del requerimiento, mientras que el cuerpo SOAP contiene el método llamado y los parámetros con los que se llama al mismo. Todo esto es un modelo de mensajes request/response con una forma de describir un conjunto de métodos y pasarle a los mismos parámetros. Esto parece la base del protocolo RPC y de hecho es el uso más común de SOAP. El potencial es entregar esto sobre Internet utilizando HTTP para realizar comunicaciones entre organizaciones permitiendo realizar comunicaciones entre aplicaciones con diferente plataforma, sistema operativo y lenguaje de programación. 276

4 Web Services en GeneXus Proveedores Procedimientos SOAP Consumidores WSDL Import Wizard A continuación se detallan los mecanismos para proveer y consumir Web Services con GeneXus. Proveer: Para proveer Web Services con GeneXus se debe definir un objeto Procedimiento o Reporte, que debe ser de tipo main, y asociado a un generador Web. Se debe configurar la propiedad de objeto Call protocol con el valor SOAP. Se debe publicar el objeto en un servidor Web, con lo que el Web Service queda operativo para ser invocado. El WSDL del servicio queda disponible agregando el parámetro WSDL a la URL del mismo. Por ejemplo: Consumir Se utiliza el WSDL Import Wizard, que permite importar la definición del servicio que se desea consumir. Se debe indicar el WSDL del mismo, y el utilitario definirá los tipos de datos necesarios para poder consumirlo desde GeneXus. En el caso de que el Web Service utilice tipos de datos estructurados, los mismos serán agregados a la base de conocimiento al importar la definición con el WSDL Inspector. Además, es necesario configurar la propiedad de objeto Location. Esto servirá luego para configurar, en los objetos GeneXus que vayan a invocar al Web Service, la ubicación del mismo (host, port, etc.). 277

5 Web Services en GeneXus Procedimiento SOAP Procedimiento GeneXus main con la propiedad call protocol = SOAP Archivo WSDL generado automáticamente El Servidor es un Procedimiento GeneXus con Call Protocol = SOAP. Por la naturaleza del protocolo SOAP los programas generados con GeneXus pueden ser invocados por cualquier cliente SOAP no generado por GeneXus. La información acerca de cómo invocarlo se encuentra en el archivo WSDL (Web Services Description Language) que es generado automáticamente. Dicho archivo se obtiene pasándole el parámetro WSDL a la URL del servicio. 278

6 Web Services en GeneXus Manejo de errores Comportamiento frente a un error Si al hacer un llamado SOAP desde un objeto GeneXus se produce un error, normalmente la ejecución del llamador se cancelará mostrando el error que ocurrió. Si el objeto llamado es un Procedimiento o Reporte GeneXus, es posible indicar que se detenga la ejecución de los programas llamadores en caso de fallar la llamada. Esto se hace mediante la propiedad Cancel Caller Execution on Error : Esta propiedad se habilita solamente cuando la propiedad Call Protocol tiene el valor SOAP. El valor por defecto es Yes. De tener valor No, la ejecución no se cancelará y se podrá obtener el código numérico de error con la función GetSOAPErr(), y el mensaje de error mediante la función GetSOAPErrMsg(). 279

7 Definición del consumidor de un Web Service Objetos Externos Paso 1: Indicar la URL del Web Service que se quiere utilizar. Los external objects permiten acceder a recursos externos a la KB, como si fuesen un objeto interno de la misma. Estos objetos externos pueden ser clases nativas del lenguaje, assemblies, Enterprise Java Beans, stored procedures, o Web Services. Un external object se puede crear manualmente (a través del diálogo "New Object") indicando cada propiedad y método, o se puede usar un Wizard para facilitar el trabajo. El wizard a usar depende del tipo de External Object, en el caso particular de los Web Services, es el WSDL Import Wizard. Los external objects (EO) del WSDL de un servicio permiten agregar referencias del mismo en la base de conocimientos. Los EO almacenan toda la información relacionada al webservice (nombre, propiedades, métodos, parámetros, etc), requeridos para invocar los métodos de dicho web service. Por más información consultar:

8 Definición del consumidor de un Web Service Objetos Externos Paso 2: Indicar el nombre que se le dará al External Object, su descripción, carpeta de ubicación y prefijo. 281

9 Definición del consumidor de un Web Service Objetos Externos Paso 3: Una vez descubierto el Web Service, presionamos Import para importarlo. 282

10 Definición del consumidor de un Web Service Objetos Externos Paso 4: Una vez importado el Web Service, vemos el objeto externo y sus propiedades (View/Properties o F4 sobre el Objeto Externo). 283

11 Definición del consumidor de un Web Service Objetos Externos Para conocer la estructura del WS, damos botón derecho sobre el mismo y seleccionamos Open Part / Structure: Conocemos los parámetros 284

12 Definición del consumidor de un Web Service Objetos Externos Para consumir el WS definimos una variable basada en el tipo de dato CountryInfoService y luego invocamos al método CapitalCity: 285

13 Web Services Locations Para permitir configurar invocaciones a objetos main GeneXus en forma remota. Se pueden hacer usando el tipo de datos Location de GeneXus o el archivo location.xml. Instancias para configurar los locations: 1. En tiempo de generación: mediante location.xml 2. En tiempo de ejecución mediante un archivo: location.xml 3. En tiempo de ejecución mediante código: utilizando variables tipo Location Cuando en el contexto de GeneXus se habla de Location, puede referirse a 2 conceptos: Location de un objeto en 3 capas (propiedad Location a nivel de objeto y propiedad de modelo MultiTier Location) Location de algo accedido via HTTP: puede ser location de un objeto GeneXus (propiedad Location de un objeto con call protocol SOAP o HTTP) o de un web service externo. A un objeto GeneXus con call protocol SOAP o HTTP, se le puede configurar la propiedad Location. Se trata simplemente de un nombre, un string identificatorio / una indirección. Para invocar un objeto GeneXus main SOAP, usando call(), se le debe configurar un Location y además resolver la indirección: Es decir, especificar de alguna forma cómo acceder objetos de ese location; en otras palabras, configurarle host, port, baseurl, datos de autenticación y proxy. Los web services externos, importados, también tienen su Location. El nombre en este caso es predefinido por GeneXus. Es imporante saber entonces cómo configurar un location. Los locations se pueden especificar de varias formas: Con un location.xml o con el Location Data type, o incluso en grupos. Más información:location.xml o Location Data type:

14 En conclusión, a través de los locations, se busca permitir configurar las invocaciones a objetos main GeneXus en forma remota, cuando se utilizan diferentes protocolos, por ej. llamadas vía SOAP. Dichas configuraciones se pueden hacer tanto usando el tipo de datos Location de GeneXus como el archivo location.xml. Instancias para configurar los locations: 1) En tiempo de generación. Mediante el archivo location.xml, ubicado en el directorio raíz de la base de conocimiento y cuya estructura es descripta más abajo. Este archivo debe ser creado por el usuario GeneXus. 2) En tiempo de ejecución, mediante un archivo. Mediante el archivo location.xml, ubicado en el directorio corriente durante la ejecución del programa que invoca al main. Este archivo debe ser creado o editado por el usuario GeneXus. 3) En tiempo de ejecución, mediante código. Mediante variables de tipo Location, cuya estructura es descripta más abajo. Es decir que las propiedades especificadas en tiempo de ejecución mediante código tendrán preferencia sobre las especificadas en tiempo de ejecución mediante un archivo y éstas a su vez tendrán preferencia sobre las especificadas en tiempo de generación para permitir mayor dinamismo en la configuración de los locations. Propiedades Se describen a continuación las propiedades disponibles para describir el location en el archivo XML: Propiedad Subelemento XML Tipo Protocolo Host Host Character HTTP Port Port Numeric HTTP BaseURL BaseURL Character HTTP Secure Secure Numeric (0 1) HTTP Timeout Timeout Numeric HTTP Authentication Authentication Numeric (0 1) HTTP AuthenticationMethod Authentication Method Numeric HTTP AuthenticationRealm Authentication Realm Character HTTP AuthenticationUser Authentication User Character HTTP AuthenticationPassword Authentication Password Character HTTP 287