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).
No hay comentarios:
Publicar un comentario