Reflections about SOA implementation in the enterprise.

El tema de SOA no es nada nuevo, pero a la hora de querer conocer sobre este interesante tema el problema no fue encontrar información, sino todo lo contrario, clasificar y sacar conceptos útiles de las gran cantidad de información al respecto.
A mi criterio el tema de SOA fue un gran boom hace 6 o 7 años y luego fue madurando para ser un paradigma aplicable con exito en empresas donde la madures de sus procesos justifique la gran inversión que requiere implementar SOA. No solo es cuestión de soft y hard, sino también de un cambio cultural muy importante en la compañía. Es común que cada área de negocio tenga su propia genencia que sub procesos independientes y prioridades diferentes. por los general es obvio que todas está alineadas a un objetivo de negocio común, pues sino estraríamos en otros problema que es más un análisis de administradores de empresas y consultores asociados.
Pero de todas formas esta diferentes prioridades hace que a larga cada área sea como silos aislados en donde emprenden la contrucción de aplicaciones para resolver determinadas área de negocio, sin pensar (o poco) en lo que implementa las otas áreas.
Como consecuencia tenemos casos de duplicación de funcionalidad, repostorios con datos con entidades redundantes (por ej varias tablas de clientes o de proveedores).
La estandarización de esto requiere de un área que tenga una visión transversal a todas las áreas para poder alinearlos, definir estándares de integración, desarrollo , deployment etc con el fin de integrar las diferentes áreas de negocio. Esta área deberia estar formado por especialistas en las diferenes ramas del desarrollo y arquitectos empresariales.
Volviendo al tema de SOA, una vez que tenemos los procesos, podemos pensar en la implementación en sistemas software (primero los procesos , despues el software).
Ahora, para los más ansiosos paso a describir un resumen (o recordatorio según en caso) de los que es SOA desde el punto de vista ténico.


Arquitectura orientada a servicios

Servicios

Los servicios son sistemas autónomos, que poseen una especificación definida que pueden ser accedidos en forma remota desde otras aplicaciones de la compañía.
Desde el punto de punto de vista del consumidor del servicio no interesa como está implementado sino cual es el mensaje de entrada a recibir y cuál es el formato de la salida, de esta forma se pueden crear sistemas altamente escalables, distribuidos y reutilizables.

Para que los servicios puedan forma parte de una arquitectura orientada a servicios deben tener al menos las siguientes características

• Reusables: Proveen servicios de negocio que pueden ser utilizados por varias aplicaciones.
• Proporcionar un contrato formal: Indica que establece una interface formal para los mensajes de entrada y de salida. En la práctica se debe los mensajes tienen formato XML, por lo tanto se deben exponer esquemas XML (XSD) y no clases.
• Deben tener bajo acoplamiento
Significa que un cambio en la implementación de alguno de ellos debe afectar lo mínimo posible a los demás.
• Deben permitir la composición entre ellos.
Esta funcionalidad permite componer el resultado de la ejecución de varios servicios para ofrecer un solo resultado. En la práctica esto se podría implementar con un Enterprise Service Bus.
• Deben ser autónomos.
Indica que su implementación y administración se debe poder hacer independientemente de los demás, eta característica está muy asociada con la de bajo acomplamiento.
• No deben tener estado.
Indica que el servicio recibe el mensaje de entrada, lo procesa y luego responde el resultado sin mantener estado alguna entre ejecuciones.
• Deben poder ser descubiertos.
El descubrimiento de lo servicio es un factor muy importante para poder administrarlos, de esta forma el sistema consumidor puede conocer su especificación en un forma simple. Este proceso se implementa con un registro de servicios y una herramienta de UDDI.

TNets de SOA

En la práctica se definen 4 reglas que debe cumplir un sistema basado en SOA , estas reglas se las denomina TNets de SOA [Esposito Dino et at, 2009]

TNet N° 1; Las fronteras deben ser explícitas

La interacción con los servicios se debe hacer mediante interfaces públicas. Los métodos en la interface representan los puntos de entrada en el servicio y los datos en la firma de los métodos representan los mensajes de entrada y salida del servicio.
Las interfaces deben ser lo más simples posibles y no deben exponer datos internos a los servicios, la implementación interna de los mismos debe ser transparente para el consumidor.

TNet N° 2 ; Los servicios deben ser autónomos

Para el caso de los servicio esta regla indica que cada servicio debe poder ser implementado, administrado y versionado en forma independiente del sistema en el cual es implementado y consumido. Esto no indica que los servicio deben estar totalmente aislados del resto del sistema, lo que indica que debe tener el menor acoplamiento posible. Por lo tanto si necesita comunicarse con otros servicios lo debe hacer mediante contratos y políticas.

TNet N° 3: Usar contratos , no clases

Unos de los objetivos de SOA es la interoperabilidad, o sea todo servicio debe tener una inteface pública basadas en estándares de la industria e independiente de la plataforma. En el caso de un sistema basado en componentes las interfaces entre ellos comparten clases, para el caso de SOA esto no es válido porque el sistema sería dependiente de la plataforma.
Estas interfaces públicas se basan en contratos de servicios basado en mensajes.
Los mensajes compartidos son documentos XML y su contrato está especificado mediante esquemas xml (XSD).
Las diferentes implementaciones de SOA convierten esos mensajes XML en clases específica de una determinada plataforma y convierten las clases de respuesta en sus correspondientes mensajes XML como respuesta al consumidor del servicio.


TNet N° 4: La compatibilidad es basada en políticas

Que un servicio sea accesible y que lo pueda llamar no es una buena razón para el consumidor lo invoque. Los servicios y contratos son necesarios pero no suficientes, estos indican que es lo que se envía al servicio y que se espera de él.
Este TNet se refiere a la semántica de compatibilidad entre servicios, que un servicios haga exactamente lo que el consumidor espera. Esta semática se expone vía un acceso público y una política estándar. El estándar WS-Policy [W3C WS-Policy, 2007] específica como se debe implementar este TNet

Gobierno SOA

De la definición de SOA se desprende que para poder hacer una correcta implementación y mejorar el ROI es necesario un gobierno SOA, esto implica el proceso para poder administrar los servicios, publicarlos, controlar las versiones etc. Este factor es imprescindible porque en caso contrario no se puede aprovechar las ventajas que provee este estilo de arquitectura.

Según Bobby Wolf , Consultor WebSphere J2EE de IBM [Woolf Bobby, 2007], un proceso de gobierno SOA debe manejar al menos los siguientes aspectos.

• Definición del servicio
Involucra la técncias y herramientas que permiten identificar, describir la funcionalidad y comportamiento de un determinado servicio

• Ciclo de vida del servicio
Como todo desarrollo software los servicios deben respetar un ciclo de vida de desarrollo, para el caso particular de los servicios estos pueden tener los siguiente estados.
1. Planeado.
Cuando un nuevo servicio está siendo diseñado, pero aún no implementado
2. En prueba.
El servicio está implementado en un ambiente de prueba para que pueda ser probado por el grupo correspondiente.
3. Activo
En este estado el servicio está disponible para ser consumido y por lo tanto se considera un servicio productivo. Esto implica que debe tener alta disponibilidad no se puede dar de baja o modificar sin un adecuado proceso que mitigue el impacto en los consumidores.
4.Obsoleto:
En este estado el servicio aún está activo, pero su funcionalidad es obsoleta y por lo tanto a partir de pasar a este estado no se deben aceptar nuevos consumidores y se debe comunicar que el servicio será reemplazado.
5.Eliminado:
En este estado el servicio ya no está más disponible, muchas veces es inevitable y no siempre se pasa a este estado en forma planificada. Cosa que se debe evitar para evitar el impacto en los consumidores.

• Versionado
Los servicios tienen cierta funcionalidad que satisfacen una especificación funcional específica, por lo tanto el servicio puede cambiar por cambios funcionales, por errores detectados u otro motivo. Esta situación inevitable en todo software requrie ser adminstrado en forma correcta para evitar perjudicar a los consumidores. Lo que se debe hacer es versionar los servicios manteniendo las versiones antiguas disponibles hasta que por algún motivo se se consideren obsoletas.
Para versionar existen varias técnias y cada una tiene sus pro y contras y algunas de ellas son mandatorias cuando se implementan los servicios en determinada tecnología que solo utiliza determianda técnica. Como técnicas podemos mencionar:
- Cambio de nombre del servicio con un sufijo que indique la versión.
- Agregado de parámetros opcionales en la espcificación de la interface.
- Agregado de información de la versión en la cabecera de los mensajes.
- Enrutamiento dinámico por contenido, en donde el sistema envía el mensaje a la versión correspondientes.

• Migración
En muchas situaciones en que el servicio evoluciona de versión el consumir puede seguir usando alguna versión antigua, pero esto no siempre es así y necesariamente el cosumidor debe migrar de versión porque la nueva provee funcionalidad que justifican el esfuerzo , porque la versión actual se queda obsoleta etc. El proveedor del servicio no puede depender de la migración de los consumidores, a los sumo proporciona la mayor información para que estos migren en sus propios tiempos.

• Registros de servicios
Para que los consumidores puedan acceder a los servicios primero debe saber donde están ubicados y como acceder a ellos. Además permite administrar las versiones de los servicios.
Una vez que el consumidor comienza a invocar el servicios depende de él, por lo tanto no alcanza con publicar el servicios sino que debe existir un mecanismo para regitrar las dependencias entre lo servicios y los consumidores incluyendo notificaciones a los consumidores cuando hay cambios en el servicios publicado o cuando va a ser pasado al estado obsoleto.

• Modelos de mensajes de los servicios.
En una invocación de servicios el consumidor y el proveedore debene estar de acuerdo con el formato de los mensajes a intercambiar. Para evitar el caos que searía ponerse de acuerdo entre grupos de trabajo que separados, decenas de servicios y de consumidores se adopta utilizar un modelo de datos canónico.Un modelo de datos canónico es un grupo de formatos de datos que es independientes de cualquier aplicación y compartida por todas ellas. Dentro de los procesos de gobierno SOA debe haber uno que en forma neutral encargado de definir estos formatos de datos comunes.

• Monitoreo
Es un sistema SOA se debe garantizar un determina Nivel de Servicio Acordado (SLA), pues la caída de cualquier de ellos puede afectar el funcionamiento de los consumidores y de servicios asociados si el que falló por parte de una composición de servicios.
El sistema de monitoreo es el encargado de detectar y prevenir problemas antes que ocurran midiendo los recuros de lso servidores donde están implementados los servicios, si los tiempos de respuesta están dentro de los valores predeterminados etc.

• Propiedad del servicios
Cuando una aplicación usa un servicios, ¿quién es el responsable por el servicios?. La definición es ambigüa y se debe determinar en forma clara para evitar malos entendidos. En grandes empresas puede ser un área provea servicios para acceder a información referente a ella,pro lo tanto en ese caso el área de IT de esa área de negocio es la responsable por la diponibilidad y mantenimiento del servicio. En el caso de sistemas empresariales formado por composición de servicios esta responsabilidad se solapa, por lo tanto debe haber una cooperación entre analisistas de negocios, arquitectos empresariales, arquitectos de software, reponsables de tecnología y de áreas de desarrollo para alinear todo lo referente a los servicios al negocio de la empresa.

• Pruebas de los servicios
Como todo sistema software los servicios pasan por un estado de pruebas antes de implementar en un sistema productivo. Estas pruebas deben ser tanto funcionales como técnicas y las debe hacer el área proveedora de los servicios. Los consumidores lo único que debe probar es su propia funcionalidad y la conexión con los servicios consumidos, pues pueden asumir que los servicios publicados funcionan correctamente.

• Seguridad en los servicios
¿Cualquier usuarios puede acceder al servicios? ¿Todos los datos expuestos son públicos?, ¿La información compartida debe transmitirse por canales seguros? ¿Cómo se maneja el sistema de auditaría para evitar invocaciones no autorizadas?. Estas y muchas preguntas relacionadas con la intergradidad de los datos manejados y la disponibilidad de los servicios la maneja el área de seguridad y por lo tanto estos aspectos se deben considerar en la etapa de diseño de los servicios.


Conclusión:
SOA es un importante paradigma que si es bien aplicado puede ayudar en mucho a la integración de las áreas de negocio de la empresa, mejorar la reusabilidad de los desarrollos, tener un leguaje común de modelado etc. Los proveedores suelen poner como latigijo el tema de la mejora del ROI, este es un tema en donde no pude profundizar y no se que tan fácil es calcularlo.
Lo más importante para implementar SOA no es la técnología aplicada, productos y habilidades ténicas, sino procesos bien conformados, integración de las áreas y lo más importantes cambios cultural para pensar en "SOA" de los gerentes de negocios, de IT, analisistas y lideres de proyecto.
Luego de salvado este paso (nada fácil por cierto) pasamos las habilidades de la gente ténica de IT, deben pensar en el árbol pero tambien en el bosque para no plantar un eucalipto en un bosque de pinos, usar patrones de la industria para independizar los servicios de la plataformas del consumidor , diseñar pensando en la reutilización (en la medida de los posible) entre otroas cosas.
Por último, como los procesos de negocio cambian constantemente (como dice el famoso refrán "lo único constante es el cambio"), los sistemas que forman la solución SOA deben ser lo más flexibles posible para poder seguir ese cambio, ese también es una gran desafío.

Referencias


[Esposito Dino et at, 2009], “Architecting Microsoft .Net Solution for the Enterprise”, Microsoft Press, pag 229 a 236.

[W3C WS-Policy, 2007], Web Services Policy 1.5 – Framework,
http://www.w3.org/TR/ws-policy .

[Woolf Bobby, 2007], “Introduction to SOA governance, Governance: The official IBM definition, and why you need it”,
IBM SOA Governance

Cloud Computing I

“The cloud is a virtualization of resources that maintains and
manages itself” Kevin Harting

Entre las nuevas tendencias en IT surge un nuevo paradigma para implementar aplicaciones
empresariales y servicios que difiere del conocido datacenter centralizado donde tenemos todas nuestras aplicaciones, bases de datos, servidores de email, de archivos etc.
Aprovechando las ventajas provistas por las mejoras en las redes de datos, virtualización, sistemas de almacenamiento entre otros este nuevo paradigma nos permite implementar aplicaciones dentro de una infraestructura no centralizada y compartida, básicamente está es la filosofía de cloud computing.
En este artículo veremos los conceptos básicos de este paradigma, describiremos aplicaciones y servicios provistos por los mayores proveedores de software y aspectos relacionados con los pros y contras de implementar en la nube aplicaciones empresariales.

¿Que es cloud computing?

“..moving computing and data away from the desktop and the portable PC and simple displaying the results of computing that take place in a centralized location and is then transmitted via the Internet on the user’s screen” John Markoff

Probablemente el término “cloud” surge de la representación que se hace a Internet en los diagramas de redes.
Conceptualmente cloud computing proporciona un nivel alto de abstracción de la nube en donde los desarrolladores y administrador implementan aplicaciones utilizando frameworks y herramientas que los abstrae de la implementación física como puede ser detalles de routers, servidores, unidades de almacenamiento etc.
Por lo tanto el usuario del servicio no necesita preocuparse de cómo se implementa esas tecnologías y como se mantienen. Solo se preocupa de como acceder a sus aplicaciones desde cualquier lado y su nivel de disponibilidad para satisfacer los requisitos de las aplicaciones.
En realidad con cloud computing se puede acceder a funciones y servicios con necesidades de cambios dinámicos.
Los frameworks que se utilizan en la nube deben proveer los siguientes mecanismos:

- Automonitoreo
- Registración y descubrimiento de recursos.
- Definición de acuerdos de nivel de servicio SLA.
- Reconfiguración automática.

Desde el punto de vista del usuario en la nube los recursos están virtualizados y se mantienen y administran por si mismos.

Mitos sobre la nube

Cloud computing no es grid computing, unit computing ni software-as-services SaaS,
pero estos paradigmas pueden utiliza una red en la nube como forma de implementarlos
El cloud no solamente es un cambio tecnológico sino también de negocio tanto para
los clientes que la utilicen como los proveedores de software e infraestructura tecnológica.
Gartner publicó los 8 mitos más comunes con respecto a cloud computing

Mito 1: Cloud computing es un infraestructura o una arquitectura.
Mito 2: Cada suministrador tendrá una nube diferente.
Mito 3: SaaS es la nube.
Mito 4: Cloud computing es una nueva revolución.
Mito 5: Toda los sistemas remotos son Cloud computing.
Mito 6: Internet y la Web con la nube.
Mito 7: Todo estará en la nube.
Mito 8: Cloud computing elimina las redes privadas.

Soluciones implementadas

Existen varios proveedores que ya poseen sistemas implementados en la nube y que están disponibles para ser utilizados en forma gratuita o mediante el pago de un costo según las caracteristicas suministradas.
Ejemplo de ellos son los servicios de Amazon mediante salesforce.com, LiveMesh de Microsoft o Moozy de EMC para compartir recursos, App Engine de Google o Blue Cloud de IBM son algunas de las aternativas disponibles. Para mayor detalle ver referencias.
La NASA tiene disponible "NEBULA Cloud computing platform", que son servicios basados en Cloud Computing que provee componenetes open sources y sistemas self-services.

Conclusiones

Cloud computing es el resultado de la evolución de la tecnología aplicada a la implementación de infraestructura hardware y estándares abiertos para interoperar sistemas.
Sobre la nube se pueden implementar servicios como software-as-service que son productos software expuestos en la nube como servicios como por ejemplo Google Docs o Microsoft Office Online, platform-as-service como por ejemplo los sistemas multi-petabyte de EMC Atmos o SimpleDB de Amazon.
Otro aspecto importante es el cambio en el modelo licenciamiento pasando de un sistema de compra o alquiler de la infraestructura a pago por uso.
Grandes proveedores como Micrososft, Google, Amazon, IBM, HP, Citrix o EMC entre otros ofrecen servicios en la nube, con carácteristicas muy variadas.
Por lo tanto es importante considerar a la hora de utilizar servicios en la nube los aspectos de seguridad, privacidad, disponibilidad, fiabilidad y cumplimiento de estádares aplicables a sistemas implementados en la infraestructura dentro de la compañía.

Con appistry http://www.appistry.com/ se pueden generar redes Cloud Computing locales.

Referencias

IBM Blue Cloud
http://www.deitel.com/ResourceCenters/Programming/CloudComputing/CloudComputingIBMsBlueCloud/tabid/3063/Default.aspx

Microsoft Cloud Computing Tools
http://msdn.microsoft.com/en-us/vstudio/cc972640.aspx

Amazon Cloud Services
http://aws.amazon.com/products/

EMC Cloud Optimized Storage
http://www.emc.com/products/category/subcategory/cloud-optimized-storage.htm

Google Cloud App Engine
http://code.google.com/intl/en/appengine/

NEBULA Cloud computing platform
http://nebula.nasa.gov/

¿Es socio del MUG?, www.mug.org.ar

Interoperability I

Es cada vez más común que los sistemas empresariales actuales tengan que
interactuar entre ellos, con productos implementados dentro de la compañía o con
sistemas implementado en Internet o dentro de otra compañía u organismos
gubernamentales.

En ese contexto existieron muchos protocolos de comunicaciones, desde el manejo
de la comunicación directamente utilizando el protocolo TCP/IP hasta modernos
sistemas de integración modernos donde se maneja seguridad, estabilidad,
fiabilidad, direccionamiento, enrutamiento etc.

Los primero protocolos de comunicaciones estaban diseñados para interconectar
sistemas que corrieran bajo la misma plataforma o lenguaje, de ellos surgió el DCOM
para plataforma Microsoft, CORBA para Java etc. Para el caso de necesitar
interconectar sistemas heterogéneos se debía recurrir e protocolo de bajo nivel como
TCP/IP o RPC, hoy en día se siguen utilizando para comunicarse con versiones
antiguas de algunas plataformas como SAP o Host.

Debido a esta gran torre de Babel de protocolos varios importantes proveedores de
software y hardware como Microsoft, Sun, IBM, Intel, CA, Entrust, BEA, TIBCO entre
otros coordinaron la creación de un estándar de comunicación para interconectar sus
plataformas.

Con el advenimiento del XML como lenguajes para especificar datos y metadatos se
dio un gran avance en el tema, luego se crearon las especificaciones de los XML
WebServices, en sus versiones más básicas se pudo efectuar interconexiones básicas
entre varias plataformas, como por ej .Net de Microsoft con Java de Sun.

Para poder satisfacer requerimientos de interoperabilidad más exigentes se creó el
Organization for the Advancement of Structured Information Standards OASIS.
OASIS es un consorcio de organismos con el fin de crear estándares abiertos para la
intercomunicación de sistema de información globales.

Con respecto a los webservices se generaron la familia de estándares WS*, que
extienden la especificación original para los webservices otorgando especificaciones
para agregar seguridad, manejo de transacciones, de enrutamiento etc.

En lo que respecta a seguridad se crearon la familia de estándares WS-Security ,
que tiene como objetivos establecer mecanismos de intercambio de mensajes SOAP
en forma segura.

Utilizando protocolo independientes de la plataforma

Una forma de evitar todos los problemas asociados con el marshaling entre
plataformas es utilizar protocolos que sean independientes de ellas.
Luego de un gran esfuerzo de los mayores vendors de software y hardware (Intel,
HP, Sun, IBM, Microsoft, CA etc) se formalizaron una serie de estándares para
manejar un lenguaje común a la hora de interconectar sistemas heterogéneos.

De todos estos estándares lo que nos interesan son los referidos al uso de servicios
web como mecanismo de comunicación.
De este trabajo surgió el WS-Basic Profile 1.1 que consta de un conjunto de
especificaciones para servicios web no propietarias que agrega clarificaciones,
refinamientos, interpretaciones y ampliaciones de especificaciones que promueven la
interoperabilidad.
Este conjunto está formado por las especificaciones de WSDL v1.1, UDDI v2 y SOAP
v1.1 .

Conclusión
La correcta integración de plataformas heterogéneas necesita , valga la redundancia
, la correcta integración de los proveedores que las crean, pues son lo que deben
generar herramientas para poder interconectarse con otros sistemas utilizando un
lenguaje común.
Los estándares de OASIS, en especial los WS* son un importante paso en este
sentido

Referencias

Especificación WS-Securiy, http://docs.oasis-open.org/wss/2004/01/oasis--
200401-wss-soap-message-security-1.0.pdf

World Wide Web Consortium http://www.w3.org/

Introducción TDD III

Continuando con esta serie de posts, voy a describir el uso de una herramienta que me pareció muy útil para probar servicio Web y Rest, me refiero al SoapUI.
En este caso voy a describir la funcionalidad que tiene la herramienta para crear objetos mocks que simulen un servicio Web, en la documentación del SoapUI los denominan MockService.

Los objetos Mock son objetos que permite simular los servicios externos al código que queremos probar.
Por ejemplos si estamos probando una componente de acceso a datos necesitaríamos tener acceso a la base de datos, que esta contenga datos de prueba válidos etc, por lo tanto dependeríamos del estado de la base de datos, la conectividad a ella y tener los permisos necesarios. Una alternativa sería simular el comportamiento de la base de datos utilizando objetos simulados que tenga el comportamiento esperado para el sistema real antes determinado conjunto de datos de entrada.

Luego de esta breve introducción vamos a ver como implementar MockServices usando el SoapUI

Lo primero que debemos hacer es generar un proyecto SoapUI en base al WSDL del servicio que queremos simular. Le asignamos el nombre TestCreditRiskService y habilitamos las opciones “Create Test Suite” y “Create Mock Service” dejando los otros valores por defecto sin alterar.

En la ventana “Generate Test Suite” dejar las opciones por defecto.

Para hacer una prueba manual del servicio se utilizan los mensaje xml de entrada creado por la herramienta, por defecto se crea uno, pero se pueden crear todos los necesarios con le menú contextual sobre el nombre del servicio.

En este ejemplo el servicio original está corriendo en la máquina local y los datos válidos de prueba son dni=12345678 y dni=23456789, de lo cuales obtenemos reportes de riesgo crediticio diferentes.

Para agregar un objeto Mock para un servicio Web (MockServices) se puede utilizar el creado cuando

se generó el proyecto o bien con el menú contextual sobre la interfase.

Este MockServices implementa el patrón de Service Stub para acceder a la simulación el servicio web original o bien al servicio original, esto se camb

ia seleccionando el endpoint correspondiente.

Para el MockServices creado asignamos un Response simulado en base al Request2

Los endpoint asignados a los mockservices se puede ver directamente invocando en el navegador la url asignada al MockService.

Por lo tanto si vamos a nuestro request original podríamos ejecutar el mismo pero invocando al MockService creado.

Agregamos el endpoint de la interfase RiskClientServiceSoap para que use como interfase de entrada.

Una vez configurado podemos iniciar el servicio simulado con las opción Start.

El MockService ya está corriendo, el último paso de configuración es redireccionar nuestra interfase del servicio original al servicio simulado.

Conclusión:

Utilizando el SoapUI se pueden hacer pruebas unitarias de servicios web en un forma muy simple, además permite hacer pruebas de carga.
Con los MockService podemos además empezar a dsarrollar el código que lo invoca antes de que la implementación real del servicio esté disponible.
Obviamente que está situación es útil cuando el contrado ya está bien definido y la implementación real tenga los menores cambios para que no impacte lo que ya se hizo.

Introducción TDD II

Pruebas unitarias con NUnit
A la hora de confeccionar el test unitario de una aplicación bajo NUnit, lo primero con lo que de debe contar como se mencionara anteriormente, es con los casos de test, luego se debe escribir el código de testeo, este código tiene una estructura especial y cuenta con una serie de atributos que serán interpretados mas adelante por el motor de NUnit. El código especialmente creado para este fin, contará con Assertions, que van a probar el correcto funcionamiento de la aplicación, en el caso de no tenerlos, el test fallara si el método testeado devuelve una excepción.

Asserts

Una aserción, o instrucción Assert, prueba una condición especificada
como argumento para el método Assert. Si la condición se evalúa como
true, no se produce ninguna acción. Si la condición se evalúa como
false, se produce un error en la aserción. Si la ejecución se realiza
bajo el depurador, el programa entra en el modo de interrupción.
Más información sobre Aserciones en el código administrado
Las aserciones son una base importante en los tests unitarios, si la aserción falla, se reporta el error. Si un test contiene mas de una aserción, las subsiguientes a aquella en donde se produce la falla no serán ejecutadas, ya que el test en ese caso ha fallado, es por esto que es más que recomendable, probar una sola aserción por test.

Las Aserciones deben ser utilizadas en aquellos casos en donde se requiera algún tipo de evaluación sobre un valor devuelto por un método, o por ejemplo en casos donde se evalúan condiciones en función del resultado de la ejecución de un método.

A modo de ejemplo, si se tiene un método que suma dos números, el test a realizar, será, la comprobación, del valor resultante de la ejecución del método, contra un valor esperado determinado. Existen diferentes tipos de Aserciones, que van a proveer al programador de la aplicación de test unitario, de la facilidad, para crear a partir la combinación de los mismos, test unitarios sólidos.

A continuación se enumeran los distintos tipos de aserciones provistas por Nunit. Y se recomienda visitar en link que se encuentra mas adelante, para obtener un detalle completo de los distintos métodos y sobrecargas que de la clase NUnit.Framework.Assert ofrece, agrupados por tipo.
Tipos de Aserciones:
• Equality Asserts
• Identity Asserts
• Compararion Asserts
• Type Asserts
• Condition Asserts
• Utility Methdo s
• String Assert
Para mas detalles
Atributos
Son utilizados por NUnit para la identificación de los tests, en versiones anteriores, la identificación se hacia en base a herencia y a partir de naming conventions, es a partir de la versión 2 de NUnit que la identificación de los test unitarios se da, a partir de ciertos atributos.

Estos atributos, están incluidos en el Namespace NUnit.Framework, cada clase que los use debe incluir el using correspondiente, y el proyecto debe referenciar a el assembly, nunit.framework.dll.
Para mas detalles
La Interface
El UNit se puede ejecutar de dos formas, utilizando los comandos de consola o utilizando la interfase gráfica, la primera opción es ideal para automatizar el proceso, por ejemplo desde un PostBuild en el Visual Studio .Net o desde una tarea de Nant.
Como se puede apreciar el resultado de la ejecución presenta los distintos tests unitarios dispuestos en forma de árbol.
Luego de la ejecución se puede apreciar por medio de un color el resultado del mismo.

Verde = OK

Amarillo = No se ejecutó.

Rojo = Falla

Hacia la derecha se puede apreciar por medio de una interface de solapas los logs de los tests, que proveen amplia información sobre los test unitarios ejecutados, y errores que se van produciendo.
Esta interface también brinda la opción de seleccionar los tests unitarios a ejecutar, y se recarga automáticamente cuando se recompila el código.

Creando el proyecto de pruebas unitarias en MS Visual Studio .Net

Una vez creado el proyecto de Test en MS VS .Net, que contendrá la o las clases con los métodos que ejecutará el NUnit, lo que sigue es:

En cada clase importamos el espacio de nombres agregando:

 using NUnit.Framework;

Establecemos el atributo que índica la clase que contiene las pruebas, con lo cual, previo al nombre de la clase agregamos "[TestFixture]", por ejemplo:

                                                   Contraer

namespace MyCompany.Application.Project.TestCases

{    

    [TestFixture]

    public class TestCase

    {

                      ...

    }

    ...

}

Podemos además incorporar un metodo que inicialice variables a utilizar indicándolo previamente con [SetUp]:

 Contraer

[SetUp] 

public void Init() 

{ 

      ... 

} 

Especificamos cuales son los métodos sin retorno

de resultados (void) de prueba que el NUnit deberá ejecutar con la cláusla [Test], ejemplo:

  Contraer

#region Test Method1

[Test]

public void TestMethod1()

{

      ...;

}

#endregion

El siguiente es un ejemplo simple:

  Contraer

using System;

Para ampliar el concepto de los Asserts se va dar un ejem

plo sobre su utilización.

Como se puede apreciar en el siguiente ejemplo, el método SetUp, quien cuenta con el atributo [SetUp], posee la lógica necesaria para crear los objetos que serán utilizados durante los tests unitarios.

Mas adelante, es posible distinguir el método BagMultiply, este es un test que cuenta con varios Asserts, como se puede apreciar en el código, por medio de estos 3 Asserts, se testea el buen funcionamiento del mismo.

En los dos primeros casos, los asserts son de comparación, como parámetros se pasan, en primer lugar el valor esperado y luego el valor resultante del método que se prueba.

Por último tenemos un assert que va a evaluar la condición que se pasa por parámetro.

Para este test, con cualquiera de los asserts que falle, el resultado del test será negativo.

Luego se compila el proyecto quedando preparado para ejecutarlo desde NUnit.

Conclusión:

Con esta herramienta se pueda ejecutar pruebas unitarias en forma automática.
Junto con herramientas de integración continua como el Hudson con un control de fuentes como SVN, de scripting de tareas con el Nant, de generación de mock objets como NMock se puede generar un entorno basico para automatizar las pruebas unitarias.

Comercialmente está el Team Fundation Server que permite generar los casos de test, hacer el deploy y automatizar las pruebas, el analisis de estas herramientas de este tipo queda para otro artículo.

Referencias:

1. NUnit Framework, http://www.nunit.org

Introducción al TDD I

Pruebas unitarias

Introducción:

El diseño de un software es un factor muy importante pues afecta a todo el ciclo de vida del desarrollo y la calidad del software creado. Un buen diseño permite al sistema satisfacer principalmente los requisitos funcionales pero también los no funcionales como mantenibilidad, seguridad, performance, usabilidad etc. Existen varias técnicas de diseño cada una con sus características particulares. En este artículo vamos a describir los aspectos fundamentales del desarrollo de software basado en pruebas (TDD; por sus siglas en inglés).
Por lo tanto TDD no es una metodología de pruebas sino de diseño donde se comienza con el diseño y desarrollo de los casos de pruebas y luego con la implementación del código funcional hasta que las pruebas se puedan ejecutar sin errores.
Los casos de prueba además sirven para especificar los casos de uso en formato ejecutable y esta técnica permite diseñar el software en niveles de abstracción desde una granularidad chica hasta la más grande.

Beneficios de realizar las pruebas unitarias:

En cuanto al código

• Es fácil de mantener.
• Se torna más comprensible.
• Tiende a estar mejor diseñado.
• Antes de escribir código, fuerzan a detallar los requisitos de una manera útil.
• Mientras escribe el código, evitan un exceso de funcionalidad. Cuando se pasan todos los casos de prueba, la función está completa.
• Cuando se hace refactorización de código, aseguran que la nueva versión se comporta de la misma manera que la antigua.
• Cuando se mantiene código, ayudan a asegurar que los cambios no alterarán código ajeno.
• Cuando se escribe código en equipo, aumenta la confianza en que el código que se está a punto de enviar no va a romper el de otras personas, porque se pueden ejecutar las pruebas unitarias de ellos antes.
• Los test unitarios actúan como documentación.
• El conjunto de test unitarios proporciona constante retroalimentación de cada uno de los componentes.
• La detección de errores se ve facilitada.
• El tiempo de depuración se reduce.
• El conjunto de tests actúa como una red de seguridad contra regresiones en los bugs.
  
  

Características de un buen Test:

• Un test debe probar el qué y no el cómo, debe asegurarse que la funcionalidad del código a probar se cumpla en forma correcta y no prestar atención a como lo logra.
• Es muy limitado en su alcance.
• Se ejecuta y sucede de manera independiente.
• Revela claramente su intención.
• Debe poder ser ejecutado en forma automática cada vez que se modifique el código probado.
  
• Usa ha menudo stubs y mock objects.

Desventajas de las pruebas unitarias manuales.

• Se puede escribir una aplicación de prueba para hacer el testing. Si luego de varias semanas se quiere volver a hacer el testing el código ha sufrido tantas modificaciones que seguramente la aplicaciónd e prueba inicial ya no sirva y tenga que volver a construirse.

• En proyectos grandes podrá haber decenas de clases y muchas librerias.Es muy dificil escribir pruebas separadas por cada una de las clases en el proyecto y mantener todas ellas para futuros pruebas.

• Probar apliaciones requiere un tester humano.Se puede probar varias posibilidades al principio, pero es dificil recordar todos los casos para repetir en el futuro, se deberían documentar aparte teniendo que mantener los casos de pruebas y la documentación.
  

• Cuando la prueba es manual, el tester debe verificar el resultado de la misma y por lo tanto deber tener todo el conjunto de resultados posibles para cada prueba

• Es muy poco practico repetir todo el tiempo todos los casos manualmente antes de que salga un release. Esto llevaria muchas horas o días para completar las pruebas unitarias de todas las piezas de código.

• La ejecución de pruebas unitaria en forma manual es muy tedioso y tendiente a errores.

• Utilizando Test Driven Development TDD las pruebas son automáticas y autodocumentadas.

Herramientas

Existen en el mercado muchas herramientas que permiten realizar pruebas unitarias, la mas utilizadas son

Herramienta	Plataforma	Comentarios
NUnit http://www.nunit.org/	.Net Framework 1.0,1.1,2.0	Free, modo consola o interface gráfica
TestDriven http://www.testdriven.net/	.Net Framework1.0,1.1,2.0,3.0	Misma funcionalidad del NUnit como adin del VS.net.Los resultados se visulizan en modo texto en el VS.Net
JUnit http://www.junit.org/	Java	Stand alone o integrado a varios IDEs (Eclipse, java Builder etc)
vbUnit http://www.vbunit.com/	Visual Basic 6.0	Comercial, integrada con el VS VB 6.0
ASPUnit http://aspunit.sourceforge.net/	ASP.Net	Permite realizar casos de prueba para el front end de ASP.Net (proyecto open source suspendido)
TFS http://msdn.microsoft.com/en-us/teamsystem/default.aspx	.Net framework 2.0,3.0 y 3.5	Integrado con algunas versiones del Visual Studio Team System 2005/2008.
SoapUI http://www.soapui.org	Java	Permite ejecutar pruebas unitarias de consultas SOAP y REST.
SUNit http:\\sunit.sourceforge.net	Smaltak	El padre de todas las herramientas xUnit.

Conclusión

Las pruebas unitarias son un tema muy importante para garantizar la calidad del código que estamos creando. Usando una metodología de diseño y herramientas adecuadas este proceso se podría integrar para que en forma automática se ejecuten las pruebas unitarias ante cada subida al repositorio de código centralizado.Para ello se debería integrar con sistemas de control de versiones. Agregando un sistema de revisión de código automática junto se puede garantizar la alineación del código a estándares de codificación que mitigan problemas comunes de la aplicación de malas prácticas. Este tema está fuera del alcance del TDD pero si de las metodologías de desarrollo.

Referencias

1. Testing object-oriented systems: models, patterns, and tools, Addison-Wesley

2. Continuous integration, Martin Fowler, http://martinfowler.com/articles/continuousIntegration.html

3. Extreme Programming XP , http://xprogramming.com/index.php

4. Introducción a Scrum, http://www.mountaingoatsoftware.com/scrum

5. Agile Manifiesto, http://agilemanifesto.org/