Tag Archives: .net 4.0

WCF: Auditar errores a nivel de servidor


Windows Comunication Foundation (WCF) fue la evolución lógica de los antiguos Web Services de .NET 2.0 dotando a estos de multiples mejoras.

Aunque hoy en día se ha convertido en el estandar de uso para el desarrollo de servicios webs centralizados en .NET hay algunas cosas que Microsoft no terminó de pulir o complicó más de la cuenta.

Una de ellas es la captura de excepciones que ocurran en el servidor que aloja el WCF cuando es invocado desde un cliente en concreto y en este pequeño artículo vamos a explicar como configurar el servicio WCF para que audite los errores ocurridos.

 

Las típicas excepciones a nivel de cliente como “An unsecured or incorrectly fault error” o “An error occurred when verifying security for the message” realmente esconden el verdadero motivo del error y el único modo de saberlo es indicarle al servicio WCF que inserte en el Visor de Sucesos de Windows los detalles de la excepción usando “Service Security Audit“.

Para ello necesitaremos modificar el Web.Config añadiendo en el tag <behavior> el tag <serviceSecurityAudit> como en el ejemplo:

<behaviors>
      <serviceBehaviors>
        <behavior name="ServiceBehavior">
<serviceSecurityAudit auditLogLocation="Application" serviceAuthorizationAuditLevel="Failure" messageAuthenticationAuditLevel="Failure" suppressAuditFailure="true"/>
        </behavior>
      </serviceBehaviors>     
    </behaviors>

Los parámetros de “serviceSecurityAudit” son:

  • auditLogLocation:
    • Define dónde se almacenará el log del WCF.
    • Tipos:
      • Default
        • Los eventos se escriben en el Visor de Sucesos.
      • Application
        • Los eventos se escriben en el Visor de Sucesos de “Application”
      • Security
        • Los eventos se escriben en el Visor de Suscesos de “Security”
  • serviceAuthorizationAuditLevel y messageAuthenticationAuditLevel
    • Indica si se van a auditar los eventos de autorización y autenticación respectivamente contra el WCF.
    • Tipos:
      • None
        • No se almacena nada.
      • Success
        • Sólo las peticiones exitosas.
      • Failure
        • Sólo los errores.
      • SuccessAndFailure
        • Se almacena todo.
  • suppressAuditFailure
    • Valor booleano que indica si se ignoran o no las posibles excepciones que ocurran al intentar escribir en el log (la típica excepción guardando la excepción). Por defecto si se falla al intentar guardar la excepción esta es capturada e ignorada.
 
Si, como en mi caso, queremos saber solo cuando falla basta con que pongamos los valores a “Failure” y tendremos una entrada en el Event Viewer de nuestro servidor con el texto completo y real de la excepción.

 

IMPORTANTE: Activar el Service Security Audit reduce considerablemente el rendimiento del servicio WCF. Mi recomendación es que se desactive si ya has resuelto el error o si no necesitas auditar nada más.

 

Espero que este pequeño tutorial os ayude a encontrar esos horribles errores ocultos en vuestros servicios WCF.

 

Nos vemos Compilando!!

Creando la capa de datos: Entity Framework vs LINQ to SQL

Una de las cosas que más interés me ha generado durante mi vida como desarrollador es como conseguir una buena capa de persistencia, consistente, flexible y transparente para el nivel de aplicación sin mezclar consultas sql’s o crear manualmente clases que repiten funcionalidad y datos.

He trabajado con varias herramientas, desde las más rudimentarias clases estáticas con métodos que ejecutaban sql “a pelo” hasta clases generadas a mano que por debajo usaban una instancia de DataRow (que por cierto no es serializable y no se puede usar con servicios WCF); hasta que en el framework 4.0 de .NET se incluyó el Entity Framework (EF) y LINQ to Entities.

 

Pero antes, un poco de historia:

Ya en la versión 3.5 de .NET nuestros amigos de Redmond incluyeron una nueva herramienta de O/RM (object relational mapping) conocida como “LINQ to SQL”. Con LINQ to SQL podíamos modelar una base de datos relacional con clases .NET de forma automática lo que nos permitia seleccionar, editar, insertar o eliminar datos tan solo editando las clases y colecciones generadas.

Para poder trabajar con estas clases se añadió soporte para lenguaje “LINQ” (Language Integrated Query) que no es más que un modo de expresar consultas similares al sql normal contra cualquier colección (ya sea generado por el modelador de LINQ to SQL o bien creada manualmente). LINQ incluye tipado, comprobación de las consultas en tiempo de compilación, expresiones lambda y tipos anónimos e intellisense lo que lo convierte en un lenguaje para consultas mucho más potente que el sql clásico.

Con estas dos herramientas juntas podemos obtener una serie de clases generadas automaticamente de una base de datos y trabajar con ellas manipulando datos sin necesidad de escribir una sola linea SQL.

 

Más adelante, con la versión 4.0 de .NET se incluyó ADO .NET Entity Framework y su LINQ to Entities que ofrecía una nueva forma de modelar bases de datos en entidades de forma automática más compleja y flexible pero con un funcionamiento básicamente similar ya que también se trabaja mediante consultas LINQ.

 

Visto esto os preguntareis: “Pues tiene buena pinta pero…¿qué diferencias existen entre LINQ to SQL y Entity Framework?

Aunque son casi lo mismo LINQ to SQL y EF han tenido vidas paralelas y, hoy en día, EF se ha impuesto de manera aplastante. La gran diferencia es que LINQ to SQL se creó con la finalidad de ser un RAD (Rapid Application Development) por lo que se dejaron alguna cosas en el tintero que se solventaron con EF:

  • LINQ to SQL sólo permite conectarse a SQL Server y ser usado en C# o VB.NET. EF en cambio soporta varios proveedores como MySql, Oracle, SQL Server, XML, etc…
  • LINQ to SQL mapea cada tabla/vista como una clase o “entidad” sin permitir herencia, entidades lógicas o entidades de negocio. EF lo implementa completamente.

 

Como veis Entity Framewok está preparado para modelar la capa de datos de una forma más generica y flexible lo que nos permite abordar proyectos de mayor envergadura aunque si lo que buscamos es una forma rápida de modelar nuestra base de datos SQL SERVER y no necesitamos grandes florituras LINQ to SQL nos valdría perfectamente.

En futuras entradas explicaré de forma más practica como modelar una base de datos y como hacer las típicas consultas (Select, Insert, Update, Delete) con Entity Framework.

 

Nos vemos Compilando!