Autenticación con AgilePoint y el uso de Surrogate (2ª Parte)

En un artí­culo anterior hablábamos de la autenticación con AgilePoint y la surrogación. Echaba en falta algíºn gráfico que dejara algo más clara la forma de trabajar, así­ que lo adjunto en esta segunda parte.

Esquema Surrogate
Esquema Surrogate

Como véis, se aprecian las tres combinaciones de las que se habla en la primera parte.

  • Opción A: Usuario a través de un navegador web, el servidor web tiene que impersonar al usuario llamante.
  • Opción B: Usuario a través de aplicación de escritorio que trabaja contra una capa de servicios, el servidor de negocio tiene que impersonar al usuario llamante.
  • Opción C: Usuario a trvés de aplicación de escritorio que trabaja directamente con servicios de AgilePont, no hace falta impersonación, el propio usuario pertenece al dominio y se autentica directamente con sus credenciales de red.

Pocos artí­culos íºltimamente. Mucho trabajo.
Saludos!
Miguel.

Solid RAD

Recientemente he tenido la oportunidad de participar en una presentación de Solid RAD, la herramienta para el desarrollo rápido de aplicaciones, ofrecida bajo el sello y garantí­a de calidad del equipo de Solid Quality Mentors
Jesíºs López y Daniel Seara (con el cual he tenido nuevamente el placer de coincidir) han sido los dos mentores de Solid que realizaron la presentación de forma conjunta.
A partir de la propia arquitectura y orientación de Solid RAD, la cual podréis conocer consultando el video provisto en el siguiente enlace mms://solidq.com/SolidRad (copiar el link y ejecutar pegando en la barra de dirección de Internet Explorer), destacar la inmensa oportunidad que supone compartir durante parte de una mañana, y de forma directa y personalizada, de los conocimientos y opiniones de los dos mentores. Lo que ha dado una pequeña “discusión” sobre el uso de las transacciones es algo que me gustarí­a exponer en un próximo artí­culo. A mi la visión me ha parecido genial.
Destacar entre otras cosas de Solid RAD, otras ideas fantásticas, como las de partir de un modelo de objetos de negocio para exponer el conocimiento a otras capas, pero sin orientar el modelo de objetos directamente a las entidades de datos, tal como harí­a un ORM, si no a las vistas definidas sobre dichas entidades de datos. Es una idea simplemente genial combiándola al mismo tiempo con el generador de código de Solid RAD, que automatiza la generación de las entidades de transporte de datos a partir de las propiedades de cada una de las vistas sobre la que es accedida.
Saludos.
Miguel.

WCF ServiceDebug – includeExceptionDetailInFaults

“ServiceDebug” es el tag que debe añadirse a la conducta asociada a nuestro servicio de WCF para que publique la descripción del error a los clientes, en el caso de que se produzca algíºn problema a la hora de consumir un servicio.
<system.serviceModel>
  <services>
    <service name=”WCFPolimorfismo.MiServicio” behaviorConfiguration=”miConducta”>
      <endpoint address=”” binding=”basicHttpBinding” contract=”WCFPolimorfismo.IMiServicio”></endpoint>
    </service>
  </services>
  <behaviors>
    <serviceBehaviors>
      <behavior name=”miConducta”>
        <serviceMetadata httpGetEnabled=”true”/>
        <serviceDebug includeExceptionDetailInFaults=”true”/>
      </behavior>
    </serviceBehaviors>
  </behaviors>
</system.serviceModel> 
Saludos.
Miguel.

WCF – Contratos y Enumeradores

Siguiendo con WCF, a continuación os adjunto otra evolución del proyecto de servicios web polimórficos donde se puede observar la creación de un enumerador “PaisEnum” que es visible también desde el cliente consumidor gracias a aplicar en conjunto las etiquetas “DataContract” y “EnumMember”.
Os dejo además la URL del artí­culo que tomé de referencia, donde se amplí­a el uso de estas capacidades:
https://msdn.microsoft.com/es-es/library/aa347875.aspx
Y la solución en Visual Studio 2008 con los enumeradores incorporados:
Enumeradores en WCF
Saludos.
Miguel.

FaultContract – Definiendo Excepciones en WCF

Y es que uno de los principales problemas que nos encontrábamos los desarrolladores de Servicios Web .NET de la versión 2.0, es cómo lanzar las excepciones tipificadas que definí­amos en la capa de negocio para que pudieran ser capturadas desde la capa de presentación.
Para los que os hayáis encontrado ya con el problema, sabréis que toda excepción generada desde un Servicio Web .NET 2.0 llega a la capa de presentación como SoapException… por lo que es imposible tipificar en el cliente cuál ha sido exactamente el error generado por la capa de negocio. Hay algíºn truquillo por ahí­ pasando un XML en la SoapException y leyendo el XML desde el cliente, pero nunca me ha acabado de convencer.
Con la etiqueta FaultContract de WCF el problema ya está resuelto y vamos a ser capaces de definir excepciones en la capa de servicios que pueden ser capturadas desde el cliente. Os adjunto al post la solución de servicios polimórficos que vimos semanas atrás, añadiendo la casuí­stica de la generación de excepciones y captura desde el cliente.
Fijaros entre otras cosas del código situado en Base.DAOException, que es la clase que utilizamos para el transporte de la excepción (atención, no hereda de Exception).
También en el interfaz que expone IMiServicio.cs, que es donde veréis que además del atributo “OperationContract” por cada uno de los métodos, también definimos “FaultContract”, asociado al tipo de excepción que va a ser capaz de lanzar dicho método.
[FaultContract(typeof(Base.DAOException))]
Fijaros en MarcaDAO.Update cómo lanzamos la excepción.
throw new FaultException<Base.DAOException>(new Base.DAOException(ex));
Pero, sobre todo, fijaros cómo se captura en el cliente Form1.cs
catch (FaultException<Servicio.DAOException> ex)
WCF Ejemplo FaultContract
Saludos
Miguel

Saltando de Servicios Web .NET 2.0 a WCF

Hola a todos.
Hace tiempo ya que tení­a pendiente un artí­culo como este, donde se mostraba un ejemplo de evolución de un proyecto realizado con .NET Framework 2.0 y Servicios Web, a un proyecto hecho en WCF (siento el retraso, pero voy muy justo de tiempo ultimamente y casi no puedo avanzar artí­culos para el blog). La idea es que los profesionales que conozcan y estén acostumbrados a trabajar con Servicios Web 2.0, pierdan el miedo a WCF y vean que con cambios muy sutiles podemos reaprovechar el trabajo hecho y migrar a WCF.
Para ello os he preparado una solución que consta de dos proyectos, uno hecho con Servicios Web 2.0 y otro con WCF. El de WCF parte del de Servicios Web 2.0, lo ajusta para su uso en WCF y además aumenta la funcionalidad aprovechando el polimorfismo de WCF (tema que hablamos ya en un artí­culo anterior).
Entre las cosas que me gustarí­a que os fijarais es que en el proyecto de WCF se define un servicio “svc” y que dicho servicio está relacionado a un archivo “.cs” que implementa una interfaz. Esto se ha hecho con los servicios de “venta” y “mantenimiento”. Es obligatorio que cada servicio de WCF implemente una interfaz determinada. En la interfaz empiezan ya a verse atributos especí­ficos de WCF como son “ServiceContract” y “OperationContract”. En cuanto a la capa de acceso a datos, en concreto en los DTO veréis aparecer etiquetas “DataContract”, “DataMember” y “KnowType”.
He añadido como complemento más ejemplos de usos de Polimorfismo en WCF. Como véis hay un servicio llamado “mantenimiento”, el cual llama a la factorí­a correspondiente seleccionando el DAO contra el que va a trabajar en tiempo de ejecución. Como sabéis esto no se puede hacer en Servicios Web 2.0.
Otro tema curioso es cómo se ha implementado el servicio de Venta en cada una de las aplicaciones, como veréis en la solución de WCF el método recibe un IDTO, mientras que como esto no es posible en Servicios Web 2.0, la firma del método cambia.
Ejemplo Transición Servicios Web 2.0 a WCF
Terminar diciendo que el ejemplo ha sido implementado usando como entorno de desarrollo Visual Studio 2008.
Saludos a todos.
Miguel.

¿Servicios Web Polimórficos? (Parte 2 – Solución con WCF y Framework 3.5)

Hace ya bastantes artí­culos atrás estuvimos hablando de Servicios Web y Polimorfismo (aquí­). Introdujimos el tema y le dimos alguna vuelta a la necesidad de poder aplicar el concepto de polimorfismo a las llamadas de un servicio web. Es más, incluso lo intentamos utilizando Servicios Web en .NET mediante el Framework 2.0… y… comprobamos que no era posible.
Quedaron abiertas otras soluciones, pero hasta el momento no habí­a podido invertir tiempo en este tema, así­ que ahora que ya tengo algo que mostraros, allá vamos!
Para empezar, como habréis podido observar la solución parte del uso de WCF (Windows Communication Foundation). En concreto para la solución he empleado Visual Studio 2008 y el Framework 3.5 (remarco lo de la versión del Framework, ya que esta misma solución utilizando el WCF y el Framework 3.0 no os va a funcionar, ya que no se hace igual). Estamos de suerte y la solución con el Framework 3.5 la verdad es que es sencillí­sima.
Paso a mostraros fragmentos de código sueltos y luego os adjuntaré el proyecto para que podáis ver y probar vosotros mismos que funciona. Eso sí­, avanzo que el código del proyecto es simplemente para probar el funcionamiento así­ que le faltarán comentarios y demás cosas que intentaré añadir directamente aquí­.
Bien, antes de nada empezar diciendo que voy a intentar seguir la guí­a del primer intento que hicimos de Servicios Web Polimórficos, en la que la idea era conseguir tener un íºnico Servicio Web que nos ofreciera la posibilidad de realizar el mantenimiento de infinitas entidades de datos, en lugar de tener un servicio diferente para cada una de ellas. Para hacerlo necesitábamos que el cliente que consume el servicio recibiera en la definición de su WSDL las clases que implementaban la interfaz IDTO, pero no habí­a manera de que la aplicación de servicios al generar el WSDL lo hiciera de forma automática.
La idea serí­a tener un servicio web que tuviera métodos como los siguientes (para los que no conozcan la teorí­a de los DAO, DTO y Factorí­as, podéis encontrar literatura en la categorí­a de patrones de este mismo blog):
public void Insert(IDTO dto)
{
    Factory.GetDAO(dto).Insert(dto);
}
public void Update(IDTO dto)
{
    Factory.GetDAO(dto).Update(dto);
}
public void Delete(IDTO dto)
{
   Factory.GetDAO(dto).Delete(dto);

Como véis esto serí­a la leche ya que cualquier llamada al servicio serí­a capaz de ejecutar la acción independientemente del DTO que le llegue…
Por aquí­ dejo el código de la factorí­a, que como véis, segíºn el DTO que recibe, retorna el DAO correspondiente.
public class Factory
{
   public static IDAO GetDAO(IDTO dto)
   {
       if (dto is CocheDTO)
       {
          return CocheDAO.GetInstance();
       }
       else if (dto is MarcaDTO)
       {
          return MarcaDAO.GetInstance();
       }
       throw new Exception(“no existe este dto”);
    }
}
Además, como podréis observar, todos los DAO heredan de IDAO, que es quien define los métodos con los que un DAO puede trabajar, y es lo que usa la factorí­a para actuar con independencia.
Pero bueno, vamos al grano y a lo que interesa, que es cómo conseguir que se entere el cliente que recibe el servicio de los DTO que pueden heredar de IDTO. La clave está cuando definimos la clase IDTO.
[DataContract]
[KnownType(typeof(DTO.CocheDTO))]
[KnownType(typeof(DTO.MarcaDTO))]
public class IDTO
{
}
Sobre la clave DataContract, ya hablaremos cuando hagamos la introducción a WCF, en lo que quiero que os fijéis es en las claves KnowType. Aquí­ es donde estamos marcando al servicio que IDTO tiene como tipos conocidos otras clases, que son las que heredan de ella. Por cierto, habréis visto que IDTO es una clase y no un interfaz… por lo visto el atributo KnowType no puede utilizarse con interfaces, pero bueno nos da lo mismo en este caso.
Con todas estas combinaciones que os he presentando, y si probáis el ejemplo donde tenéis más código, veréis que en el cliente que se ha montado (que es una aplicación de escritorio con un botón), podréis leer el siguiente código:
Servicio.MiServicioClient cliente = new Servicio.MiServicioClient();
Servicio.CocheDTO coche = new Servicio.CocheDTO();    
Servicio.MarcaDTO marca = new Servicio.MarcaDTO();     
coche.Codigo =1;
coche.Matricula=”IB-4444-TRT”;
coche.NumeroPuertas=1;
cliente.Insert(coche);
marca.Codigo = 4;
marca.Nombre = “Mercedes”;
marca.Pais = “España”;
cliente.Update(marca);
Bingo! El cliente es capaz de instanciar objetos que no son retornados o pasados por parámetro explí­citamente por un método de un servicio (que era uno de los problemas que tení­amos con el Framework 2.0). “Mágicamente” podemos utilizar los DTO en cliente, rellenarlos y pasárlos a los correspondientes métodos de Insert y Update. Al llegar la petición al servicio, la factorí­a decide el DAO a llamar en tiempo de ejecución y a correr.
Con un íºnico servicio podrí­amos realizar toda la fachada para mantener y consultar infinitas entidades de negocio. ¡Objetivo cumplido!
Os invito a descargar la solución de ejemplo que os adjunto y a lanzarla en modo debug, veréis que si lo seguí­s la ejecución mantiene el flujo que hemos definido sin problemas.
Servicio WCF Polimórfico
Saludos.
Miguel.