PROTOCOLO SOAP

Introduccin
SOAP es un protocolo liviano basado en XML, para invocar procedimientos en forma remota (Remote Procedure Call). Utiliza cualquier protocolo que permita transportar mensajes de texto, siendo HTTP el ms utilizado. Su especificacin describe el contenido que debe tener un mensaje XML para ser usado en una invocacin remota. Cualquier aplicacin que cumpla la especificacin puede invocar y proveer servicios sin importar en que lenguaje o plataforma est implementado, lo nico necesario es que la aplicacin sea capaz de interpretar el mensaje SOAP que recibe, realizar el procesamiento que el mensaje requiera, y devolver otro mensaje SOAP con la respuesta. En las aplicaciones generadas por GeneXus se utiliza SOAP para invocar a objetos en forma remota, usando HTTP como protocolo de transporte.

Alcance
Objetos llamadores (Clientes)
Objetos: Todos los objetos Lenguajes: C/SQL - Java - Visual Basic Visual FoxPro C# Interfaces: Win/Web Los objetos llamadores son los que invocan servicios mediante SOAP

Objetos llamados (Servidores)

Objetos: Procedimientos y Reportes Lenguajes: C/SQL - Java - Visual Basic C# Interfaces: Web Los objetos llamados son los brindan un servicio invocado mediante SOAP

Descripcin
Algunas de las ventajas de utilizar este protocolo en aplicaciones GeneXus son la posibilidad de desarrollar servicios web, asi como el poder hacer invocaciones entre objetos de diferentes generadores (por ej. llamar desde Visual Basic a Java, o desde C/Sql a Visual Basic), funcionalidad que no estaba permitida en versiones anteriores, excepto llamadas RPC desde los generadores visuales a los generadores CSql/Cobol/RPG.

Servidor
Para indicar en GeneXus que un objeto main va a ser llamado utilizando el protocolo SOAP, se deber seleccionar el valor SOAP en la propiedad

Options/Call Protocol. Nos referiremos en adelante a dichos objetos como Servidores o Servicios web. Solo pueden ser reportes o procedimientos, sin ningn tipo de interfaz con el usuario. Se requiere un servidor Web que haga el hosting de los servicios a ser invocados. Los programas Servidores reciben la invocacin http, procesan el mensaje SOAP que enva el Cliente con sus parmetros, realizan la accin requerida, y generan otro mensaje SOAP de respuesta (eventualmente con los parmetros modificados).

Cliente
Los objetos que van a invocar al servicio web, a los que llamaremos Clientes, pueden ser cualquier objeto GeneXus. La invocacin se hace con el comando call() de GeneXus. Los programas Clientes realizan las tareas necesarias para ensamblar el mensaje SOAP, hacer la invocacin http, y desensamblar la respuesta, obteniendo los parametros modificados en forma automtica. Todo esto se realiza en forma automtica y transparente para el usuario.

Locations
Para indicar cual va a ser la ubicacin de los servicios invocados se utiliza un esquema conocido como Locations.

Manejo de errores
Comportamiento frente a un error
Si al hacer un llamado SOAP desde un objeto GeneXus se produce un error, normalmente la ejecucin 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 ejecucin 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 ejecucin no se cancelar y se podr obtener el cdigo numrico de error con la funcin GetSOAPErr(), y el mensaje de error mediante la funcin GetSOAPErrMsg().

Cdigos de error en el cliente

Los posibles cdigos de error que pueden ser retornados mediante la funcin GetSOAPErr() son los siguientes: 0: Operacin completada con xito. Mayor que 0 y menor que 10000: Algn parmetro retornado por el servidor no tiene el nombre esperado. El cdigo de error indica la posicin del parmetro que ocasion el conflicto. Menor que 0 y mayor que -10000: Sucedi un error al interpretar el XML de respuesta. Suceder por lo general si la respuesta no es XML o no es XML bien formado. Si se toma el valor absoluto del cdigo de error el resultado corresponder a un cdigo de error del objeto XMLReader. De todas formas, getSOAPErrMsg() retornar una descripcin del error. Menor que -10000: Sucedi un error en la comunicacin HTTP. Si se toma el valor absoluto del cdigo de error y se le resta 10000 el resultado

corresponder a un cdigo de error del objeto HTTPClient. De todas formas, getSOAPErrMsg() retornar una descripcin del error. -20001: La respuesta recibida es un XML vlido pero no es un mensaje SOAP vlido. -20004: El servidor retorn que hay un error en el pedido SOAP realizado por el cliente. En este caso getSOAPErrMsg() retornar un mensaje conteniendo el cdigo y el mensaje de error retornados por el servidor. Si el servidor es un procedimiento o reporte GeneXus, retornar alguno de los cdigos de error descriptos ms abajo. -20006: Sucedi un error no identificado. En este caso getSOAPErrMsg() retornar un mensaje conteniendo el cdigo y el mensaje de error retornados por el servidor. -20007: Nombre de location no vlido. Sucede cuando se llama a la funcin GetLocation(Nombre) con un nombre de location que no est definido para ningn objeto en la KB.

Cdigos de error en el servidor

Un procedimiento o reporte GeneXus que es llamado mediante SOAP puede retornar alguno de los siguientes cdigos de error: -20000: No se recibi un mensaje SOAP. -20001: El mensaje recibido es un XML vlido pero no es un mensaje SOAP vlido (igual que en el cliente). -20002: El mtodo llamado no es el esperado. (El mtodo SOAP de los objetos GeneXus siempre se llama Execute).

Casos
Veremos a continuacin diferentes combinaciones entre Clientes y Servidores, y su implementacin en cada caso:

CLIENTE GENEXUS SERVIDOR GENEXUS

El Servidor es un procedimiento o reporte con Call Protocol = SOAP, el Cliente es cualquier otro objeto de la KB haciendo un call(). La ubicacin del Servidor se configura utilizando el esquema de locations. Los objetos Cliente y Servidor pueden estar generados con diferentes generadores, teniendo en cuenta la seccin Alcance:

Cliente Servidor C/SQL

C/SQL

Java

Visual Basic

Visual FoxPro

(*)

(*)

(*)

(*)

Java Visual Basic Visual Fox

(*) El generador C/Sql adopt el SOAP como protocolo por defecto para las llamadas RPC, por lo que una llamada RPC a un programa C/Sql siempre se va a hacer va SOAP, no importando el generador con el que se genere el objeto llamador (con el valor Internal para la propiedad Call Protocol; en este caso no esta disponible la propiedad Cancel Caller Execution on Error, y cancelar el programa llamador en el caso de que se produzca un error en el programa llamado). Es posible a partir de esta caracterstica hacer llamadas RPC desde programas C/Sql hacia programas generados por cualquier generador que genere servicios SOAP. Por ejemplo es posible llamar desde un objeto main C/Sql a otro objeto main C/Sql, caracterstica no disponible hasta ahora. Un caso particular de lo anterior es si el Servidor es un objeto de otra KB. En este caso es posible invocarlo configurando el location, creando en la KB del Cliente un objeto dummy con el mismo nombre y parmetros que el objeto Servidor, y haciendo un call() a dicho objeto desde el objeto Cliente.

CLIENTE NO GENEXUS SERVIDOR GENEXUS

El Servidor es un procedimiento o reporte 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 informacin acerca de cmo invocarlo se encuentra en el archivo WSDL (Web Services Description Language) que es generado automticamente. Dicho archivo se obtiene pasndole el parmetro wsdl a la URL del servicio, en el ejemplo anterior sera: http://localhost:80/c/sqlsolis/prg/nombredeprograma?wsdl NOTA: Se esta generando dentro del archivo WSDL de los servidores SOAP un elemento <documentation> que incluye el Help del objeto. Esto permite incluir en el WSDL informacin acerca del uso del Servicio, parmetros que recibe, para que sirve, etc. El elemento tiene los siguientes subelementos: <documentation> <URL>Character</URL> <line>Character</line> <line>Character</line>

. . </documentation> En el elemento URL se indica la URL al Help HTML del objeto que se genera. Por mas informacin consultar la documentacin del Help HTML. En los elementos line se genera el Help del objeto. Solo la parte de texto es generada, ignorndose el resto. Se generan lneas con un mximo de 80 caracteres, en caso de que la lnea de Help sea mas larga, se generan tantos elementos line como sean necesarios.

CLIENTE GENEXUS SERVIDOR NO GENEXUS

Si bien el protocolo permite llamar a cualquier servicio SOAP sin necesidad de que este sea un programa GeneXus, por el momento no es posible especificar que un programa externo debe llamarse va SOAP, ni tampoco describir sus parmetros. Igualmente es posible invocar a un servicio web externo utilizando los tipos de datos HttpClient, XmlWriter y XmlReader. Esta disponible un ejemplo en el sitio de GeneXus Open Source.

Consideraciones Generales
No es posible especificar que un programa externo debe llamarse va SOAP, ni tampoco describir sus parmetros. No se esta generando correctamente en el WSDL el Help del objeto cuando se tienen lneas con mas de 75 caracteres, pudiendo truncarse alguno de ellos.

Funciones Principales de un Arquitecto de Software

Me han preguntado recientemente cuales son las funciones de un Arquitecto de Software, termino que me suele hacer rer y que siempre digo que en menor y mayor medida casi todos somos un poco Arquitectos de Software, yo he recopilado estas funciones:

Arquitectura: Definicin de arquitectura de los sistemas, vista fsica, vista lgica, principios de arquitectura, seguridad, etc. Seleccin de Software: Pilas de aplicaciones, bases de datos, libreras, frameworks, estndares tecnolgicos, etc. Seleccin de Infraestructura: Sistemas Operativos, hardware, redes, sistemas de recuperacin, etc. Requisitos no Funcionales: Rendimiento, escalabilidad, seguridad, etc. Liderazgo: Liderazgo Tcnico, responsabilidad y autoridad, direccin de equipos, etc. Coaching y Mentoring: Ayuda sobre problemas tcnicos, ayuda en la evolucin profesional, etc.

Metodologa de Proyectos: Estructura de Proyectos, Metodologas (Waterfall, Scrum, RUP, XP...). Procesos de Desarrollo: Control de versiones de cdigo fuente, procesos de construccin, integracin continua, automatizacin de pruebas y otros procesos y herramientas de desarrollo. Prcticas y Estndares: Estndares de codificacin y libros blancos, seleccin de herramientas, etc. Diseo, Desarrollo y Pruebas: Diagramas UML, codificacin, pruebas unitarias, etc. Experiencia: Conocimiento sobre tecnologas y arquitecturas. Estar al da en cuanto a tendencias tecnolgicas: Agile, Web 2.0, SOA, Lightweight Java EE, etc.

http://geeks.ms/blogs/oalvarez/archive/2009/07/02/funciones-principales-de-un-arquitectode-software.aspx http://www.tec.url.edu.gt/boletin/URL_19_SIS02_COMPETENCIAS.pdf