12.30.2012

QueryInterceptors en WCF Data Services

Los QueryInterceptors son atributos que nos permiten personalizar la forma en que se llevan a cabo las consultas utilizando WCF Data Services – aunque en realidad sirven para muchas otras cosas más. Creando un servicio para consumirlo desde un dispositivo móvil utilice estos atributos para llevar a cabo una tarea de consulta de forma sencilla utilizando WCF Data Services y utilizando notación JSON. El escenario lo describo a continuación.

Resulta que tengo un conjunto de registros pero solo necesito los registros que tienen una propiedad especifica seteada con un valor especifico. En WCF Data Services esto implica hacer una consulta en Linq y proceder con el filtro. Sin embargo utilizando los QueryInterceptors ya no es necesario crear la consulta en Linq del lado del cliente y puedo proceder directamente desde el servicio. Para ilustrar este caso vamos a ir con un ejemplo.

Supongamos que tenemos una tabla de películas con todas las películas del año, tal y como se ve en la figura ( datos de ejemplo por supuesto )

image

Ahora bien, resulta que la aplicación móvil solo debe de desplegar las películas que están en cartelera, es decir EnCines = 0. Para llevar a cabo esta tarea, hice un WCF Data Services y le configuré el modelo del Entity Framework para que pueda devolver las entidades. Si no agregamos ningún método o un QueryInterceptor, entonces vamos a poder filtrar utilizando un browser y modificando el query string, o creando un cliente y utilizando Linq. Sin embargo, como ya sabía que requería solo las películas que estaban en el cine proyectándose, procedí a crear un interceptor que me permita devolver solo las películas cuya Propiedad EnCines = 0.

image

Como se ve en la figura anterior, el QueryInterceptor es un atributo que se le aplica al conjunto de registros que se específica en el atributo, en este caso “Películas”. Seguidamente procedemos a crear una Expresión de Linq en donde establecemos que esa expresión recibe Película y retorna un booleano. Luego con una expresión lambda procedemos a aplicar la comparación deseada.

Como vemos en la siguiente figura, la consulta inicial solo nos retorna los registros de las películas que tienen el atributo EnCines = 0.

image

Etiquetas de Technorati: ,

11.25.2012

Memorias - Arquitectura de Software: !No necesito un Servidor de Aplicaciones

 

Leyendo por ahí un blog de arquitectura en inglés me encontré con una aseveración que me dejó pensando seriamente en como discernir en que leer y que no leer en la web. El autor – un arquitecto de software – daba 4 razones por las cuales el observaba que un servidor de aplicaciones era innecesario. Las razones eran un tanto básicas, pero el blog ha causado hasta cierto punto, movimiento en el sitio. Por este blog sentí un sentido de urgencia en escribir un post acerca del porqué SI debemos tener un servidor de aplicaciones y de eso se tratará este post.

Reutilización de la lógica de negocios

En muchos casos los desarrolladores usan el término reutilización para vender positivamente una idea, y al mismo tiempo pueden usar el término para minimizar el impacto que pueda tener el hecho de reutilizar la lógica de negocios en algún desarrollo. Sin importar si utilizamos un servidor de aplicaciones o no, la reutilización es lo que nos ha motivado a evolucionar a la hora de hacer software; haciendo memoria podemos ver claramente que primero queríamos reutilizar tipos, luego componentes, luego procesos de negocios internos y luego procesos de negocio externos. Es necesario reutilizar para prevenir la duplicación del código, el sobre trabajo y sobre todo para permitir integrar procesos de negocios que nos permitan crear de forma RÁPIDA y CONSISTENTE procesos de negocio para apoyar el buen funcionamiento de los diversos clientes externos e internos que puedan necesitar de los servicios del área. En que casos no es relevante reutilizar – bueno, si tu aplicación es algo monolítico, que nadie más va a necesitar entonces no creo que sea necesario el sobre esfuerzo requerido para hacer una aplicación con servicios reutilizables – una aplicación para estacionamiento o un sistema de inventario para la panadería de la esquina son ejemplos de estos casos.

Gobernabilidad de la solución

La gobernabilidad es una palabra de moda en nuestros días a la hora de desarrollar software, pero nadie puede negar su importancia en una arquitectura de software. El software que construimos debe de ser monitoreable, es decir, debe darnos información suficiente para saber que está ocurriendo con nuestros servicios, que excepciones pasan en nuestro eco sistema, cuál es el servicio que más se utiliza, sobre que protocolo es que más se utiliza – así es, el mundo es más que solo HTTP. Si no tenemos un servidor de aplicaciones me pregunto ¿ Cómo vamos a tener gobernabilidad? En .NET, tenemos el Windows AppFabric para tener gobernabilida sobre los servicios y procesos de negocio que tenemos automatizados, y toda esta información queda en una base de datos SQLServer desde donde tenemos la capacidad de ver en que estado esta nuestra plataforma. Volviendo con la argumentación del blog que leí – y que no les voy a mostrar – no me explico como tener gobernabilidad sin un servidor de aplicaciones.

Escalabilidad

Por supuesto que existen diferentes niveles de escalabilidad en las aplicaciones de software. En una arquitectura distribuida, es necesario tener la posibilidad de que la aplicación pueda escalar pero no a nivel de interface de usuario si no a nivel de procesos de negocio. ¿Qué sentido tiene tener una aplicación web que sea escalable si tengo un proceso instalado en dos servidores distintos ( como suele ocurrir cuando no tengo un servidor de aplicaciones ) y solo en uno de los dos esta escalable? ¿No es mejor tener un solo proceso cacheable, muy escalable, donde todas las aplicaciones que consumen el servicio tengan la misma experiencia a la hora de interactuar con el proceso?

Calidad

El hecho de no tener un servidor de aplicaciones ( o varios ) en donde los procesos automatizados residan y puedan ser reutilizados por todas las aplicaciones que lo requieran nos va a permitir garantizar que la calidad de nuestros productos se va a ir incrementando. Por ejemplo, si tengo un servicio que tiene una operación que me retorne el estado de cuenta de un cliente, y este funciona correctamente en la aplicación 1 – la que inicialmente llevo a crearlo – cual es la probabilidad de que me funciona correctamente desde otra aplicación – 100%.

Movilidad

Indudablemente que uno de los cambios más drásticos en estos días es la incorporación de dispositivos móviles. Si tenemos un servidor de aplicaciones, nuestras aplicaciones móviles serán en su gran mayoría construidas con composición de aplicaciones; es decir, consumiendo servicios y construyendo los servicios que hagan falta. Es claro que estos servicios que consumimos desde nuestros dispositivos móviles son exactamente los mismos que usa nuestro software en la empresa, por lo tanto tenemos garantía de que el software que utilizamos tendrá el mismo comportamiento a nivel de negocio sin importar desde donde se ejecuta. Sin un servidor de aplicaciones los servicios estarán en un limbo en donde nadie sabe que existen ( solo los creadores ) y por lo general nadie los reutiliza, por lo que cada aplicación tiene que desarrollar completamente sus soluciones. Además por lo general, estas soluciones van ligadas al UI seleccionado para desarrollar la aplicación.

Seguridad

La seguridad parece ser uno de los temas más importantes en temas de tecnología, sin embargo, a la hora de analizar como es manejada en cada uno de los sistemas desarrolllados en las empresas, parece que no importante tanto como se preveía. Esto se da principalmente porque la seguridad parece de entrada delegada a las personas encargadas del área de infraestructura y nosotros como desarrolladores olvidamos que somos los primeros responsables de que nuestro software sea seguro. En este aspecto, un servidor de aplicaciones es un componente ideal para poner nuestros procesos de negocios a funcionar de forma correcta, ya que la autenticación y la autorización podemos aplicarla de forma uniforme a los servicios que tenemos funcionando y por lo tanto, todas las aplicaciones que utilicen nuestros servicios utilizarán los mismos mecanismos de seguridad.

Estos son solamente algunas razones por las cuales debería utilizarse un servidor de aplicaciones dentro de la empresa: sin embargo, podríamos escribir un capítulo de un libro – ya en camino Smile - de las razones por las cuales en muchos aspectos más, un servidor de aplicaciones me va a ayudar a tener una plataforma más segura, estable, ágil y escalable.

Technorati Tags:

11.17.2012

Un Bus de Servicios en Windows – Parte 1

Uno de los términos más de moda en este tiempo es el bus de servicios. Gracias al impulso que la arquitectura orientada a servicios le ha dado, es normal ver que las empresas tengan un bus de servicios implementado, estén implementado uno, o en este momento estén pensando o en el proceso de adquirir un bus de servicios.

Durante mucho tiempo, en el mundo de Windows, hemos carecido de un bus de servicios por parte de Microsoft y lo único que hemos tenido al alcance es el Bus de Integración de Biztalk Server – que es algo parecido { pero diferente, al menos con objetivos diferentes}.

Windows Service Bus

Pero la espera ha terminado. En días pasados, se liberó el Windows Service Bus 1.0. ¿Y qué es el Windows Service Bus? Como lo dice su documentación en el msdn, es un conjunto de componentes que proveen las capacidades de “messaging” del bus de Windows Azure pero sobre Windows – on premises. Este bus, nos va a permitir crear y ejecutar aplicaciones desacopladas y basadas en mensajes ( Definición típica de un bus de servicios Smile ).

Características de Messaging del Windows Service Bus

El Windows Service Bus  soporta el mismo conjunto de caracterísitcas del Azure Service Bus; lo que quiere decir que nos ofrece almacenamiento confiable de mensajes y obtención de mensajes desde el bus a través de varios protocolos y  APIs. Para llevar a cabo estas tareas, nos ofrece dos formas para interactuar con el mismo: Service Bus Queues y Service Bus Topics.

Service Bus Queues

Las colas del bus de servicio nos permiten crear aplicaciones en donde se le permite al recibidor del mensaje procesarlo a su propio ritmo.  Además, nos permiten tener balanceo de cargas al poder tener múltiples procesadores que aceptan el mensaje desde la misma cola. Existen muchos escenarios en donde se pueden utilizar este tipo de esquemas a través de colas de mensajes, pero quizás el más popular es el caso del “check out” del carrito de compras de Amazon, el cual por escalabilidad esta implementado utilizando un esquema de colas.

Service Bus Topics

Este es un esquema pub/sub – publicador /sucriptor – que nos permite que muchos suscriptores – y de forma concurrente – puedan de forma independiente obtener una copia de un mensaje. Este escenario es muy común en los buses de integración, en donde un mismo mensaje puede activar muchos componentes del bus, tales como adaptadores, orquestaciones o mapeos. Igualmente se da en escenarios donde un mismo mensaje esta obligado a tomar dos caminos diferentes a la vez para su respectivo procesamiento.

Technorati Tags:

11.13.2012

Memorias - Arquitectura de Software: Hágalo todo con SOA !!!

Una de las afirmaciones más temerarias que esucho con mucha frecuencia, esta relacionado con el hecho de que las empresas creen que por el simple hecho de implementar una arquitectura orientada a servicios – SOA – todos sus problemas están resueltos. Esto también se ve reforzado por la idea que venden los proveedores de productos SOA cuando dicen: “Pasálo todo por el BUS de servicios y todo listo”. Esto por supuesto es incorrecto ya que aunque SOA como arquitectura ayuda a paliar los dolores normales de una organización en materia de sistemas, hay que recalcar que el fuerte de SOA va más por un tema de integración de aplicaciones heterogeneas y por extender la vida de un producto de software, que por un tema de arquitectura de dominio – ejemplo de que no se debe de pasar por un bus es el pago de tarjeta de crédito, ya que el timeout de una transacción del lado del cliente puede tener resultados inesperados en la transaccionabilidad del sistema.

Respecto a este tema, es importante diferenciar los tipos de arquitectura a los que nos vemos enfrentados todos los días. Esto principalmente porque no tienen sentido hacer una aplicación en .NET, pero como ahora estoy utilizando SOA le voy a poner un “overhead” innecesario a la transacción – no solo .NET Java, PHP o cualquier otra plataforma.

Nuestras aplicaciones de dominio – ejemplo RRHH, ERP, CRM, etc. – deben ser expuestas a través de servicios pero a través de un servidor de aplicaciones o un bus de dominio – tal como el Windows Service Bus – sin tener que ir a pasar por un bus de SOA que te va a solicitar transformar tus esquemas SOAP a un formato neutral – por lo general XML – para que pueda ser consumido desde cualquier aplicación en otro formato. 

Ahora bien, para los que ya se están preguntando porque a través de servicios si no va a pasar por un bus de datos la respuesta es muy sencilla: nunca sabemos quien va a necesitar nuestra funcionalidad. Esta es una premisa que todo arquitecto debe de tener en cuenta a la hora de desarrollar sus aplicaciones “esperar lo inesperado”. Para entender un poco mejor el escenario vamos a poner un ejemplo:

Supongamos que tenemos una aplicación financiera que se va a utilizar entre otros roles, por oficiales de servicio al cliente. Considerando que los agentes de servicio al cliente ya utilizan un CRM, no existe necesidad de parte de la institución de tener dos aplicaciones corriendo y poniendo a la agente a digitar en dos lados distintos con una alta posibilidad de error, además de incrementar la superficie de ataque ( a nivel de seguridad ). Es casi seguro que la solución óptima y que atraerá más a los clientes es el poder desarrollar sobre el CRM las interfaces contra la aplicación recién adquirida, lo cual justifica el uso de servicios para que al final solo sea pintar pantallas y consumir servicios.

Y entonces cuál es el rol de una arquitectura orientada a servicios? SOA nos va a permitir integrar nuestras aplicaciones sin importar la plataforma, y para ganarme esa versatilidad en la integración puedo darme el lujo de tener esa latencia en la transacción.

El escenario antes descrito desde el punto de vista de arquitectura se puede ver en la siguiente figura:

image

¿Que tecnologías debo utilizar?

En una arquitectura de dominio desarrollada en tecnologías microsoft lo mejor es utilizar el Windows AppFabric y el Service Bus de Windows – tema a tratar en otro post. En una arquitectura SOA si la tecnología que se utiliza es microsoft lo recomendado es utilizar Biztalk Server.

Technorati Tags: ,

8.12.2012

BPM y Workflow Foundation – Parte 3

Continuando con la tercera entrega de la serie de BPM utilizando tecnologías Microsoft, en este post vamos a realizar un workflow básico, lo vamos a instalar en el IIS/WAS y lo vamos a monitorear utilizando el Windows AppFabric.

El Workflow

En esta ocasión vamos a crear un workflow muy simple que va a llevar a cabo dos operaciones muy básicas a partir de una lista de números. Primeramente va a calcular el valor promedio de los ítems contenidos en la lista, y seguidamente va a dividir la lista de números en números pares y números impares. Iniciamos creando el workflow para ser consumido  a través de WCF tal y como se ve en la siguiente figura.

image

El workflow se puede ver en la siguiente figura.

image

Las figuras marcadas con rojo son las de activación del workflow vía el proxy de WCF y la de respuesta respectivamente. En la de activación se recibe como parámetro la lista de números con la que vamos a trabajar.

image

En la de respuesta se retorna la lista de pares, la lista de impares y el promedio calculado.

image

Probamos el workflow ejecutándolo en el WCFTest y vemos que funciona correctamente.

image

Ahora procedemos a instalar el workflow en el IIS/WAS, teniendo al AppFabric para monitoreo del workflow –el tema de los perfiles de deployment lo trataremos en otra serie. Para esto creamos una aplicación de consola y agregamos una referencia al servicio para poder activar el workflow.

image

Luego consumimos el servicio desde la aplicación de consola.

image

Si ejecutamos el código anterior el resultado es el siguiente:

image

Ahora procedemos a ver en el AppFabric como se ha estado comportando este workflow y este servicio en WCF; para esto vamos al sitio web dentro del IIS y vemos el dashboard del IIS.

image

Como podemos ver en el Panel del AppFabric, se han ejecutado 15 llamados a diversos servicios, y se han activado 5 workflows en ese lapso de tiempo ( 1 hora ).

Como podemos ver en este post, cumplimos con  3 de las 4 características de un BPM:

  1. Tener un diseñador de BPM en el Visual Studio ( en este caso 2012)
  2. Tener un motor de ejecución –> el que instancia y ejecuta el workflow, que es activado por un proxy WCF.
  3. Se puede monitorear utilizando el Windows AppFabric.
Etiquetas de Technorati: ,,,

8.05.2012

BPM y Workflow Foundation – Parte 2

Continuando con la serie de artículos acerca del workflow Foundation y los BPMs, en este post vamos a crear nuestro primer workflow y lo vamos  a exponer de forma tal que sea activado utilizando un proxy de WCF.

Implementando el Workflow

En primera instancia vamos a ir al Visual Studio y crear un proyecto de Workflow Foundation del tipo “WCF Workflow Service Application” tal y como se ve en la siguiente figura.

image

Como vemos en la figura anterior en la descripción del tipo de proyecto, este permite crear un servicio WCF que esta hosteado en el IIS/WAS – es decir soporta múltiples protocolos de activación – y se puede administrar vía el AppFabric. Este tipo de proyectos funciona de la siguiente manera cuando están en producción:

image

Inicialmente los workflows van a estar hosteados en el IIS; estos workflows pueden accederse vía HTTP o vía otros protocolos utilizando WAS; además van a ser monitoreados por el AppFabric y todo su logging y su trazabilidad va a estar almacenada en el SQL Server que esta configurado en el AppFabric para tal propósito. El workflow va a estar disponible vía un proxy WCF, por lo tanto los consumidores del workflow van a agregar una referencia al servicio cuando quieran activar el proceso.

Cuando creamos el proyecto del tipo seleccionado, se va a crear un workflow con dos actividades listas por defecto tal y como se ve en la siguiente figura:image

Como se ve en la figura anterior, las dos figuras generadas son para recibir la solicitud y para enviar la respuesta de la activación del workflow, todo el proceso que vayamos a crear, estará dentro de la zona marcada de color azul. En la figura ReceiveRequest están todos los aspectos de la configuración del workflow.

image

En esta actividad se define el namespace del servicio, el nombre del contrato, el nombre de la actividad y por último es establece si un servicio puede crear una instancia del servicio o no ( indispensable para que corra ).

Los parámetros de recibo del workflow se pueden ver en la forma de recibo en el campo content; si damos clic podemos ver la opción para poner parámetros de recibo.

image

El mismo método se utiliza para asignar los parámetros en la parte de la respuesta. En este caso, al respuesta del workflow simplemente será hacer un ToString del parametro de ingreso como se muestra en la siguiente pantalla.

image

Esto parámetros ( de recibo y respuesta ) se asignan a partir de variables definidas en el workflow, tal y como se ve en la siguiente figura.

image

Si ejecutamos esta actividad tal y como esta dándole F5, vamos a ver que este se hostea en el servidor de pruebas Web de VS y además que podemos consumirlo en el WCF Test Cliente.

image

En este caso, el WCF Test Client trabaja como el cliente que activa el workflow a través de un proxy que se genera de forma automática a la hora de debuguear el workflow.

En el próximo post vamos a crear un workflow aplicado a lo que se hace normalmente en una aplicación de negocios y lo vamos a publicar en el IIS.

Etiquetas de Technorati: ,,

7.14.2012

BPM y Workflow Foundation – Parte 1

Mucho se habla en estos días de la implementación de procesos de negocio utilizando BPM’s, y con este aparecen muchos “toolsets” para implementar BPMs en el negocio. ¿Pero qué es un BPM?¿Qué características tiene?¿Qué NO es un BPM?¿Puedo implementar un BPM en tecnologías Microsoft? Esta es una nueva serie de post orientadas a clarificar – o desenredar – un poco más el tema de los BPMs.

¿Qué es un BPM?

BPM – Business Process Management -  es la especialidad para el modelaje, automatización, administración, monitoreo y optimización de un proceso de negocios para aumentar su flexibilidad, su eficiencia, y su eficacia. En esta definición hay que destacar que BPM es una especialidad o disciplina y no una tecnología o herramienta. BPM no es solo software, si no que también la gente juega un rol muy importante; de hecho, la diferencia más importante entre un workflow y un BPM es que el BPM va más allá de la simple automatización de tareas para ayudar a la gente a llevar a cabo tareas de forma repetitiva.

Características de un BPM

Un BMP tiene cuatro características principales que vamos a discutir en esta sección:

  1. Un BPM tiene un designer: Todo BPM debe de tener un modelador de procesos visual que permita implementar el proceso de forma práctica y con rapidez.Hay que recordar que una de las ventajas de llevar a cabo BPMs es que son flexibles y permiten cambios de forma rápida, sin un diseñador esto sería una tarea prácticamente imposible.
  2. Un BPM tiene un motor de ejecución: Los BPMs corren sobre un motor de ejecución que se encarga de su ejecución de forma automática. Este motor se encarga entre otras cosas de persistir o cargar el proceso de acuerdo a las condiciones de su ejecución.
  3. Un BPM se puede monitorear: Todo BPM tiene que ser monitoreable, es decir debo saber que sucede con el mismo. Esto incluye saber si el proceso se completó, si está suspendido, o tuvo algún error, etc.
  4. Un BPM se puede optimizar: Todo BPM tiene la posibilidad de ser optimizado. Esto normalmente se logra con herramientas que permiten hacer simulación de procesos para verificar que sucedería si se le cambia, agrega o se le quita algo al proceso.

¿Qué no es un BPM?

Existen muchas herramientas en el mercado que se venden como herramientas BPM pero en realidad son flujos de trabajo básicos que dependen de la interfaz de usuario para poder ser utilizados. Un BPM no depende de ningún tipo de interfaz gráfica y puede ser activado desde una página Web, un servicio (Web o no), un servicio del sistema operativo, una aplicación de escritorio etc. Si un flujo de trabajo depende de una interfaz o de algún tipo de tecnología de presentación entonces no se considera un BPM, ya que ningún flujo de trabajo sin que haya tecnología de por medio depende intrínsecamente de la forma de activarse o de proseguir con una actividad determinada.

¿Existen BPMs en tecnologías Microsoft?

Esta pregunta es muy común cuando se habla de arquitectura de software y la empresa hace sus desarrollos en .NET. Considerando las cuatro características anteriores podemos decir que tenemos una solución BPM si utilizamos Workflow Foundation y el AppFabric. En este contexto, el workflow Foundation tiene un designer en Visual Studio –bastante completo por cierto – ,  puedo ejecutar los procesos en el motor de workflows de WF y por último con el AppFabric obtengo monitoreo, seguimiento y persistencia del Workflow. La única característica que no se cumple con el WF es la optimización del proceso, puesto que no existe una herramienta dentro del stack de Microsoft para llevar  a cabo esta tarea –> que basándome en mi experiencia es muy poco utilizada (He visto muy pocas empresas invertir en simulación de procesos para la optimización de los mismos, pese a que las herramientas que lo utilizan si lo permiten).

¿Y Biztalk Server?

Biztalk Server es un servidor de EAI –> Enterprise Application Integration –> y los wokflows que se construyen en él son workflows de integración. Biztalk Server al igual que WF tiene un diseñador, un motor de workflow y tiene monitoreo para los mismos. Sin embargo, la naturaleza de los workflows de Biztalk está dirigida hacia integrar aplicaciones a través de adaptadores permitiendo que los protocolos de comunicación y los formatos de los mensajes puedan ser dispares entre aplicaciones. Básicamente los workflows de WF son para dominios únicos de aplicación ( integración entre componentes del propio dominio ) y los workflows de Biztalk Server son para dominios externos en combinación con el dominio propio ( Integrar componentes de diversos dominios de aplicación).

Etiquetas de Technorati: ,,

7.01.2012

Biztalk: Error WCF-SqlAdapter–> The requested operation could not be performed because OLE DB provider does not support the required transaction interface

Trabajando en un proyecto con Biztalk server 2010 y los adaptadores WCF para sql server me encontré con un error muy interesante y algo complejo de comprender –> no de arreglar como sucede con la mayoría de los errores.

El problema

Resulta que estaba integrando equipos mainframe a través de un linked server con Biztalk Server. Cuando hacia consultas a los equipos mainframe la transacción funcionaba perfectamente, pero cuando la transacción tenía que modificar alguna entidad del mainframe entonces obtenía el siguiente error:

The requested operation could not be performed because OLE DB provider  does not support the required transaction interface

Haciendo un esfuerzo de memoria Lengua fuera en domingo, recordé que cuando uno utiliza linked servers contra equipos contra los que no se puede realizar transacciones distribuidas de forma automática, se debe configurar el proveedor –> en este caso OleDB –> para que no intente la operación con una interface para obtener la transacción. Esto se logra de manera simple a través de la pantalla de configuración del proveedor y marcando la opción “non transactions updates”.

image

Sin embargo seguía dando el mismo error en el servidor. Luego de un par de pruebas supuse que el error de configuración podría estar en el endpoint del servicio que se conectaba al linked server del lado de Biztalk, especificamente en el binding. Abriendo la configuración del adaptador pude ver que la configuración para la transacción de ambiente estaba en verdadero, lo cual por supuesto en una transacción distribuida eleva la transacción para que sea manejada por el  DTC y este obliga a todos los involucrados en la transacción a votar en la operación. Siendo que el mainframe contra el que estábamos interactuando no soporta el tipo de interface que solicitaba el DTC, se debió establecer esta propiedad en false y listo …problema solucionado Sonrisa 

image 

Etiquetas de Technorati: ,,

6.28.2012

Implementando un Foreach con expresión Lambda

En días pasados dando una capacitación, le solicité al grupo de desarrolladores que hicieran un método que recibiera una lista de clientes y un parámetro tipo string –> en este caso el país –> para filtrar la lista con este parámetro y retornar otra lista con los clientes que pertenecen al país solicitado. Como era de esperarse, la mayoría de los estudiantes solucionó el problema con un foreach y haciendo una comparación en cada iteración. Sin embargo, creo que es mucho más simple implementar esta solución a través de una expresión lambda y es lo que me llevó a escribir este post.

En primera instancia vamos a escribir la clase cliente sobre la cual vamos a llevar a cabo el procedimiento.

public class Cliente
{
public int Id { get; set; }
public string Nombre { get; set; }
public string Apellido1 { get; set; }
public string Apellido2 { get; set; }
public string Pais { get; set; }
}

Ahora procedemos a escribir el método que recibirá la lista de clientes y procederá a retornar otra lista filtrada con el parámetro número 2 –> el país de donde quiero los clientes.

public List<Cliente> ObtenerPorPais(List<Cliente> pLista, string pPais)
{
return pLista.Where(p => p.Pais == pPais).ToList();
}

En este código se va a comprara cada uno de los elementos de la lista, y los que cumplan con la condición ( p.Pais == pPais) serán retornados en una lista cuyo tipo se infiere a partir del tipo de la lista original y de la invocación del método ToList().


Como podemos ver en el método anterior, es mucho más simple implementar la solución con una expresión lambda y un método de extensión de linq que utilizar un foreach y una comparación por cada elemento de forma manual.



Etiquetas de Technorati: ,,,,

6.24.2012

Autenticando Servicios WCF – Certificados Digitales y Usuario/Password –Parte 3

Continuando con la serie de posts acerca de la autenticación de servicios, en este post vamos a proceder a realizar la autenticación de un servicio WCF vía usuario y password. En estos casos siempre es recomendable utilizar un certificado para asegurar el canal ya que de lo contrario, estaríamos enviando las credenciales en “clear text” y esto conlleva a que nos podamos ver en problemas si nos interceptan el mensaje.

Esquema usuario y password

Para este post vamos a utilizar una base de datos de usuarios muy conocida por los desarrolladores .NET y en especial los que utilizan mucho ASP.NET: ASPNETDB. Esta base de datos es generada a partir de un esquema que ya se encuentra incluido en los directorios de .NET y normalmente se accede utilizando el Sql Membership Provider –> Para más información acerca del ASPNETDB y el SQL Membership Provider visitar el siguiente sitio web. El esquema básico de esta base de datos con las características de usuarios y roles se ve en la siguiente figura:

image

Luego volveremos para poder agregar usuarios en la base de datos seleccionada. Por ahora proseguiremos con la implementación del servicio.

Crear el Servicio

En este caso vamos a crear un servicio muy simple que tiene una operación que recibe un string y retorna un decimal. El contrato del servicio es el siguiente:

using System.ServiceModel;

namespace AutenticacionUP
{
[ServiceContract(Namespace="http://icomparable.blogspot.com")]
public interface IServicioCuentasBancarias
{
[OperationContract]
decimal ObtenerSaldo(string pNumeroCuenta);
}
}

Seguidamente procedemos con la implementación del servicio.

namespace AutenticacionUP
{
public class ServicioCuentasBancarias : IServicioCuentasBancarias
{
public decimal ObtenerSaldo(string pNumeroCuenta)
{
return 394232;
}
}
}

Ahora procedemos a configurar el servicio. El primer paso es configurar el endpoint y probar el servicio en el test client.

      <service name="AutenticacionUP.ServicioCuentasBancarias">
<
host>
<
baseAddresses>
<
add baseAddress = "http://localhost:8732/Design_Time_Addresses/AutenticacionUP/Service1/" />
</
baseAddresses>
</
host>
<
endpoint address ="" binding="wsHttpBinding" contract="AutenticacionUP.IServicioCuentasBancarias">
</endpoint>
<
endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</
service>

El servicio corriendo es el siguiente:


image


Ahora procedemos a configurar la seguridad del servicio. El primer paso es crear un binding en donde se especifica el tipo de seguridad que vamos a manejar para autenticar el servicio.

    <bindings>
<
wsHttpBinding>
<
binding name="wsHttpEndpointBinding">
<
security>
<
message clientCredentialType="UserName" />
</
security>
</
binding>
</
wsHttpBinding>
</
bindings>

Como podemos ver en el binding, vamos a especificar que la seguridad a nivel de mensaje se llevará a cabo usando el nombre usuario y password como tipo de credencial del cliente. Ahora procedemos a asociar la credencial al servicio.

<endpoint address ="" binding="wsHttpBinding" 
bindingConfiguration="wsHttpEndpointBinding" contract="AutenticacionUP.IServicioCuentasBancarias">

Ahora procedemos a modificar el comportamiento estándar del servicio para que utilice el certificado que vamos a especificar para que asegure el canal. Este certificado estará disponible en la máquina local y en el almacén My. Nótese además que le estamos indicando que la autenticación a utilizar es userNameAuthentication y que vamos a utilizar un membershipProvider llamar MySqlMembershipProvider.

        <behavior>
<
serviceMetadata httpGetEnabled="true" />
<
serviceDebug includeExceptionDetailInFaults="false" />
<
serviceCredentials>
<
serviceCertificate findValue="CN=DRMCert" storeLocation="LocalMachine" storeName="My" />
<
userNameAuthentication userNamePasswordValidationMode="MembershipProvider"
membershipProviderName="MySqlMembershipProvider"
/>
</
serviceCredentials
>
</
behavior>

WCF soporta por defecto el uso del SQL Membership provider. Para poder utilizar tenemos que configurarlo en el app.config del servicio.

<configuration>
<
connectionStrings>
<
add name="MyLocalSQLServer"
connectionString="Initial Catalog=aspnetdb; data source=.\sqlexpress;Integrated Security=SSPI;" />
</
connectionStrings>
<
system.web>
<
compilation debug="true" />
<
membership defaultProvider="MySqlMembershipProvider" >
<
providers>
<
clear/>
<
add name="MySqlMembershipProvider"
connectionStringName="MyLocalSQLServer"
applicationName="MyAppName"
type="System.Web.Security.SqlMembershipProvider" />
</
providers>
</
membership>
</
system.web>

En este le vamos a indicar en que instancia de base de datos está la base de datos y además vamos a configurar el membership provider. En este vamos a definir el connection string que debe de utilizar para conectarse y además el nombre del provider, el cual será utilizado por el behavior configurado anteriormente para realizar la autenticación.


Ahora procedemos a instalar el servicio. Probamos que el mismos esté disponible navegando hasta la ubicación del servicio svc.


image


Ahora procedemos con el cliente. Para esto procedemos con una aplicación de consola, desde la cual agregamos una referencia al servicio que estamos elaborando:


image


Ahora consumimos el servicio de la forma que normalmente lo hacemos, sin embargo esta vez, vamos a tener que agregar el usuario y el password que para nuestro caso ya fueron agregados a la base de datos del membershipProvider –> para agregar usuarios a esta base de datos lo mejor es crear una aplicación web y desde ahi levantar el sitio web de configuración del sitio, desde donde es muy simple agregar los usuarios.

using System;
using ClienteUP.ServicioCuentasBancarias;

namespace ClienteUP
{
class Program
{
static void Main()
{
using (var _proxy = new ServicioCuentasBancariasClient())
{
_proxy.ClientCredentials.UserName.UserName = "prueba";
_proxy.ClientCredentials.UserName.Password = "Pa$$word1";

var _resultado = _proxy.ObtenerSaldo("22222");
Console.WriteLine(_resultado);
}
}
}
}

El último paso es configurar el servicio del lado del cliente para que utilice el certificado para poder comunicarse de forma segura con el servicio. Primero configuramos el comportamiento en donde le decimos al servicio donde obtener el certificado.

      <behaviors>
<
endpointBehaviors>
<
behavior name="BehaviorNuevo">
<
clientCredentials>
<
clientCertificate findValue="CN=DRMCert"
storeLocation="LocalMachine"
storeName="My" />
<
serviceCertificate>
<
authentication revocationMode="NoCheck"/>
</
serviceCertificate>
</
clientCredentials>
</
behavior>
</
endpointBehaviors>
</
behaviors>

 


Ahora procedemos a agregar el behavior al endpoint del servicio:

        <client>
<
endpoint address="http://diego-pc/WCFCertificados/AutenticacionUP.ServicioCuentasBancarias.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IServicioCuentasBancarias"
behaviorConfiguration="BehaviorNuevo"
contract="ServicioCuentasBancarias.IServicioCuentasBancarias"
name="WSHttpBinding_IServicioCuentasBancarias">
<
identity>
<
certificate encodedValue="AwAAAAEAAAAUAAAALKVZNNCYWPMn+f6f4SfBghH+PcIgAAAAAQAAAOwBAAAwggHoMIIBVaADAgECAhBZhs7Ez8SQt0Ud2V9N1dnOMAkGBSsOAwIdBQAwEjEQMA4GA1UEAxMHUm9vdERSTTAeFw0xMjA1MTYxNzQyMjBaFw0zOTEyMzEyMzU5NTlaMBIxEDAOBgNVBAMTB0RSTUNlcnQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALG6+TrqsTKkBSNpfbpKHQGzdV8poX7+0fMf5/3jdrkFz1FnfZ7VmmMPIxdNuYJv63B2ScofpZEyvOfw61DHvjShORUSk3kw5NUW40hpVx4KUSneJjcvXklIHdODUfsCy7Werx30Q0CsgfydtCzJkKYLCuT3WVFxHeIqjNRFzIuzAgMBAAGjRzBFMEMGA1UdAQQ8MDqAEEPdF141cN5jkiYGrl1aJRChFDASMRAwDgYDVQQDEwdSb290RFJNghBrRb3C05OyokfF03CEBc6QMAkGBSsOAwIdBQADgYEAl+fRGhfd/gxgmtDLUFJ2UnAPII6lslW5hMeSs/VPXpCafoOzJSfBV3NPXMslTHKgRrBfuRwcf3ruID5Ttas5n1JPfvzn7TYqVDQ+vU2rOt0A19FAMMGJBW9Q934NxRVwPSR6Yklpunozb3EFg/YdVTcBbrr658wKN/O8hrGl+IM=" />
</
identity>
</
endpoint>
</
client>

El resultado al ejecutar el servicio es el siguiente:


image


Etiquetas de Technorati: ,

6.17.2012

Autenticando Servicios WCF – Certificados Digitales–Parte 2

En el post anterior empezamos creando el certificado digital e instalándolo de forma tal que pueda ser utilizado para autenticar un cliente a la hora de consumir un servicio utilizando WCF. Ahora vamos a proceder a crear un servicio que utilice este certificado como medio de autenticación.

Creando el Servicio WCF que Utiliza el Certificado Digital

Para iniciar vamos a crear un servicio WCF con la plantilla de proyecto “WCF Service Library”.

image

Ahora vamos a crear un contrato de servicio con una simple operación que suma dos número –> la complejidad del servicio no es relevante, incluso pudimos utilizar el servicio pre generado.

using System.ServiceModel;

namespace ServicioSeguroBlog
{
[ServiceContract(Namespace="http://www.formsevolution.com")]
public interface IServicioSeguro
{
[OperationContract]
int Sumar(int pX, int pY);
}
}


Y procedemos a implementar el servicio

namespace ServicioSeguroBlog
{
public class ServicioSeguro : IServicioSeguro
{
public int Sumar(int pX, int pY)
{
return pX + pY;
}
}
}

Ahora procedemos a configurar el servicio de forma tal que pueda utilizar el certificado para la autenticación. El primer paso es definir un “binding” para establecer como se va a manejar la seguridad en el endpoint, esta seguridad se define por tipo de protocolo a utilizar –> podemos tener múltiples configuraciones para cada binding ya que siempre los podemos identificar vía el nombre. Como se puede ver en el siguiente código, en este binding vamos a utilizar seguridad a nivel de mensaje y el tipo de credencial a utilizar será certificado.

<bindings>
<
wsHttpBinding>
<
binding name="wsHttpEndpointBinding">
<
security>
<
message clientCredentialType="Certificate" />
</
security>
</
binding>
</
wsHttpBinding>
</
bindings>

El siguiente paso es modificar el comportamiento estándar definido para el endpoint por parte de la plantilla de WCF para establecer como se van a manejar los certificados a la hora de autenticar. En primera instancia, al estar utilizando un certificado temporal tenemos que habilitar el revocationMode. Seguidamente configuramos el certificado a nivel de servicio para indicarle el nombre de mismo, su ubicación, y el nombre del almacén que lo contiene.

        <behavior>
<
serviceMetadata httpGetEnabled="True"/>
<
serviceDebug includeExceptionDetailInFaults="False" />
<
serviceCredentials>
<
clientCertificate
>
<
authentication revocationMode="NoCheck"
/>
</
clientCertificate
>
<
serviceCertificate findValue="CN=DRMCert" storeLocation="LocalMachine" storeName="My"
/>
</
serviceCredentials
>
</
behavior>

Por último procedemos a “ligar” el endpoint del servicio con los ítems configurados anteriormente.

      <service name="ServicioSeguroBlog.ServicioSeguro">
<
host>
<
baseAddresses>
<
add baseAddress = "http://localhost:8732/Design_Time_Addresses/ServicioSeguroBlog/Service1/" />
</
baseAddresses>
</
host>
<
endpoint address ="" bindingConfiguration="wsHttpEndpointBinding" binding="wsHttpBinding" contract="ServicioSeguroBlog.IServicioSeguro">
<
identity>
<
dns value="localhost"/>
</
identity>
</
endpoint>
<
endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</
service>

A nivel del comportamiento no es necesario agregarle nada ya que el servicio utiliza el que esta definido por defecto, por lo tanto solo tenemos que agregar el binding el cual hacemos a través de la etiqueta bindingConfiguration. Ahora procedemos a instalar el servicio en el IIS.


Antes de instalar el servicio podemos probar que este este funcionando correctamente con el host temporal de VS 2010 –> svcHost. Si el servicio carga esta bien configurado.


image


Sin embargo, si lo ejecutamos debe de fallar ya que el cliente de prueba auto configurado no tiene la información del certificado para autenticarse.


image


Para instalar el servicio, hacemos una aplicación web dentro del IIS


image


Seguidamente creamos un Application Pool que tenga un usuario que tenga permisos para acceder al certificado, en mi caso es usuario local –> Local System.


image


Luego procedemos a asignar ese pool a la nueva aplicación web.


image


El siguiente paso es instalar el servicio en la nueva aplicación creada en el IIS. Esto se hace seleccionado la opción de publicar el servicio.


image


El VS nos dirá si la instalación estuvo correcta o no.


image


Si habilitamos el directory browsing y vamos a la dirección del servicio vamos a ver el contenido del directorio.


image


si le damos click al archivo svc veremos la presentación del servicio y ahí podemos seleccionar ver el wsdl del servicio.


image




Configurar el Cliente


El último paso es configurar el cliente. Para esto vamos a crear una aplicación de consola que va a consumir el servicio. El primer paso es agregar la referencia al servicio con la dirección del WSDL.


image


Seguidamente procedemos a codificar la invocación a la operación.


 

using System;
using ClienteSeguro.ReferenciaServicio;

namespace ClienteSeguro
{
class Program
{
static void Main()
{
using (var _proxy = new ServicioSeguroClient())
{
var _resultado = _proxy.Sumar(3, 5);
Console.WriteLine(_resultado);
}
}
}
}

El siguiente paso es configurar el cliente para que pueda autenticarse con el certificado. Primeramente procedemos a agregar el comportamiento del lado del cliente para que el cliente sepa donde esta el certificado a utilizar. En este caso será igual del servicio porque estamos haciendo el ejercicio en la misma máquina, en situaciones reales hay que instalar el certificado en el cliente e indicar en la configuración en donde se encuentra este certificado.

  <system.serviceModel>
<
behaviors>
<
endpointBehaviors>
<
behavior name="BehaviorNuevo">
<
clientCredentials>
<
clientCertificate findValue="CN=DRMCert" storeLocation="LocalMachine" storeName="My" />
<
serviceCertificate>
<
authentication revocationMode="NoCheck"/>
</
serviceCertificate>
</
clientCredentials>
</
behavior>
</
endpointBehaviors>
</
behaviors>








Por último agregamos el comportamiento al endpoint del servicio.

      <endpoint address="http://diego-pc.cgccr.priv/WCFCertificados/ServicioSeguroBlog.ServicioSeguro.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IServicioSeguro" behaviorConfiguration="BehaviorNuevo"
contract="ReferenciaServicio.IServicioSeguro" name="WSHttpBinding_IServicioSeguro">
<
identity>
<
certificate encodedValue="AwAAAAEAAAAUAAAALKVZNNCYWPMn+f6f4SfBghH+PcIgAAAAAQAAAOwBAAAwggHoMIIBVaADAgECAhBZhs7Ez8SQt0Ud2V9N1dnOMAkGBSsOAwIdBQAwEjEQMA4GA1UEAxMHUm9vdERSTTAeFw0xMjA1MTYxNzQyMjBaFw0zOTEyMzEyMzU5NTlaMBIxEDAOBgNVBAMTB0RSTUNlcnQwgZ8wDQYJKoZIhvcNAQEBBQADgY0AMIGJAoGBALG6+TrqsTKkBSNpfbpKHQGzdV8poX7+0fMf5/3jdrkFz1FnfZ7VmmMPIxdNuYJv63B2ScofpZEyvOfw61DHvjShORUSk3kw5NUW40hpVx4KUSneJjcvXklIHdODUfsCy7Werx30Q0CsgfydtCzJkKYLCuT3WVFxHeIqjNRFzIuzAgMBAAGjRzBFMEMGA1UdAQQ8MDqAEEPdF141cN5jkiYGrl1aJRChFDASMRAwDgYDVQQDEwdSb290RFJNghBrRb3C05OyokfF03CEBc6QMAkGBSsOAwIdBQADgYEAl+fRGhfd/gxgmtDLUFJ2UnAPII6lslW5hMeSs/VPXpCafoOzJSfBV3NPXMslTHKgRrBfuRwcf3ruID5Ttas5n1JPfvzn7TYqVDQ+vU2rOt0A19FAMMGJBW9Q934NxRVwPSR6Yklpunozb3EFg/YdVTcBbrr658wKN/O8hrGl+IM=" />
</
identity>
</
endpoint>

Si ejecutamos el cliente anterior el resultado es el siguiente:


image


Etiquetas de Technorati: ,

5.25.2012

Autenticando Servicios WCF – Certificados Digitales–Parte 1

Crear e Instalar el Certificado

Cuando se crea un servicio que se debe autenticar utilizando certificados digitales para brindar seguridad a nivel de mensaje debemos crear un certificado temporal. Para esta tarea procederemos con la herramienta makecert.exe. Esta herramienta genera certificados del tipo x.509 para propósitos de prueba. En realidad esta herramienta crea una pareja de llaves –> una pública y otra privada – que servirán para las firmas digitales las cuales se van a almacenar en un archivo.

Para desarrollar un servicio que use certificados x.509 para brindar seguridad a nivel de mensaje –> la seguridad se puede aplicar a nivel de mensaje o a nivel de transporte dependiendo del protocolo utilizado –> los certificados tienen que tener un nivel de confianza los cuales tienen que tener un nivel de confianza especificado. Las opciones disponibles son:

  • Peer Trust: el certificado se valida de forma directa
  • Chain Trust: el certificado se valida contra el emisor del mensaje conocido como “root authority”.

En este tutorial vamos a utilizar Chain Trust. El primer paso es crear un certificado auto firmado que será la autoridad raíz; este certificado será almacenado en el almacén de autoridades raíz de certificación de confianza. En WCF se utilizará posteriormente para crear un certificado desde el certificado autofirmado raíz y que se instalará en el almacén de la máquina local.

Crear el Certificado Raíz

El primer paso para crear un certificado raíz que se va a utilizar para firmar los certificados que se van a intercambiar entre el servicio WCF y el cliente. Para esto utilizamos el “command prompt” de Visual Studio y procedemos con la siguiente instrucción:

image

En este caso el parámetro –n indica el nombre del CA, –r indica que el certificado va a ser autofirmado y por último –sv nos indica que el archivo contiene la llave privada del certificado.

Cuando ejecutamos este comando aparece la pantalla para crear el password de la llave privada.

image

Luego nos va a pedir el password de nuevo con el fin de poder acceder la llave privada del archivo pvk para generar el .cer que es el que contiene la llave pública.

image

Podemos verificar que los certificados están creados en el directorio donde nos ubicamos para crearlos utilizando el Windows Explorer

image

Instalar el certificado

Ahora procedemos a instalar el certificado en la locación “Trusted Root Certification Authorities” lo cual nos indica que todos los certificados firmados por esta autoridad serán de confianza tanto para el cliente como para el servidor. [ Este ejemplo corre en una sola máquina, si se desea tener un cliente en una máquina virtual o vía red, se debe instalar el certificado también en la máquina cliente.

Para levar a cabo esta tarea procedemos a correr la consola de administración utilizando el comando ejecutar – Windows + R – y procedemos a escribir mmc y le damos enter.

image

Tenemos que agregar el complemento – snap – para poder agregar el certificado, para esto seleccionamos archivo y agregar o quitar complemento…

image

Seguidamente agregamos el complemento de certificados tal y como se ve en la siguiente pantalla.

image

Cuando arranca el wizard, seleccionamos cuenta de equipo para que el certificado este disponible para todos los usuarios.

image

Seleccionamos el equipo local como administrador del complemento y luego finalizamos el wizard..

image

Y finalizamos el wizard. La pantalla del MMC debe verse ahora así:

image

Expandir el folder de Certificados y seleccionar el folder de Entidades de certificación raíz de confianza –> vaya traducción.

image

Ahí le damos botón derecho y procedemos a seleccionar la opción “todas las tareas/importar”.

image

El wizard inicia con la siguiente pantalla en la cual seleccionamos siguiente

image

Buscamos el archivo .cert que acabamos de generar y lo agregamos

image

En el siguiente paso aceptamos los valores por defecto.

image

En la última pantalla revisamos los valores del wizard y lo finalizamos

image

El certificado esta instalado en el almacén de certificados de confianza de la raíz. Para verlo procedemos a expandir el folder de certificados en la consola y los buscamos por el nombre.

image

Crear e instalar el certificado temporal para el uso del servicio WCF

Ahora procedemos a crear e instalar el certificado en la máquina del servidor. Para esto procedemos a movernos a la ubicación del  certificado raíz en la máquina del servidor.  Una vez en la ubicación procedemos con el siguiente comando desde el “prompt de Visual Studio”.

image

Este comando nos permite crear el certificado e instalarlo en el store My. El certificado se llama DRMCert.cer y esta creado a partir del certificado emitido en el paso anterior RootDRM. Al estar utilizando la misma máquina tanto para el servidor como para el cliente el mismo store y el mismo proceso nos sirve para interactuar con el certificado. Si estuviéramos trabajando con máquinas separadas, habría que copiar el certificado y aplicar el mismo comando del lado del cliente de prueba.

Si vamos a la consola consola de administración, el certificado recién creado deberá aparecer en el almacén de equipo local, dentro del folder certificados de los certificados personales.

image

En el siguiente post iniciaremos el trabajo con el servicio WCF y su respectivo cliente.

Etiquetas de Technorati: ,,