SEGMENTACIÓN EN DISEÑO DE .WSDL

Todos sabemos que la importancia que tiene en el ciclo de vida SOA la interface .WSDL, esto debido a que es el 'Description Language' de los Web Service y porque es el punto de acceso expuesto para la comunicación entre todos los servicio de tipo Web Service.

Debido a ello, es importante que durante la etapa de diseño uno se dé el tiempo debido en diseñar un correcto archivo .WSDL, de preferencia ya sea por medio de una herramienta o si se tiene práctica a mano, pero definir un buen diseño, considerando el posterior Topdown que se realizará.

En esta oportunidad mostraré como crear un .WSDL basado en un diseño segmentado "no común", pero altamente recomendado en los escenarios en que se requiere definir un .WSDL con gran cantidad de capacidades (operaciones) dentro de este.

Los modelos clásicos para diseñar un .WSDL (v1.1) son los siguientes:

 _ Un solo archivo .WSDL que contenga todo en su interior: (types (complexType, simplexTypes), message, portType, binding, service).  

_ Un archivo .WSDL que contenga en su interior: (message, portType, binding, service) y un archivo .XSD que contenga en su interior: (types (complexType, simplexTypes) ). El .WSDL import ó include el .XSD.  

_ Un archivo .WSDL que contenga en su interior:  (message, portType, binding, service), un archivo .XSD que contenga en su interior el modelo de datos propio de todas las operaciones: (types (complexType) ), un archivo .XSD que contenga datos 'genéricos' entre todas las operaciones. (types (complexType, simplexTypes) ). El .WSDL import ó include el .XSD propio y este import el .XSD genérico. 

Estos modelos de diseño de .WSDL son los conocidos y según el orden van mejorando el diseño propiamente. Así mismo, existe un modelo aún mejor pero que no es tan aplicado, este modelo de diseño se basa en segmentar la interface .WSDL de las operaciones en sí, haciendo que cada operación maneje su propio .WSDL y que exista un .WSDL principal. En otras palabras el diseño sería de esta manera:

_ Un archivo .WSDL (principal) que contenga en su interior:  (portType, binding, service), varios archivos .WSDL (según el número de operaciones existente) que contenga en su interior:  (message y types (complexType) propios de la operación), un archivo .XSD que contenga datos 'genéricos' entre todas las operaciones. (types (complexType, simplexTypes) ).  El .WSDL principal import todos los .WSDLs según el número de operaciones existentes y cada uno de estos .WSDL secundarios import  el .XSD genérico.

La ventaja de este modelo de diseño de .WSDL, es que está enfocado en las operaciones y hará al momento del Topdown respectivo que las clases .java (por ejemplo), se autogeneren en directorios independientes por cada operación respectivamente. Esto hará que no exista riesgo en el problema clásico de la duplicidad de clases usadas por cada operación al momento del Topdown:

La relación entre archivos es a nivel de NameSpace, debido a ello es bueno que se defina un correcto estándar en lo relacionado a los nombres, ya que en base a esta definición, se creará el orden de los directorios luego del Topdown respectivamente. Así mismo, todo lo demás es un juego de imports entre los archivos definidos:

- Archivo .WSDL (principal):

- Archivo .WSDL secundario por operación (Operación#1):

- Archivo .WSDL secundario por operación (Operación#2):

- Archivo .XSD genérica: 

Para los interesados en utilizar este tipo de modelo de diseño de .WSDL, pueden descargarlo desde aquí: http://www.mediafire.com/download/8nl9nuv6tmnpqr9/DisenioSegmentado_Wsdl.zip

ANÁLISIS SOA: [TOP-DOWN / BOTTOM-UP]

En muchas empresas NO se les da la importancia debida al trabajo del Rol: 'Analista SOA', es más en muchas empresas este Rol ni exíste. Este es un error grave, ya que la tarea que realiza dicho Rol es en si la base de toda Arquitectura SOA, debido a que el resultado de dicho análisis ('modelado y arquitectura orientada a servicios') que estos profesionales hagan, definirá los 'Servicios Candidatos' que posteriormente se verán reflejados como base en el Inventario de Servicios (con relación a los ‘servicios compuestos’).

Cuales son las consecuencias de un incorrecto Análisis SOA: que los servicios base en el inventarios de servicios NO sean altamente reutilizables (en muchos casos NI existen), que exista rebundancia constante a nivel de codificación en los procesos, que se creen servicios compuestos por crear, problemas con la gobernanza y el posterior mantenimiento de cada servicios, etc. Y lo peor es que el impacto es incremental a media que el inventario de servicios va creaciendo.

Actualmente, existen algunos enfoques SOA (ejemplo: SOMA y MSOEM) que definen un conjunto de técnicas para identificación de 'Servicios Candidatos'. Dichas metodologías SOA, tienen muchas cosas en común, ya que existen entre los resaltantes dos caminos posibles: TOP-DOWN y BOTTOM-UP.

- Técnica BOTTOM-UP:  

La cual se enfoca en realizar un análisis, para la obtención de los servicios candidatos, partiendo de  las aplicaciones y/o sistemas legacy (antíguas) ya existentes en los cuales los procesos de negocio no están definidos.

- Técnica TOP-DOWN:

La cual se enfoca en realizar un análisis, para la obtención de los servicios candidatos, partiendo de los procesos de negocio (si no se tienen estos, deben ser obtenidas del Feedback de los 'Analistas Funcionales' y modelando los BPMN respectivos). Descomponiendo dichos áreas funcionales, en proceso de negocio en  hasta llegar a procesos, subprocesos y tareas. Es importante recalcar que esta técnica descompone los elementos del nivel más bajo de la granularidad.

Así mismo, se debe tener en claro que todo el proceso de negocio tarde o temprano tenderá a ser un TOP-DOWN (es recomendable), de lo contrario no se llegara a una Arquitectura SOA ideal, donde IT esté alineado al negocio.

Por otro lado, se debe tener claro que este enfoque de análisis debe ser iterativo, ya que no se debe de querer hacer desde el inicio TODA la descomposición del total de los procesos existentes en la empresa. Es recomendable hacerlo por partes, en base a los procesos principales a medida que los requerimientos vayan saliendo. Esto debido a que los servicios serán altamente modificables y apuntan a la reutilización, por lo que se debe analizar por partes los procesos de negocio de la empresa, para definir y formalizar los primeros Servicios Candidatos base del Inventario de Servicios. 

Finalmente, para su posterior investigación los enfoques más resaltantes actualmente son:

- SOMA (IBM).
- MSOAM (Thomas Erl).

Particularmente, prefiero la segunda, pero se pueden complementar.

DINAMIC PROXY CLIENT WS

En esta oportunidad comentaré sobre cómo consumir Servicios Web de manera dinámica.

En proyecto donde el paradigma de la orientación a servicios es aplicado, es imprescindible para la comunicación entre servicios la generación de un Proxy Client del servicio Provider dentro de la aplicación consumidora (Consumer). Para cumplir esto existen actualmente muchas apis en JAVA que facilitan dicho manejo, tanto para generar el servicio (TopDown), como para consumirlo. Entre estas apis JAVA existan: Axis1, Axis2, JaxWs, JaxRpc, etc. Estas apis permiten mediante el TopDown aplicado generar las clases y objetos JAVA siguiendo la estructura de Wsdl/Xsd para poder hacer Get/Set de los datos según convenga.

Esto es bueno pero y estándar, pero existe una transformación detrás de este manejo. Por otro lado, es bueno saber que estas apis facilitan el manejo siempre y cuando la estructura de diseñada del WS, no sea compleja, ni dinámica. Esto se menciona ya que en algunas ocasiones debido una alta complejidad en la estructura (Request/Response), seguridad, etc del servicio provider, es necesario manejar un proxy client de manera dinámica.

Para estos escenarios es bueno conocer que se puede crear un Proxy Client dinámico, que se adapte a cualquier escenario que el negocio requiera y armar los Request. Así mismo, para obtener los datos del Response por más compleja que sea la estructura de respuesta, en vez de manejar un api Jaxb (transformación), nos podemos apoyar en "XPath" ..., ya que por medio de este lenguaje de expressions podremos navegar entre las estructuras XML del Response de una manera muy veloz y potente.

El dummy preparado permite mostrar todo lo mencionado anteriormente.

1. Desplegamos un WS, median un Mock en SOAPUI y así simular un WS Provider:

2. Definir los métodos que servirán para el procesamiento Rquest/Response y el Main que simulará el lanzamiento:

3. Se debe mapear diferentes puntos propios del servicio: URL, Namespace, ServiceName, PortName, TimeOut, etc:

4. Se definen los métodos: procesarRequestWS y procesarResponseWS:

5. Se arma el Request XML, independientemente de la estructura y/o complejidad que se tenga (esta puede está incluso mapeada en .properties y ser reutilizada):

6. Aquí se muestra el poder de XPath para obtener los datos de la cadena XML Response, independientemente que sea un dato y/o lista, se debe entender que todo en si son cadenas y se pueden manipular y obtener como tales por medio de las sentencias XPath propiamente:

7. El resultado de la prueba y consumo respectivo se muestra en LOGs:

Con esto espero haber demostrado comoconsumir dinámicamente un WS, sin usa una sola api adicional, todo apoyandonos en las librerias del JDK, así mismo como el apoyo del poderoso XPath ...!

Para los interesados, se puede descargar las fuentes del dummy aquí:
http://www.mediafire.com/download/ctbw2389i8dabaf/DummyDinamicProxyWs.zip

WSDL 1.1 vs WSDL 2.0

Desde el 2007 la (W3C), como consorcio internacional para el desarrollo de estándares Web, publicó lo que se conoce como el futuro y mejorado estándar para servicios, el estándar WSDL 2.0.

Esta versión nueva de WSDL 2.0 maneja varias diferencias y mejoras con relación a su antecesora y aún estándar WSDL 1.1, que son las siguientes:

• El WSDL 2.0 integra el elemento Message dentro del elemento Types, con relación al WSDL 1.1. 
• El WSDL 2.0 renombra el elemento PortType como Interface, con relación al WSDL 1.1. 
• El WSDL 2.0 renombra el elemento Port a Endpoint, con relación al WSDL 1.1. 
• El WSDL 2.0 renombra lo parte inicial de declaración en la interface conocida como Definitions como Description, con relación al WSDL 1.1. 
  

 

 

El modelo WSDL 2.0 también impone restricciones semánticas más allá de la conformidad estructural. Con el fin de describir con precisión estas limitaciones, y como ayuda para definir con precisión el significado de cada documento WSDL 2.0, la especificación WSDL 2.0 define un modelo de componentes como una capa adicional de abstracción por encima del conjunto de información XML. El siguiente diagrama ofrece una visión de los componentes de WSDL 2.0 y su herencia.

Esta nueva estructura del modelo WSDL es más amigable, mejor diseñada y entendible. Así mismo, lo resaltante de esta versión de WSDL 2.0 es que permite a los desarrolladores elegir el modelo de desarrollo de aplicaciones de Servicios: HTTP o SOAP. Esto debido a la creciente popularidad del modelo REST y SOAP.Con respecto al HTTP, se reconoció la clara necesidad de la compatibilidad con HTTP en las descripciones de aplicaciones Web (contratos). Por tanto, el WSDL 2.0 ofrece una compatibilidad absoluta con HTTP y SOAP, lo que lo hace muy útil tanto para aplicaciones Web sencillas, como para aplicaciones de Servicios Web que requieran de funcionalidades adicionales.

Lo desagradable es que actualmente hasta la fecha, esta versión de WSDL 2.0, no se ha vuelto aún estándar, debido a ello herramientas muy conocimiento como lo son: SOAPUI, ORACLE, IBM y apis como JAXWS aún NO lo soportan, teniendo conocimiento que el único que si lo soportar es AXIS2. Esto quiere decir que seguiremos usando como estándar para nuestros desarrollos el WSDL 1.1 por algo más de tiempo.Finalmente, los que desee actualmente existe un conversor de WSDL 1.1 a WSDL 2.0 (http://www.w3.org/2006/02/WSDLConvert.html), para que se alguna manera, para los que no se acostumbran aún, de esta manera les sea más fácil la transición al nuevo futuro estándar.

SOA vs MICROSERVICIOS

En esta oportunidad complementaré la idea de este muy bueno artículo hecho por: Andrés Hevia

http://pensandoensoa.com/2015/10/25/a-vueltas-con-los-microservicios-y-soa/, dando mi punto de vista sobre este tema tan controversial del cual se habla este último tiempo.

En si NO se debe de confundir lo que es SOAP con WS-*, ya que SOAP (Simple Object Access Protocol), es un protocolo de comunicación estándar para mensajería apoyado por la W3C como un modelo distribuido. Por otro lado, WS-* es un protocolo definido por OASIS orientado al desarrollo y la adopción de estándares. Dichos estándares son comúnmente implementados por los Vendors (ORACLE, IBM) en sus herramientas, así como en apis OpenSource.

Ahora, en si una de las diferencias que comúnmente se menciona es que SOA en su implementación debe ser desarrollada con Web Service específicamente y por otro lado, MicroServicios debe ser implementado con servicios RestFul basado en arquitectura REST. En mi opinión está mal ya que se en un proyecto SOA las implementaciones deben ser orientadas a servicios (NO Web Service), esto quiere decir que dichos servicios pueden también ser considerados de tipo RestFul, NO hay problema con ello.

Por otro lado, la gran diferencia entre ambos es que una de las características de SOA es que es recomiendable como patrón, el usar un ESB para la comunicación, seguridad, transformaciones, eliminaciones de conexiones punto a punto, etc, entre los servicios de manera desacoplada, en sí que sea la columna vertebral de las soluciones SOA. Por otro lado, MicroServicios NO manejan la visión del manejo del ESB, ellos de apoyan en lo que se denomina API Gateway que proporciona un punto de acceso central para administrar, enrutar, supervisar y asegurar el acceso a servicios expuestos públicamente.

Finalmente, desde mi punto de vista veo que un API Gateway no es un sustituto de un ESB, sino más bien una mejora para la implementación de una Arquitectura Orientada a Servicios (SOA).

SOAP FAULTs vs ERROR CODE

Todos los que tenemos conocimiento y hemos trabajado con servicios sabemos que para llevar a cabo un proyecto SOA es requerida la aplicación del paradigma de la orientación a servicios, en nuestros desarrollos. Ahora es necesario, durante la implementación de estos servicios, seguir una serie de principios que ayudarán para estandarizar con buenas prácticas dichas implementaciones. Justamente el primero y más importante principio SOA, habla sobre la ''Creación de Contrato de Servicio Estandarizado", durante la definición de dicho contrato a nivel de Web Service (.wsdl), surge una gran duda que es abordada en este post, esta es cómo manejar el control de errores: con 'Soap Faults' o con 'Error Code' personalizados.

Las Excepciones y Fallos a nivel de servicios se utilizan para comunicar los errores dentro del servicio o para comunicar errores a través de límites de servicio. Por ejemplo, el protocolo HTTP utiliza códigos de estado como 404, que indica el problema a nivel de URL (No disponible). Así mismo, es importante considera lo que son excepciones por Timeout, excepciones al momento de consumir alguna BD y/o servicios que forman parte del servicio compuesto, etc.

Hay que tener en cuenta al lanzar una excepción, que se tiene que permitir a las aplicaciones consumidoras identificar la excepción y/o problema sucedidos, para que estos puedan estas interpretar y reaccionar adecuadamente a la excepción. Así mismo, debe de proporcionar información suficiente para que dicha aplicación y/o servicio (dentro del flujo compuesto), pueda entender lo que salió mal y definir cómo controlarlo.

A nivel de Web Service se pueden solucionar este problema de dos formas con Soap Faults ó con Error Code personalizados.

I. SOAP FAULTs:

Este es el modo de control de errores provisto dentro del .wsdl, para el manejo de cualquier tipo de problema dentro del servicio. La falla es registrada dentro del cuerpo elemento de un servicio web. Así mismo, para su manejo debe ser creado un tercer elemento menssage de tipo Fault dentro del PortType:

[fault message="tns:MissingName" name="NombreObjetoError" /]

Actualmente, existen en base al tipo de SOAP utilizado: (SOAP:1.1 ó SOAP:1.2), que manejan estructuras de falla diferentes por versión respectivamente.

SOAP 1.1:
 [SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"]
   [SOAP-ENV:Header/]
     [SOAP-ENV:Body]
         [SOAP-ENV:Fault]
            [faultcode]SOAP-ENV:Client[/faultcode]
                    [faultstring]INFORMACION DEL PROBLEMA[/faultstring]
                    [faultactor]http://gizmos.com/order[/faultactor]
            [detail]
                        [PO:order xmlns:PO="http://gizmos.com/orders/"]AQUÍ DETALLE COMPLETO DEL PROBLEMA[/PO:order]
                    [/detail]
           [/SOAP-ENV:Fault]
     [/SOAP-ENV:Body]
 [/SOAP-ENV:Envelope]

SOAP 1.2: 
[env:Envelope xmlns:env="http://www.w3.org/2003/05/soap-envelope"]
  [env:Header/]
  [env:Body]
    [env:Fault]
      [env:Code]
         [env:Value]env:Sender[/env:Value]
      [/env:Code]
      [env:Reason]
         [env:Text xml:lang="en-US" ]INFORMACION DEL PROBLEMA[/env:Text]
      [/env:Reason]
      [env:Role]http://gizmos.com/order[/env:Role]
      [env:Detail]
         [PO:order xmlns:PO="http://gizmos.com/orders/"]AQUÍ DETALLE COMPLETO DEL PROBLEMA[/PO:order]
      [/env:Detail]
    [/env:Fault]
    [/env:Body]
[/env:Envelope]


II. ERROR CODE:
Consiste en NO manejar los message de tipo Fault dentro del PortType (Input message y Output message), y definir un estándar a nivel de .xsd (ComplexType), con los parámetros de control de errores: CodError, MsjError, donde se estandarizarán los controles de error mencionados (No disponible, TimeOut, BD, etc), ya sean de tipo Técnicos ó Funcionales (negocio). Así mismo, estos cuando se ejecuten serán controlados en la implementación del servicio e identificados por tipo de excepción, y  retornados a la aplicación consumidora en el mismo elemento: Output message (CodError, MsjError). Esto facilitaría la identificación de la falla del servicio para el cliente (transparente). 

Recomendación:

Muchos estarán a favor del manejo por Soap Faults y otros por el manejo por Error Code personalizados. Desde mi punto de vista, he trabajado con ambos formas de control y procederé a dar mis comentarios y puntos de vista:

En lo relacionado a Soap Faults, el manejo facilita el desarrollo del lado de la implementación del servicio, ya que uno como desarrollador se olvidaría un poco del control de excepciones, debido a que ante una falla, esta será lanzado por el: fault message. Por otro lado, este manejo dificulta el control e identificación del error por parte de las aplicaciones consumidoras que tendrán que pelearse con dos estructuras diferentes de Soap Fault (Versión SOAP: 1.1 y 1.2), así mismo como los problemas del lado e algunos Frameworks, que al hacer el Topdown generan problemas para acceder a la parte de Fault a nivel de código.

En lo relacionado a Error Code, el manejo dificulta el desarrollo del lado de la implementación del servicio debido a que se deberá identificar, dentro del servicio, los posibles tipos de errores que puedan generar problemas en el servicio: TimeOut, No disponible, BD, etc, y ser respondidos por el mismo objeto:  Output message. Por otro lado, este manejo facilitaría haciendo transparente el control de errores del lado de las aplicaciones consumidoras, es más se podría definir desde el inicio como parte del documento de especificaciones del servicio los posibles: codError y msjError, para los diferentes escenarios de tipo Técnicos o Funcionales (negocio). Incluso, favorecería la identificación por el lado de los administradores del servidores (a nivel de Logs).

Finalizando, solo me queda mencionar que se ha tratado de detallar datos importante, en base a experiencia en el manejo, de estas dos modalidades existentes para el Control de Errores a nivel de Web Service. De su lado, ya queda tomar nota y ver que manera de adecúa mejor a la implementación en su negocio (proyectos).

CENTRALIZACIÓN DE LOG's (SYSLOGs)

En un post anterior comenté sobre lo que es la: Importancia de los LOGs en los Servicios, en esta oportunidad hablaré y mostraré sobre algo importante que está de la mano con este tema, en si es posterior a dicho tema, este es la 'Centralización de Logs'.

La 'Centralización de Logs' como su nombre lo dice es muy importante, ya que si analizamos en un ambiente Prod, existen una gran cantidad de archivos Log que a diario se van generando y creciendo con los procesamientos de los sistemas. Para ello anteriormente también se recomendó una serie de consideraciones a tener en cuenta, sobre lo que debería contener cada Log. Adicionalmente a ello, es recomendable, pensando en proyectos relacionados de SOA, definir por servidor una Ruta Absoluta Fija (por ejemplo: /home/tdp/soa/logs), que contendrá en su interior los directorios con los nombres de los proyectos trabajados (servicios) y dentro de estos directorios se generen Logs de cada servicio. Así mismo, definir a un Operador/Administrador de servidores que sea el encargado de la revisión y mantenimiento de los Logs (ya que estos, dependiendo de los mecanismos que se utilicen para su generación, van creciendo por día considerablemente), debido a ellos dichos Operadores deben velar por el bienestar de los servidores, eliminando Logs de fechas anteriores (por ejemplo cuatro semanas de antigüedad, dependiendo del negocio) a nivel del Servidor y de los Nodos que existan (Cluster), por medio de Script por ejemplo. Esta es una tarea que si no se realiza ordenadamente, definiendo rutas absolutas fijas donde ir a buscar directamente, ante una falla del servicio, puede llevar al caos el identificar problemas existentes.

Justamente, pensando en aligerar un poco esta tarea de identificación de fallas en los servicios, nace el concepto de 'Centralización de Logs', esto consiste en que los sistemas y/o aplicaciones generadoras de Logs, por medio de un mecanismo, lancen sus Logs a un Servidor Central de Logs, estos servidores (Virtuales/Físicos), deberá tener la capacidad de recepcionar los mensajes de Logs enviados y por medio de una consola de administración, el Operador/Administrador será alertado vía emails, así como poder visualizar listado en pantalla los problemas, etc.

En esta oportunidad mostraré una solución para realizar dicha tarea de: 'Centralización de Logs', por medio de 'Log4j Syslog' y 'Kiwi Syslog Server'. Ahora explicando un poco sobre: 'Kiwi Syslog Server', es una solución de pago que trabaja como servidor syslog, brindando características de administración de archivos de registro, fácil de usar para los Operadores/Administradores y los equipos de red, de instalar y configurar, este trabaja con alertas, SNMP, eventos, etc, sobre las plataformas Windows, Linux. Para más detalles del producto visualizar el Video.

I. SYSLOG SERVER (Kiwi):
Lo bueno para el tema de pruebas es que este Syslog Server, maneja su versión Free, que se puede descargar de aquí. 

Un vez descargado se debe de instalar el software que trabajará fijo con Evento permanente instalado en la máquina y que escuchará los mensajes Syslog: SolarWinds_Event_LogForwarder_Setup, luego se debe instalar el Syslog Server como tal: Kiwi_Syslog_Server_9.5.0.Freeware.setup.



Terminada la instalación así se visualizará el: Kiwi Syslog Server:



II. LOG4J (Syslog):
Por medio de Log4j y su integración con Servidores de Aplicaciones como Weblogic ó WAS, uno puede configurar la autogeneración de Logs, en Rutas Absolutas Fijas por Servicio (Justo la primera parte que anteriormente ya se había mencionado y recomendado).

He creado un proyecto JAVA para simular el manejo, configuración y envío de los Logs (mensajes) al Servidor Central por medio de Syslog.

Todo debende de manejar una buena configuración de los Appender de Log4j, mi caso tengo configurado dos Appender, para que tabajen de la mano: 

• org.apache.log4j.net.SyslogAppender:  Para la comunicación con el Servidor Central Syslog.
• org.apache.log4j.DailyRollingFileAppender: Para la generación de los Log en las rutas absolutas fijas definidas.

 

III. TESTING:

El dummy preparado inicia desde Eclipse que mandará el Log a generarse, tanto en la Ruta Absoluta Fija definida, como en el Servidor Central Syslog:

El mensaje será registrado en el archivo Log, del directorio fijo definido.  

Así mismo, se registrará el mensaje en el Servidor Central Syslog, tal como se muestra en imagen.

Esto ayudará el Operador/Administrador, a que tenga más visión de los problemas existentes a nivel de los servicios y aplicaciones desplegadas en el Server.

Una segunda prueba, ya simulando un escenario real a nivel de servicios sería la siguiente:

Se debe configurar de manera similar el archivo log4j.xml que se tiene integrado con Weblogic Server, definiendo el Appender adicional que se deberá manejar para la comunicacion con el Servidor Centra Syslog, posteriormente reiniciamos (Asuminemos que el servicio para pruebas, ya está desplegado).

Desde SOAPUI ejecutamos la prueba del servicio respectivo y configurado:

Este lanzamiento registrará, la traza real del servicio en el archivo Log del servicio, generado en la Ruta Fija absoluta.

Así mismo, el mismo mensaje se registrará en el Servidor Central Syslog (Kiwi) de Logs.

 

Finalmente, solo que me queda mencionar que se ha tratado de mostrar uno de las tantas maneras y mecanismos que existen para la 'Centralizacion de Log', un poco más orientado a entornos SOA.

Para los interesados pueden descargar el Dummy del proyecto Log4jSyslog desde aquí: http://www.mediafire.com/download/ysjeyglklk8sa89/LoggerSyslog.zip