Sergio Salanitri Blog

Tip para el SoapUI

2011-03-15T12:58:00.001-03:00

Hay casos en que desde el SoapUI no se puede importar wsdls que están hosteados en un sitio con autenticación integrada. Se desconoce el motivo del error. Pero de todas formas se puede importar el wsdl bajándolo como archivo y luego importar el archivo utilizando la opción Browse de Projects->"New SoapUI Project" o "Proyecto Ya creado"->Add WSDL

Debugging de formularios infopath

2011-03-15T11:26:00.002-03:00

El presente post tiene como fin indicar los tips a seguir para poder debuguear formularios infopath que requieran prámetros de entrada desde el Visual Studio 2008 SP1.

• Seleccionar las propiedades del formulario a debuguear.
• Configurar el path del infopath.exe y los parámetros que se les quiera enviar (si aplica).
• El Visual Studio no puede levantar el formulario infopath por eso se debe llamar a una aplicación externa para que se encargue. En este caso la aplicación infopath.exe

Ejemplo
Dentro de Debug
Start externa programs:
Infoapth 2007: C:\Program Files\Microsoft Office\Office12\INFOPATH.EXE
Infopath 2010: C:\Program Files\Microsoft Office\Office14\INFOPATH.EXE

Publicación:
Luego de la compilación se deben publicar los formuario, en este ejemplo lo publicamos en la carpeta InfoPath_Publish en la raiz del proyecto.

Command line arguments:
"..\..\..\..\..\InfoPath_Publish\Formulario.xsn" /InputParameters "modo=parametro1=12345&parametro2=P&parametro3=54321&configpath=D:\MyProject\ProjectName\FormPath"

• Agregar breakpoints y ejecutar el debugging de la forma habitual con F5.
• Este proceso levantará en forma externa al Infopath y luego el Visual Studio adjunta el proceso del Infopath para poder debugguearlo.

Mica en fiesta bicentenario

2010-06-07T12:50:00.002-03:00

Arquitectura de software, rol e integracion de aplicaciones

2010-05-31T12:15:00.005-03:00

En el presente post, comparto un documento académico que hice con respecto al tema de referencia.

http://bit.ly/bfSKOR

El resumen de este documento fue posteado en

My Software Architecture Presentation

Habilidades de un arquitecto de software

2010-05-28T13:13:00.001-03:00

La visión general de un arquitecto de software es un experto en tecnologías de desarrollo, sería el encargado de proveer soluciones tecnológicas óptimas para los problemas del negocio. Además se espera que esas soluciones se integren correctamente con los componentes y soluciones existentes y planeadas.

El arquitecto se tiene que comportar como un arqueólogo, con inventiva, innovación, capacidad de mediación, negociación y liderazgo.

Por lo tanto se pretende que sea especialista pero a su ver tenga una visión general de todas las etapas del ciclo de vida del desarrollo del software. Esto le permite al arquitecto controlar aspectos de calidad en el desarrollo desde el inicio hasta la implementación en ambiente productivo y su posterior mantenimiento

Dado que es prácticamente imposible ser especialista en todas las áreas del ciclo de vida del desarrollo del software y a su vez tener una visión general del proceso existen las clasificaciones de los diferentes tipos de arquitectos de IT.

Joseph Hofstader agrega una visión del arquitecto desde el punto de vista de las habilidades de diseño. En la etapa inicial del proyecto debe tener una visión conceptual del mismo en base a los requisitos funcionales y las restricciones del negocio, en una etapa posterior se debe diseñar desde el punto de vista del modelo de dominio, puede ser horizontal o vertical, horizontal es aplicable a través de diferentes industrias y la vista de dominio vertical es aplicable a un industria en particular, se suele subestimar las habilidades para modelar dominios verticales, pero no es lo mismo el modelo de dominio para una empresa de banca, de telecomunicaciones, servicios o metalúrgica, está habilidad tiene que ser estimada por los CIOs y aprovechada para brindar valor agregado a los diseños de los sistemas de la compañía.

Estos dos aspectos definen la definición del problema, tal como se muestra en la figura existe una segunda etapa que se basa a el desarrollo de la solución

Conocer cómo trabaja una tecnología no es lo único que se debe saber para diseñar aplicaciones robustas, dedicarle esfuerzo a esta etapa no es menos importante que las anteriores, pues un profundo conocimiento de la tecnología a aplicar permite al arquitecto alinear las especificaciones funcionales al diseño técnico. Es recomendable trabajar con el mínimo de tecnologías posibles, esto permite administrar el esfuerzo del desarrollo en forma más eficiente, reduciendo la cantidad de herramientas de administración, desarrollo, monitoreo etc, teniendo grupos con menos perfiles técnicos etc. [Hofstader Joseph, 2008].

Existe otra clasificación de los roles difundida por el IASA [Akenine Daniel, 2008] que está relacionada con ciertas actividades que debe realizar un arquitecto clasificada en 3 niveles y 40 artefactos a generar.

Nivel 1: Los arquitectos y los responsables del negocio crean estrategias juntos de cómo alinear las estrategias del IT con las del negocio. Estos principios y políticas tienen influencia en toda la organización. Ejemplos de entregables en este nivel son planes de desarrollo de software , visiones y estrategias
Nivel 2: Los arquitectos crean artefactos que soportan la relación entre el negocio y la tecnología. A este nivel, los arquitectos intentan entender el proceso de la organización y como pueden mejorarlo usando las capacidades que provee el área de IT. Ejemplos de este tipo de artefactos son diagrama de procesos y de servicios.
Nivel 3: Producen artefactos para el modelado técnico de la arquitectura, utilizan las mejores practicas de diseño posibles para crear buenas soluciones, tales como equilibrio entre costo y funcionalidad, escalabilidad, flexibilidad, seguridad y otros atributos de calidad. Dentro de este nivel están los modelos de aplicación, de datos, de dominio, de componentes, capas, objetos etc.

Habilidades blandas

Un arquitecto tiene que tener la habilidad de manejar relaciones inter personales entre los miembros de su equipo, los líderes de los proyectos, los clientes y usuarios manejando una adecuada comunicación y lenguaje acorde con cada perfil de interlocutor. Es un error común hablar con lenguaje excesivamente técnico con un analista funcional o líder de usuario cuando en realidad se debería expresar en términos de procesos de negocio e interfaces de usuario y que valor agregado otorga el sistema al negocio.

Debe tener la habilidad de bajar a un nivel de atracción adecuado las especificaciones recibidas desde los usuarios que solicitan determinado sistema, para ello se requiere la habilidad de relevar la información necesario de esas personas.

Habilidades técnicas

La visión general que tiene el arquitecto le permite diseñar el sistema con un cierto nivel de abstracción que le permita describir todo el sistema.

En sistemas muy grandes estos diseños iniciales se subdividen en sistemas más pequeños que para poder simplificar el diseño. Estos subsistemas pueden estar construidos en diferentes tecnologías, implementados en infraestructuras diferentes, pudiendo ser construidos dentro de la empresa, por un tercero o bien ser un producto comercial. El diseño debe permitir integrar todos los sub sistemas mediante la utilización de estándares de integración de aplicación aplicables en la empresa.

Para un correcto diseño se debe tener bien identificados los requisitos funcionales, tener un adecuado conocimiento de las tecnologías, productos y sistemas implementados en la compañía, conocer sus ventajas y desventajas y luego decidir si utilizar productos y sistemas ya existentes, adaptarlos a las necesidades, construir nuevos o impulsar la adquisición de productos comerciales que se adapten a todo o parte de la necesidad del negocio. En el capitulo referentes a Diseño de Arquitecturas se analizará con más detalle este tema.

Referencias

[Akenine Daniel, 2008], “A Study of Architect Roles by IASA Sweden”, Architecture Journal 15, MSDN Architecture Center, http://msdn.microsoft.com/en-us/architecture/cc505968.aspx
[Hofstader Joseph, 2008], “We Don't Need No Architects”, Architecture Journal 15, http://msdn.microsoft.com/en-us/architecture/cc505974.aspx

Tutorial de Linq

2010-04-20T14:09:00.001-03:00

Comparto este tutorial sobre linq a nivel introductorio muy intresante, principalmente porque empieza con lso conceptos básicos necesario para entender linq.

Linq

View more presentations from blo85.

Config WCF with two host headers (english)

2010-03-15T16:11:00.003-03:00

Scenario: WCF with .net framework 3.5 Sp1, Windows 2003 SP2, IIS 6.0 with two host headers.

In this, my first post in english, I write about the configuration details when we need install a WCF service hosting in IIS 6.0 when the Information Server have two or more host header configurated.

Suppose a simplified version of classic WCF sample:

IService1.cs

namespace WCFTest

{

[ServiceContract]

public interface IService1

{

[OperationContract]

string GetData(int value);

}
}

Service1.cs

namespace WCFTest

{

public class Service1 : IService1

{

public string GetData(int value)

{

return string.Format("You entered: {0}", value);

}

System.ServiceModel Web.config section:

In this case we use windows authetication, but this issue is not mandatory.

<system.serviceModel>

.....

</security>

</binding>

</basicHttpBinding>

</bindings>

</identity>

</endpoint>

</service>

</services>

</behavior>

</serviceBehaviors>

</behaviors>

.....

</system.serviceModel>

The error that ocurrs when the IIS 6.0 has configurated two or more host header is the folowing

Could not find a base address that matches scheme http for the endpoint with binding BasicHttpBinding. Registered base address schemes are [].

This error ocurrs because the WCF runtime cannot know the host header where the service was implemented. In this case we must be configurate in explicit form what is the the IP of the host header when the service should run.

First , we add other System.ServiceModel section

<system.serviceModel>

.....

</baseAddressPrefixFilters>

</serviceHostingEnvironment>

The sevice and behaviors sections change too.

<endpoint address=http://<host header IP>/WCFTest/Service1.svc

binding="basicHttpBinding"

contract="WCFTest.IService1">

</endpoint>

</service>

<serviceMetadata httpGetEnabled="true"
httpGetUrl="http://<host header IP>/CASServices/Services.svc/>

</behavior>

</serviceBehaviors>

</behaviors>

.....

</system.serviceModel>

Note: In the production environment is recomended the set in false the httpGetEnabled and includeExceptionDetailInFaults attributes.

Buenas prácticas de programación en C

2010-03-10T16:41:00.008-03:00

El siguiente documento describe las buenas prácticas de programación a nivel general de lenguajes de programación orientados a procedimientos y en particular para el lenguaje de programación C.

Estas buenas prácticas las clasificaremos en diferentes grupos.

Nomenclaturas: Se refiere a las reglas aplicables a la denominación de nombres de variables, constantes, funciones, estructuras etc. Estas reglas tiene como objetivo definir un lenguaje común para facilitar la lectura y mantenimiento de un código. Son reglas generales de muchos lenguajes de programación, que son aplicables perfectamente al lenguaje C.

Sintaxis: Se refiere a reglas de la sintaxis en si del lenguaje de programación, y recomendaciones para hacer mas legible el código generado.

Patrones: Los patrones son diseños y recomendaciones generales que solucionan problemas comunes de determinados contextos. Existen patrones de diseño aplicados a diferentes tipos de lenguajes de programación (orientados a procedimientos, objetos, eventos, web etc), para diferentes contextos de ejecución (multitareas, tiempo real, distribuidos, ejecución batch etc), para diseñor en diferentes nivels de abstracción de un sistema, para integración entre sistemas que corren en la misma o diferente plataforma etc.

En nuestro caso nos dedicaremos a los aplicables a lenguajes de programación orientada a procedimientos (como el C).

Manejo de errores y excepciones:

Este tema se podría incluir dentro del grupo de sintaxis (mejores prácticas para manejar los errores) o patrones (patrones de manejo de errores), pero como se considera un tema muy importante en el desarrollo de software de calidad se lo agrega como item aparte.

Se define como un error en un programa a un defecto (bug) que provoca que el programa no funcione correctamente en todas las funcionalidades para el cuall fue diseñado. Un error puede provocar que un cálculo devuelva un dato incorrecto o que el sistema se "cuelgue" en ante ciertos parámetros de entrada. Durante la etapa de pruebas se debe detectar la mayor cantidad de errores posibles, para luego ser corregidos antes de publicar el programa para su utilización productiva.

También existen errores provocados por eventos externos a nuestro programa, como por ejemplo la no existencia de un archivo, permisos inadecuados para ejecutar determinada acción etc. Ante estos errores , que deben ser consdierados en el diseño, el sistema debe responder con un código de error para que el programa que invoque la función pueda actuar en consecuencia.

En cambio una excepción en un problema inesperado que no tiene un manejo como el caso del error. En el entorno Linux se pueden utiizar diferentes técnicas para manejar las excepciones, como pro ejemplo intercepción de mensajes. Lamentablemente el lenguaje C no tiene un buen manejo de excepciones en forma nativa y se debe recurrir a soluciones externas como la mencionada.

Documento completo

My Software Architecture Presentation

2010-03-10T14:33:00.006-03:00

En la actualidad no se concibe empresa grande sin soporte a sus negocios mediante el uso de las tecnologías de sistemas de información implementados dentro de la misma. Estos sistemas ayudan a manejar áreas tales como recursos humanos, ventas, compras, gestiones de procesos específicos del rubro, administración financiera, económica, tableros de comandos para la ayuda a la decisión de la gerencia etc.

Dada la criticidad de esos sistemas para el funcionamiento del negocio es imprescindible que sean construidos, implementados y mantenidos siguiendo estándares de calidad.

En este contexto se necesita un especialista que tenga una visión de negocio, habilidades técnicas y buena comunicación a los diferentes miembros del área de IT.

Estos sistemas muchas veces deben ser interconectados, es facultad del arquitecto garantizar la calidad del software desde el inicio hasta su implementación y mantenimiento.

En la siguiente presentación se resume el trabajo que analiza los aspectos relacionados con la arquitectura de software, su clasificación, el rol del arquitecto y metodologías recomendadas en pos de optimizar la integración entre sistemas.

Software Architecture Presentation

La documentación completa de esta presentación esta en el siguiente post.

Arquitectura de software, rol e integracion de aplicaciones

Micaela en su primer día en jardín para 3 años.

2010-03-03T11:29:00.003-03:00

Develop in C/C++ with Eclipse CDT.

2010-02-03T12:15:00.008-03:00

Les comparto una breve introduccion al desarrollo de aplicaciones C y C++ con eclipse. Este tutorial esta pensado para aquellos que tienen poca experiencia con el Eclipse.
El uso de este entorno de desarrollo forma parte de una iniciativa de usarlo para desarrollo de aplicaciones utilizando la biblioteca OpenCV (Vision Library), que permite procesar imagenes estáticas y dinamica que puede ser programada en C/C++ y Python.

Eclipse es un entorno de desarrollo IDE de código libre que está basado en un plataforma de desarrollo extensible mediante plugings (Plugin-Development Environment PDE). Está desarrollado en Java pero permite agregar plugines para programar en gran cantidad de lenguajes de programación, herramientas de diseño , de control de ciclo de vida del desarrollo ,de control de fuentes (SVN, CVS) etc.

Entre los proyectos existentes para Eclipse se pueden clasificar en las siguientes grupos más importantes:

1- Desarrollo de aplicaciones empresariales.

2- Desarrollo de aplicaciones embebidas y móviles.

3- Aplicaciones basadas en clientes ricos.

4- Aplicaciones web basadas en interfaces ricas (Rich Internet Applications)

5- Desarrollo de entornos de trabajo (frameworks) para múltiples usos.

6- Administración de ciclo de vida del desarrollo.

7- Herramientas para aplicaciones basadas en Arquitecturas Orientadas a Servicios (SOA)

La documentación de este IDE se puede obtener del sitio oficil de Eclipse

Para el caso de queres programar en C o C++ vamos a utilizar el plugin de eclipse para desarrolladores de C++ CDT.

El Eclipse es multiplataforma, en nuestro caso los vamos a instalar sobre un Kubuntu dentro de una máquina virtual en Virtual Box.

Desde este IDE se puede crear proyectos , incluir código desde otros archivos, depurar paso a paso pudiendo ver es estado de las variables etc.

Al igual que todo paquete de Eclipse al iniciar la aplicación se debe seleccionar un espacio de trabajo (workplace), el Eclipse indica una por defecto que está ubicada en el perfil de usuario, esta carpeta contendrá los proyectos y códigos fuente que desarrollemos. Es posible crear otro workplace y pasar de uno a otro según convenga usando el comando File->Switch workplace

Proceso de instalación

La instalación del eclipse se efectúa de la siguiente forma

$sudo apt-get install eclipse

Una vez implementado el IDE se debe instalar el plugin del CDT, la forma recomendada a partir del a versión 3.4 del eclipse es usando la opción de instalación de nuevo software

Para instalar un plugin de Eclipse se de indicar la url de donde se obtendrá los código, el IDE los baja , los compila y configura automáticamente.

Para el caso del CDT esa url se obtiene de su sitio oficial http://www.eclipse.org/cdt/

El siguiente diagrama indica como se debe proceder.

1- Ejecutar el wizard para instalar proyectos nuevos

2- Configurar la url de donde se bajaran los paquetes del CDT.

Código de ejemplo

Para los impacientes vamos construir un proyecto de ejemplo y con él mostraremos las funcionalidades básicas del IDE.

El Eclipse tiene la posibilidad de crear proyectos donde internamente cargaremos nuestros códigos. Estos proyectos estarán dentro de perspectiva de Eclipse, por defecto se carga la correspondiente a Java.

En este ejemplo construiremos un ejemplo muy simple que define algunas variables y utilizando un bucle las muestra en pantalla que nos va a servir para mostrar funcionalidades básicas del IDE.

1- Crear un proyecto C del tipo consola

1.1 Creamos un proyecto C tipo consola

1.2 Dejar la opciones por defecto.

2- Código de ejemplo

3- Compilación y ejecución.

El CDT al instalarse utiliza por defecto el gcc. Al ejecutar el programa el CDT lo compila y en el caso de no tener ningun error ejecuta el codigo y muestra los resultados.

Para ejecutar el codigo seleccionar el siguiente menú:

Run → Run (Ctrl + F11) y Seleccionar correr proyecto C/C++.

El resultado para este codigo de ejemplo es la siguiente:

0a 1b 2c 3d 4e

4- Debugging

El CDT utiliza el debugguing del gcc para poder detener, inspeccionar los valores de las variables, modificarlas, correr paso a paso, agregar breakpoints, correr dentro de funciones etc.

Para ejecutar el debug del codigo seleccionar el siguiente menú:

Run → Debug (F11)

La primera vez pide la configuracion del debugguer, seleccionar GDB

Luego el CDT indicara que al ejecutar el debug el Eclipe cambiara de perspectiva, este es un proceso habitual para la mayoria de los lenguajes de programacion soportados por el IDE

El el diagrama se visualizan las diferenes secciones de la perpectiva de debug

- Debug: Indica el proceso que se esta ejecutan, en nuestro ejemplo la funcion main()

- Variables. En esta secciones se puede ver el estado de las variables correspondiente a la línea del código que estamos analizando.

- Breakpoints: Muestra los breakpoints que tenemos marcado en el código, una forma de crearlo es hacer doble click sobre la barrar vertical de la izquierda del codigo justo en la línea donde queremos que se detenga la ejecucion del programa.

- Register: Permite ver el estado de los registros del procesador, esta opcion es muy util para cuando tener codigo assembler junto con el codigo C.

- DSF Disassembly: Se puede ver el codigo assembler correspondiente al codigo C que estamos analizando.

El debugguer permite ademas ver el estado de las variables con solo apuntaar con el cursor del mouse sobre la variable a inspeccionar.

Comandos basicos de debugguing:

F11: Ejecuta el codigo en modo debug, esto hace que el debugguer corra el programa hasta el primer breakpoint, si no se asignaron breakpoints corre hasta el final del programa.

F5: Ejecuta linea a linea, esta opcion es muy util para ver como evoluciona el estado de la variables.

F6: Ejecuta linea a linea como F5 pero con la diferencia que si en la linea a ejecutar existe una llamada a funcion el debuguer se introduce en ella para ejecutar linea a linea su codigo interno. Esto no aplica a llamadas a funciones de la biblioteca estandard u otra biblioteca pues se require tener el codigo C disponibles.

En la seccion de disassembly se muestra el linea a linea pero del codigo assembler correspondiente.

F8: Ejecuta el codigo hasta el siguiente breakpoint.

Conclusión:

El Eclipse CDT es una plugin de eclipse que permite programar en C/C++ para en entorno donde lo tengamos instalado, en nuestro caso se instaló para programar en C/C++ para Linux.Para el caso de Windows se debe instalar el compilador de C/C++ compatible con gcc (MinGW entre otros), ver documentación del CDT para este caso.

Si ya trabajaron con Eclipse para Java,PHY, JMe , Python u otros de los tantos lenuajes soportado por sus plugines usar el CDT es muy transparente, esa es una de la grandes ventajas que tiene este IDE. El resto es cuestión de práctica.

Test Driven Development presentation

2009-12-29T23:30:00.003-03:00

En este caso comparto una presentación, que si bien tiene varios años no deja de ser interesante para introductir en este tema.

http://bloggingabout.net/blogs/dennis/archive/2005/12/14/10554.aspx

Mocking Frameworks

2009-12-28T01:22:00.004-03:00

Le comparto una presentación muy interesante sobre el tema de Mocking, pruebas unitarias, de integración , inyección de dependencias etc.

http://altnet-hispano.pbworks.com/van-2009-11-28-mocking

Software Architecture and business objetives

2009-11-06T18:09:00.001-03:00

El miercoles 4 de noviembre tuve la oportunidad de asistir a una conferencia del Phd Andres Diaz Pace (ADP) en donde presentó la metodologia del SEI para la documentación de arquitecturas de software. Al finalizar la presentación de Andrés varios panelistas hicieron sus comentarios y respondieron a preguntas de los asistentes.

A continuación voy a intentar resumir los aspectos relevantes del la presentación.

ADP comentó que hay muchas definiciones de Arquitectura de Software, entre ellas comentó la del SEI ("Software Architecture in Practice", Clements, 2008).
Entre los apsectos importantes que rescaté del seminario es que se tome en cuenta o no la arqteuictura de software siempre existe, en forma formal mediante procedimiento o informal o implicita. Es decir si no diseñamos arquitectura alguien en el proceso de desarrollo lo hará y de la mejor forma que pueda, con el peligro que ello acarrea.

Otro aspecto es el lugar de la arquitectura de software en el proceso de desarrollo, ADP mostró un proceso simplificado en donde se inicia por lso objetivos de negocios, luego los requerimientos funcionales, de allí la arquitectura de software y finalmente el sistema. Este es un proceso iterativo en donde del objetivo de negocio se deriva a especificaciones funcioanales de alli mediante diseño se contruye la arquitectura de software y luego el equipo de desarrollo la implementa.
Al grupo de arquitectura debe participar en todo el proceso de desarrollo de software teniendo mayor porcentaje de participación durante la etapa de elaboración del proceso, pero tambie´n requiere cierto grado de participación durante la etapa de incepción, transisión e implementación.
ADP considera incorrecto que el equipo se desvincule totalmente del proyecto luego de terminado el diseño arquitectónico, por eso es requerido un cierto grado de participación en la demás etapas.

Otro aspectos importante de mencioar es que el diseño arquitectónico permiti reducir los riesgos en el proyecto, pues se encarga de elicitar los atributos de calidad, validar la infraestructura, validar con áreas auxiliares (seguridad informatica, tecnología, stakholders etc). Cabe destacar que el disertantem comentó que involucrar a muchas áres implica un riesgo a la hora de documentar la arquitectura pues cada área tiene su propia visión del proyecto y puede querer incluir en la documentación aspectos que no son parte del diseño arquitectónico (tal vez si de documentación complementaria).

Se discutió sobre lo que NO es la arquitectura de software, y ADP dió algunos ejemplos como:
- No es la arquitectura del hardware.
- No es el modelo de datos.
- No es solo un diagrama de "cajitas" interconectadas.

De este último punto se desprende que por presiones varias los stakholders intentan reducir el tiempo de diseño para pasar rapidamente al momento de la implementación, por lo tanto la arquitectura dieñada tiene una visión muy general, no consdiera atributos de calidad, riesgos por el uso de tecnologías no estandares en la compañía etc.

Elicitación de atributos de calidad:
Estre los procesos recomendados por el SEI se comentó uno denominado QAW (Quality Atributte Workshop)http://www.sei.cmu.edu/library/abstracts/reports/03tr016.cfm
Este proceso tiene como fin comprometer a los stakholders para definir precisamente los atributos de calidad requeridos en el proyecto. Basicamente la técnica implica litar los atributos de calidad y leugo mediante votación se pondera cada atributos. Luego de eso se puede elimiar algunos meno prioritarios (o dejar su analisis para un posterior release) dejando solo los más importantes.
La técnica es simple, pero lo que no es simple conseguir que los stakholders se involucren en este aspecto, pues la visión de los atributos de calidad de cada uno puede diferir bastante.

Basicamente lso siguientes son los aspectos más importante de eta técnica:

- Centrado en el sistema.
- Focalizado en los stakeholders.
- Técnica implementada antes de definier la arquitectura.

Una sesión de QAW debería seguir los siguientes pasos, la misma está moderada por un facilitador, el manager del proyecto y el arquitecto. Es importante que tiene que tener un time frame definido y en la manera de lo poible obtener un consenco documentado.

1- Introduction to QAW (Manager)
2- Business Mision Presentation (Arquitecto).
3- Indetification of Architecture Drivers
4- Scenarios Bainstorming.
5- Scenarios priorization
6- Scenario refinemente
7- Return to 1.

Esta técnica permite concentrar el esfuerzo en el diseño de aspectos no funcionales para los atributos de calidad más relevantes para los stakholders del proyecto.
la técncia define que en la documentación de atributo de calidad se deben considerar los siguientes aspectos:

1- Estímulo: Es el evento de entrada.
2- Respuesta al estímulo.
3- Fuente del estimulo.
4- Condición del ambiente.
5- Medida de la respuesta.

Por ejemplo si el atributo de calidad es la performance una simplificación (hiper simplificada) para estos aspectos serían:

1- Estimulo: Request a una determinado servicio.
2- Respuesta al estímulo: Mesaje de respuesta en XML (especifica peso en Kb).
3- Fuente de estimulo: proceso X que corre en servidor Z.
4- Condición de ambiente: X% de CPU, Z Mb de memoria consumir por el servidor, I/O, Byterates etc.
5- Medida de la respuesta: Reqeust por segundo, %CPU y %memoria conumida por el proceso en cuestion etc.

En la documentaciónd el SEI existen tablas donde están tabulados varios atributos de calidad.

Consderaciones sobre documentación de arquitectura.

Debe tener un enfoque basado en vista. Cada vita mostrará difentes niveles de detalle de la arquitectura y representaciones para diferentes interlocutores (lógica, capas, implementación etc).
En la documentación se debe tener el trace entre una objetos de una vista y de otra.
Un mayor nivel de detalle reduce el tiempo dedicado al mentoring y el coaching a la hora de implementar la arquitectura. Esto no implica que se reduzca a cero pues el arquitecto participa en todo el proceso de desarrollo.

Por ejemplo en un vista en donde se quiera detallar aspectos de seguridad deber indicar zonas de seguridad, puntos de entrada, conexiones etc.
Si es por un tema de performance, incluiría vistas de procesos, interacción etc.

En la documentación del SEI se clasificar las diferentes vistas.

En resumen las vistas deben consdierar los siguientes aspectos:

1- Estructura del sistema en térmicos de unidades de código.
2- Interacciones en tiempo de ejecución.
3- Como se relacionan con estrucmturas no software.
4- Interfaces.
5- Comportamiento.

Tambien se puede ver desde tres perpectivas diferentes:

1- Módulos: Contrucción, analisis de impacto, pruebas etc
2- Componentes y conectores: performance , disponibilidad etc.
3- Asignación de responsabilidades: Diponiblidad , seguridad, performanceetc

Para evaluar la completitud de una vista hay que considerar la descripción de sus elementos constitutivos, mapeo entre vistas, deben existir diferentes vistas según perfil de stakholders, asegurarse que contengan información útil.

Evaluación de arquitecturas:

Luego de esta introducción el disertante comento sobre el proceso ATAM (Architecture Tradeoff Analysis Method) http://www.sei.cmu.edu/library/abstracts/reports/00tr004.cfm

ATAM provee tendencias sobre la evaluación de la arquitectura, no aspectos precisos. Esta técnica ayuda a evaluar aspectos de la arquitectura como nivel de enfioque en el producto software, detección temprana de riesgos, prácticas de ingenieria de software, aspectos de calidad etc.
Dado qeu es un proceso complejo se sugiere efectuarlo luego de tener terminada la primera iteración de la documentación de arquitectura y luego de finalizada cada etapa de elaboración de las sucesivas iteraciones.

Un aspecto que comentó como introducción el disertante fue la técnica de diseño definida por el SEI, es la ténica ADD(Atribute-Driven Desing) http://www.sei.cmu.edu/library/abstracts/reports/06tr023.cfm

De eta descripción podrai resumir que la técnia ADD permite articular lso objetivos de negocio con la arquitectura, mitigar riesgos y se considera en todo el proceso de desarrollo.

Como conslusión ADP mencionó que en el futuro próximo es importante considerar istemas que requieran gran escalabilidad (ej Facebook) o gestionados con recursos no cetralizados (ej Eclipse).

Finalmente el SEI tiene su blog en donde la comunidad puede participar

Saturn Netwotk Blog

SOA anti-patterns

2009-11-03T23:56:00.005-03:00

Como en diseño de aplicaciones multicapas, web, cliente-servidor u otras existen patrones que describen problemas comunes y sus soluciones estandarizadas, en el caso de SOA no es la excepción. En este post no vamos a describir los patrones más comunes, pues son muchos y son de referencia para arquitectos y desarrolladores que trabajen en el diseño de servicios SOA, en el sitio de “SOA patterns”, http://www.soapatterns.org/ hay publicado muchos patrones y constantemente se agregan nuevos.
La intención es describir algunos de los anti patrones SOA más comunes con el fin de indicar como no se debe diseñar una solución SOA.

Interfaces CRUD
CRUD en la sigla en inglés que representa las operaciones de creación, lectura, actualización y borrado. Es muy común utilizar estas operaciones en relación a las bases de datos, pero en el caso de un sistema orientado a servicios especificar las operaciones de los servicios como CRUD es una mala práctica.
Por ejemplo en un servicio de manejo de ordenes diseñar en servicio en base a CRUD implica tener operaciones del este tipo

FindOrderByIDResponse FindOrderByID(FindOrderByIDRequest request);
CreateOrderResponse CreateOrder(CreateOrderRequest request);
UpdateOrderResponse UpdateOrderByID(FindOrderByIDRequest request);
DeleteOrderResponse DeleteOrder(DeleteOrderRequest request);

Si en los casos de uso se necesita crear, actualizar y borrar ordenes esta especificación de servicios es válida, pero si la creación de una orden implica varias operaciones previas (por ej verificar la disponibilidad del producto, verificar el estado de crédito del cliente y crear la orden), la operación CreateOrder debe invocar internamente todas las operaciones necesarias para crearlo pues en caso de exponer solo la creación de la orden el consumidor debe hacer las operaciones previas. Este diseño violaría el TNet 3 pues no estaríamos compartiendo solo contratos.
En resumen lo incorrecto no es el uso de CRUD para la especificación de un servicio sino un mal diseño.

Interfaces Chatty

Este anti patrón se refiere a cuando se diseña un sistema orientado a servicios con operaciones que implican un alto nivel de granularidad. En este tipo de interfaces el consumidor es el encargado de llamar a las diferentes operaciones siguientes una lógica específica para que juntos hagan una determinada acción de negocio. Lo correcto es que todas las operaciones para hacer una determina acción de negocio se ejecuten internamente en el servicio.
Por ejemplos la siguientes operaciones se basan en un diseño que aplica este anti patrón

bool ChekGoodAvailability(Ordr order);
bool CheckCreditStatus(Order order);
bool PlaceOrder(Order order);

Estos dos anti patrones están asociados pues un mal diseño de una interfaz CRUD se convierte en una interfaz chatty.

En conclusión el formato de los servicios expuestos depende fundamentalmente de la especificación de casos de uso que estos deben implementar. Por lo tanto en ciertos casos se van a requerir operaciones tipo CRUD pero en muchas otras no. Un adecuando análisis de las especificaciones funcionales seguido de un buen diseño es importante para no terminar utilizando anti patrones.

What SOA is not?

2009-10-25T06:32:00.001-03:00

Este post tiene como fin aclarar que no es SOA, con el fin de evitar confusiones y malos entendidos a la hora de emprender un proyecto de implementación SOA.
Dino Esposito [Esposito Dino et at, 2009] indica que hay que tener claro que SOA no es una revolución, un objetivo en sí, una tecnología , ni tampoco una implementación de webservices.
No es una revolución porque hace más de 15 años que existe la infraestructura para integrar aplicaciones (EDI, CORBA, COM, DCOM etc). Lo que generó SOA fue la necesidad de integrar sistemas existente con el fin de implementar procesos de negocios usando software. Por lo tanto invocar objetos remotos, enviar mensajes ya existía antes que SOA, por lo tanto no es una revolución sino una evolución.
Tampoco es una tecnología en sí, pues SOA es totalmente independiente de proveedores y productos. Unos de los mayores beneficios de SOA es que se aplican sus principios a una organización en particular. No se debe pensar una implementación SOA en base a productos del mercado, se debe pensar en SOA tomándose en tiempo necesario para entender sus principios y aprender cómo aplicarlos en toda su infraestructura.
Decir que SOA son webservices es un error común pues a la hora de implementar los webservices son los más utilizados como mecanismo de comunicación entre los sistemas que forman la infraestructura SOA. Por lo tanto no todas las soluciones SOA utilizando webservices y no todos sistema basado en webservices es una implementación de SOA.
Como venimos diciendo ante de pensar como implementar SOA se debe tener bien definidos los procesos de negocio que suponemos que se van a mejorar mediante la implementación de SOA. Por lo tanto el objetivo no es implementar SOA sino mejorar uno o varios procesos de negocio determinados. Luego de analizar los procesos involucrados, la infraestructura, aplicaciones, tiempo y presupuesto disponible recién en ese momento estaremos en condiciones de decir si SOA es aplicable o no.

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

Reflections about SOA implementation in the enterprise.

2009-10-16T17:55:00.010-03:00

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

2009-09-09T11:44:00.006-03:00

“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

2009-09-02T22:17:00.007-03:00

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

2009-08-22T23:43:00.008-03:00

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

2009-08-19T20:54:00.007-03:00

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:

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

Introducción al TDD I

2009-08-14T17:47:00.014-03:00

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

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

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

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

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

Agile Manifiesto, http://agilemanifesto.org/

Micaela, 2 años y medio

2009-08-06T12:32:00.003-03:00

Integration Patterns

2009-08-05T16:45:00.004-03:00

Este es el titulos de unos de los libros de Patterns & Practices que resumen en un proyecto ficticio un diseño aplicando gran variedad de patrones de integración.
El libro se lo puede bajar en formato pdf en el sitio de P&P.

http://msdn.microsoft.com/en-us/library/ms978729.aspx

En la siguiente presentación hice un resumen de este libro.

Resumen Integration Patterns

Otra importante fuente de información sobre el tema es el sitio de Patterns and Best Practices for Enterprise Integration (http://www.eaipatterns.com/) que tambien tiene su libro.
Este sitio es muy interesante porque tiene los patrones clasificados en varias categorias y stencils de visio con esquema sobre este tipo de patrones.

Plugin Pattern II

2009-07-31T15:34:00.013-03:00

En la practica cotidiana existen muchas oportunidades en la que se desea extender la funcionalidad de un sistema, tal sea para implementar de otra forma un funcionalidad existente como agregar una que no exista.

Una alternativa de solución

Usando herencia se puede implementar de otra forma una funcionalidad existente respecto a una clase original.

Por ejemplo en un sistema simple de validación de datos de entrada en donde tenemos que validar los campos tipo string, valores requeridos y uno alfanumérico con un formato predefinido, se podría implementar de la siguiente forma

La clase ValidateEngine permite validar todos los datos de entrada, obviamente esta implementación está muy simplificada pues se debería agrega toda la lógica de validación de datos de entrada de un determinado formulario del front end de la aplicación.

Esto trae como problema que se deba implementar lógica para validar tipo de datos, longitud, expresiones regulares (por ej para un ISBN) y valores requeridos, es decir una implementación con una muy baja cohesión.

Una mejora sería que la clase ValidateEngine sea una clase abstracta del cual se deba heredar para implementar cada tipo de validación.

De esta forma tenemos diferentes validaciones implementadas en clases separadas, lo que permite que cada una de ellas tenga alta cohesión.

Para utilizar este modelo podríamos aplicar el patrón estrategia [3] tal como muestra la figura.

Aplicando este patrón tendríamos un sistema más flexible, por ejemplo en C# se podría implementar de la siguiente manera:

http://codepaste.net/ocb7gy

Como resultado de la ejecución de este ejemplo obtenemos la siguiente respuesta

Si deseamos agregar una nueva forma de implementar una validación deberíamos heredar otra clase y configurarla en la clase de contexto.

Esta solución es mucho mejor que utilizar una sola clase para todo pero tiene el gran inconveniente que para agregar nuevas funcionalidades se debe crear una clase heredada lo que hace el sistema poco flexible.

¿Cómo mejoramos está solución?

Supongamos que deseamos crear un sistema en donde se pueda expandir su funcionalidad pero en forma dinámica, configurable y en tiempo de ejecución, la solución mencionada ya no satisface ese requerimiento.

La implementación del patrón Plugin permite agregar funcionalidad a nuestro sistema en forma dinámica utilizando configuración o un estándar de implementación predefinidos. Los módulos que agregan funcionalidad al sistema se denominan plugins.

Ejemplos de la vida real

Este patrón es muy utilizado en múltiples sistemas como sistemas multimedia que permiten agregar en forma muy simple nuevos módulos para edición de audio, transformación entre formatos, skins, analizadores de espectro etc.

En el mundo del desarrollo este patrón se aplica mucho, el más claro ejemplo es el IDE Eclipse,

la arquitectura de este entorno de desarrollo está exclusivamente basada en plugins, pues por si solo no tiene funcionalidad significativa más que proveer un entorno que permite agregarlos [4].

En sus orígenes fue creado como un entorno de desarrollo para Java, pero actualmente se puede usar para muchos otros lenguajes (C++, Python, PHP, Perl, Intel C++ para Linux, Cobol, ABAP , Google apis etc.), también se puede usar para modelado (UML, Base de datos, Data Warehouse etc.), herramientas de soporte al desarrollo como gran cantidad de editores diferentes, clientes Subversion, para soporte de programación en pares distribuida (Distributed XP) , comerciales como herramientas para el BPM de Tibco, generación de interfases para el broker de Software AG etc , al día de la fecha existen más de 1200 plugins publicados.

Visual Studio .Net tiene una api que permite crear plugins (addons), esta api esta implementada en System.Addin. La versión para desarrolladores del Visual Studio Team System posee plugins para revisión de código (basado en el FXCop) para pruebas unitarias, para análisis de performance, cobertura de código, control de fuentes, implementación etc.

Se pueden utilizar plugins comerciales o bien integrarlos al Visual Studio mediante un desarrollo especial.

Veamos una aplicación práctica

En el siguiente ejemplo vamos a extender el sistema de validación para aplicar el patrón Plugin, en este caso se va a utilizar configuración xml y reflection para poder agregar en forma dinámica nuevos mecanismos de validación.

Las nuevas validación estarán implementadas en assemblies separados y usarán el patrón Separate Interfase [5] para implementar la interfase IValidate que está en el assembly Context.

Cada implementación de una validación diferente se implementa en assemblies separados y mediante configuración se agregan como plugin al sistema original.

En este ejemplo usamos el siguiente archivo de configuración.

<name>ValidateRegularExpresions name>

<fullName>ValidationExample.ValidateRegularExpresions,Version=1.0.0.0,Culture=neutral,

PublicKeyToken=3d10efd7d0a5d829fullName>

<type>ValidationExample.ValidateRegularExpresions.ValidateRegularExpresionstype>

<active>trueactive>

plugin>

<name>ValidateStringsname>

………………………...

plugin>

………………………...

plugins>

ValidatePluginsConfigFile>

Por lo tanto podemos agregar nuevos nodos plugin por cada componente de validación y el programa automáticamente los invocará.

Un poco más de código

En el siguiente fragmento de código se muestra como se puede ejecutar en forma dinámica un método de un assembly externo usando reflection y un poco de lógica para leer la configuración

http://codepaste.net/k9bih8

Considerando que para que funcione correctamente los plugins deben estar en la GAC el resultado de la ejecución de este programa es idéntico al caso anterior.

Código

El código de ejemplo mostrado es parcial , de este link pueden bajar el proyecto completo para probar en sus maquinas, fue creado con el Visual Studio 2005 SP1.

Conclusión

El patrón plugin es muy útil para extender la funcionalidad de un sistema de forma tal que podemos construir una sistema base que permita agregar plugins y luego esos plugins pueden ser construidos por terceros, esta filosofía la usa el IDE Eclipse ya mencionado y también es muy utilizada en el navegador Firefox (Firefox extensions) y el Chrome de Google.

También se usa en sistemas comerciales cuyos plugins requieren el pago de licencias adicionales al sistema principal.

Como desventaja se debe considerar el aumento del complejidad para permitir el agrego de los plugins en forma simple por un usuario que no tiene porque conocer los detalles del sistema principal.

Como en muchos casos para hacer un sistema que permita utilizar este patrón se debe considerar en el diseño original de la arquitectura del mismo.

Bibliografía

[1] Pattern to Enterprise Applications Architecture - Plugin Pattern ,http://martinfowler.com/eaaCatalog/plugin.html

[2] Log4Net Framework , http://logging.apache.org/log4net/index.html

[3] Erich Gamma et at, “Design Patterns: Elements of Reusable Object-Oriented Software” (Addison-Wesley Professional Computing Series) , pag

[4] Eclipse plugin central web site, http://www.eclipseplugincentral.com/

[5] Erich Gamma et at, “Design Patterns: Elements of Reusable Object-Oriented Software” (Addison-Wesley Professional Computing Series) , pag

[6] Pattern to Enterprise Applications Architecture - Separate Interface pattern, http://martinfowler.com/eaaCatalog/separatedInterface.html

Plugin pattern

2009-07-21T13:12:00.009-03:00

Como inicio de una seria de articulos sobre patrones empiezo con uno muy relacionado con mi ultimo post,

Patron Plugin.

“Links classes during configuration rather than compilation.” (Fowler, POEAA, p.4990)[1]

El patrón Plugin permite agregar funcionalidad a nuestro sistema en forma dinámica utilizando configuración, por lo general se usan en frameworks que permitan agregar nuevas formas de implementar funcionalidades ya existente, por ejemplo el log4net [2] permite agregar nuevas implementaciones para los adaptadores a los repositorio donde registrar los mensajes de Log (IAdapter) o formato de los mensajes (IFormater).
Otro sistema que usaba el patrón plugin fue el EDRA de P&P, este framework implementaba el patrón Pipes & filters [3] en donde se podían agregar handlers que ejecuten determinada funcionalidad antes de ejecutar una acción personalizada, después o en ambos casos, ejemplo de un handler de “antes” sería un handler de autenticación, de “después” un handler de validación del formato de respuesta y para ambos casos un handlers que agregue información adicional al mensaje de entrada y al de salida a la acción, por ejemplo para medir tiempo transcurrido entre le ejecución de la llamada a la acción y la recepción del mensaje de respuesta.

Otro ejemplo de implementación del patrón plugin es cuando se usa en la implementación del patrón Chain and Responsability [4], básicamente en este patrón participan un conjunto de objetos de comandos y una serie de objetos de procesamiento, mediante configuración se pueden agregar en forma dinámica nuevos objetos de comandos.
Para implementar este patrón el sistema a extender debe disponer de un mecanismo de configuración donde se puedan agregar los nuevos componentes que implementan interfases definidas para determinadas funcionalidades del sistema.
Siguiendo con el ejemplo de log4net el archivo de configuración de la figura se indica el mecanismo que utiliza este Framework para aplicar el patrón plugin.

En este ejemplo se tienen 3 appenders, uno que envía los registro de Log a la consola, el segundo a un archivo que puede llegar a un máximo de 100kb (y luego se genera otro) y un aprender personalizado que envía los logs a otro repositorio no contemplado en la configuración estándar de log4Net (por ej MSMQ o WCF).

Mas info

[1] Pattern to Enterprise Applications Architecture - Pluging Pattern ,http://martinfowler.com/eaaCatalog/plugin.html

[2] Log4Net Framework , http://logging.apache.org/log4net/index.html

[3] Enterprise Integration Patterns – Pipes & Filters , http://www.enterpriseintegrationpatterns.com/PipesAndFilters.html

[4] Design Patterns: Elements of Reusable Object-Oriented Software (Addison-Wesley Professional Computing Series)

Logging and trace.

2009-07-13T11:02:00.008-03:00

En este post subo información sobre unos de los servicios cross más importantes a considerar en el diseño de un arquitectura empresaria, que es logging y trace de los eventos y errores que surgan en la aplicación. Se analizan las carácteristicas más importantes, los anti patrones, las buenas prácticas y los patrones de diseño aplicados. Al final se indican algunos frameworks de logging para diferentes plataformas y lenguajes de programación.

Objetivo:
Registrar eventos de relevancia para utilizarlos en procesos de auditoria o troubleshuting post mortem.
Es una herramienta muy útil en ambientes productivos donde es imposible depurar con herramientas de desarrollo.
Los eventos pueden ser información de depuración o errores ocurridos en la aplicación.

Características deseables de un sistema de logging:
Configuración de niveles de log
Formateo de eventos
Agregado de información adicional en publicación de eventos
Logging asincrónico
Logging confiable
Logging centralizado
Configuración jerárquica y dinámica
Publicación a múltiples destinos
Aplicación para visualizar y analizar los eventos.

Anti patrones:

Todo en un mismo mensaje: Todo junto en un mismo archivo es muy dificil de analizar.

Registro de datos incompletos:Registrar lo que sirva para, ni más ni menos.

Log sin formato o formato no consistente: Si el log no está estructurado, su analisis se hace muy dificil.

Entradas multi línea: Complica el procesamiento de log para pasarlo a una DB o aplicación que muestre la información en forma amigable.

Registrar mensajes relacionados a un mismo contexto en varias líneas: Muy dificil de analizar lo que pasó en un determinado contextode ejecución.

Buenas prácticas:

Registrar los logs en repositorio con formato, esto facilita en análisis de los logs registrados.

Separar los mensajes en diferentes destinos dependientes de la audiencia que los usa, por un log de auditoria puede tener muchas más información de la necesario para resolver un problema que ocurrió en la aplicación.

Registrar las acciones antes de que ocurran

Evitar que los archivos de logs sean muy grandes, se recomienda archivarlos y crear uno nuevo.

Registrar los eventos en una sola línea, es más fácil de analizar y filtrar. Si la información tiene formato complejo se recomienda usar xml.

Usar formato consistente en un mismo archivo.

Patrones utilizados

Estrategia:

Se puede usar para seleccionar la forma en que el sistema de log registra los eventos y errores.

Pipes and filters:

Se usa para tener un mecanismo extensible y de bajo acoplamiento para agregar información contextual y codificación a los mensajes antes de enviarlo al repositorio de logging.

Consideraciones de implementación:

Por lo general son frameworks muy flexibles, que soporta multiples fuentes y destinos, por lo tanto para implementarlo adecuadamente se requiere un buen análisis de que funcionalidades usar y cual es su mejor forma de implementar.

Otros frameworks de logging e instrumentación.

Java: log4J y de este log4Net, log4PHP, log4JavaScript, log4C, log4VB, log4SQL, log4PLSQL etc

AJAX: log4javascript, JSLog, Lumberjack, log4Js, jsTracer

Unix like: syslogd (nativo).

Bibliografía

Carácteristicas
http://gojko.net/2006/12/09/logging-anti-patterns/

Frameworks
Pattern & Practices Logging Application Block
Apache Log4Net

Patrones
http://www.dofactory.com/Patterns/PatternStrategy.aspx
http://msdn.microsoft.com/en-us/library/ms978599.aspx

Golpe en Honduras

2009-07-05T19:41:00.002-03:00

Este no e un tema relacionado con Arquiectura de software , pero aprovecho este espacio para repudiar el golpe de estado en el pais hermano de Honduras.
Es importante deterner este golpe, para evitar que otros los quieran imitar.
Me parece muy bien el repudio internacional, y del gobierno argentino.
Nosotros que vivimos casi toda nuestra vida en democracia, y muchos de mis colegas nacieron en democracia deben saber que no debe existir mas golpes de estados en ningún país que pueda desastibilizar la región.

Implementacion ASP.Net

2009-06-23T16:07:00.007-03:00

El tema del post es para un manual, lo que quiero compartir son algunos tips para implementar aplicaciones ASP.Net en entornos con framework .Net 2.0 instalado.
Supongamos que tenemos un ambiente con aplicaciones ASP.net 1.1 y solo tenemos los framework 1.0 1.1 , si queremos implementar una nueva apliación desarrollada con ASP.Net 2.0, tenemos que hacer los siguiente:

1- Instalar el runtime del framework .Net 2.0. How to
2- Instalar las extensiones del IIS 6.0 para framework 2.0

C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Aspnet_regiis -i

y listo , ahora podemos usar nuestras más flamante aplicación en ASP.Net 2.0. pero....

cuando queremos usar las aplicaciones ASP.net 1.1 vemos que mucha de ellas directamente no funcionan, sobre todo si dependen del machine.config, pues desde ahora el isapi del ASP.Net buscará la configuración en el machine.config del 2.0 y no del 1.1.

Solucion.

Se debe asociar los scrips maps del IIS para que la aplicacion siga corriendo con el framework 1.1

El siguiente comando instala los scrips maps apuntando a las versión asociada a aspnet_regiis.exe (en ejemplo es el 1.1) con la aplicacion SampleApp1 y todos sus subdirectorios.

C:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\Aspnet_regiis -s W3SVC/1/ROOT/SampleApp1

Si quieren ver mas opciones, que mejor que los KB de Microsoft.
http://msdn.microsoft.com/en-us/library/k6h9cz8h(vs.71).aspx

En el siguiente blog esta detallado como solucionar este problema
http://imasters.uol.com.br/artigo/2839?cn=2839&cc=145

Diseño de arquitecturas I

2009-06-19T13:07:00.005-03:00

Joseph Hofstader en el Architecure Journal N° 15 indica que el diseño de la arquitectura de un software tienen 4 aspectos: Conocimiento del dominio, conceptualización, habilidades técnicas y habiidades para aplicar patrones. Los dos primero sería la etapa de definicion del problema y las dos ultimas formaria la etapa de desarrollo dela solución.

Indica que el conocimiento de la tecnología no los unico a manejar para diseñar aplcaciones robustas, pero si es una habilidad muy importante que tiene que tener el arquitecto de software. Dentro de la empresa se recomienda trabajar con la menor cantidad de tecnologias posibles, esto permite administrar el esfuerzo del desarrollo en forma más eficiente, reduciendo la cantidad de herramientas de administración, desarrollo monitoreo etc, teniendo grupos con menos perfiles técnicos etc .
Algunos de los los aspectos de calidad a tener en cuanta al momento de diseñar la arquitectura base de un sistema son altamente influenciado por la forma en que se implementa el diseño a nivel código. Por ejemplos aspectos de seguridad, performance y mantenimiento son altamente degradados sin se desarrolla sin seguir buenas practicas y aplicar patrones.
Para ello se debe tener adecuados controles de calidad, testear el codigo en forma periodica, dependiendo de la metodología de desarrollo adoptada, la integración continúa mediante el uso de herramientas permiten controlar al final del día que el código subido al repositorio notiene errores de compilación y además se pueden ejecutar revisione de código y pruebas unitarias automáticas. Si con esto se generar reportes se puede controlar día a día la calidad del código que se está generado.

Si no hacemos esto, cuando el codigo pasa a testing funcional, nos encotramos con cosas como SQL Harcodeados, store procedures gigantescos que no tienen ningun tipo de control en la cantidad de registros a enviar al cliente, armado de documentos (xml u otros tipo) concatenados strings (System.String) y en el peor de los casos codigo "chorizo" practimente imposible de mantener, datos de conexión harcodeados (aunque no lo crean) etc etc.

No se imaginan los problema de reworking y troubleshuting que surgen cuando se produce un incidencia con alguna de esas aplicaciones.

Arquitectura de Software: ORM, Object-Relational Mapping - I Parte

2009-05-31T16:11:00.000-03:00

Arquitectura de Software: ORM, Object-Relational Mapping - I Parte

¿(Des) Orientación a Servicios?

2009-05-29T18:15:00.003-03:00

Un tema analizado en el Microsoft Architecture Day de Buenos Aires es un tema que a mi criterio resulta polémicos, la aplicación de SOA en la práctica.

SOA y su aplicación práctica en grandes empresas, según el disertante SOA no tuvo el exito esperado debido a multiples factores. La misma conclusión expresó Wilson Chelsa de Microsoft pero desde el punto de vista de retorno de inversión, modelos de beneficios etc.

- SOA resultó ser muy complejo de implemementar.
- La industria en general no se alineo a la filosofía de SOA en sus procesos de negocio.
- Requiere gran inversión en el cambio cultural de la organización.
- En sus etapas iniciales no existían servicios laterales de importancia cmo registry, governance etc.
- Las implemetaciones muchas veces no tuvieron los resultados esperados porque fue muy dificil adecuar la cultura del negocio a la folosofía SOA.
- Aún continua la discusión acerca de la granularidad de los servicios, pues si es muy granular se corre el riesgo de no exponer servicios de negocio, poco granular surge que es muy poco reutilizable. En mi experiencia los servicios expuestos muy pocas veces son reutilzables.
- El tema del versionado también está es discusión.
- El desempeño de las implementaciones SOA resultaron ser muy costosas por su grano grueso, muchas capas, gran overhead en sistemas laterales.

El disertante introdujo el concepto de (Des)SOA:
- Reducir la cantidad de capas lógicas y físicas.
- Framework como helpers externos en lugar de contenedores.

Actualmente la nueva arquitectura de Microsoft sobre sistemas distribuídos en clouds Azure, utilizan un modelo con menos capas en donde expone los servicios en forma independiente. Evidentemente es un tema para discutir en profundidad.

Este tema da para un interesante discusión.

Microsoft Architecture Day

2009-05-27T18:37:00.002-03:00

En el día de hoy se hizo la reunión de la Comunidad de Arquitectos de Microsoft. Fue una reunión muy interesante en la que gente de Microsoft y otra empreass presentaron sus experiencias en soluciones de sistemas utilizando las últimas tecnologías de Microsoft,también se presentaron nuevos feactures de tecnologias como Windows 7 , WPF , Siverligh etc. Los asistentes pudieron preserciar presentaciones como:

Andres Vetori y equipo de VMBC Caso de exito de un sistema con .Net 3.5 SP1, WCF, Retina.Net ,Geneva framework, AOP, IVR con Speech Server 2007 entre otra tecnologías. Fue un proyecto contruido utilizando la metodología Agile / Scrum.
Como herramientas de desarrollo utilizaron Team System con integración continua en base a Team Build y deploy con scripts de MSDeploy.

Conclusiones generadas del proyecto:
- Es deseable automatizar las implementaciones en producción
- Adaptar la metodología de desarrollo a las particularidades del proyecto.
- El merge continuo no es siempre justificable.
- Se debe tener un adecuado control de los builds y que objetos contiene cada iteración.

Recomendaciones para un exito de un proyecto de este tipo:
- Virtualización (Hiper-V).
- Equipo con buen señority.
- No reiventar la rueda (patrones, frameworks etc).
- No subestimar el test (automzatizarlo y controlar su correcta ejecución como entregable de la iteración).
- No olvidarse del monitoreo.
- Tener un adecuado procedimiento de control de cambios.
- Mantener una cultura de motivación para hacer las cosas bien hechas.
- Crear una cultura de calidad continua.

Diego Gonzales de lagash presentó una visió de las tendencias en arquitectura de software

- Arquitecturas elásticas
- Base de datos no relacionales.
- (des) orientación a servicios.
- Programación dinámica.

En el tema de arquitectura elástica se vió consideraciones sobre escalabilidad en ambientes Cloud, planificación de arquitectura y modelos de arquitectura.
Diego presentó el concepto de que las arquituras deben ser emergentes y no prescriptivas, es decir se deben diseñar en conjunto con el desarrollo del sistema.

Dentro del tema de escalabilidad horizontal existe el nuevo paradigma de Microsoft que es Azure y el sistema operativo Windows Azure, creado para aplicaciones distribuidas en infraestructura Cloud. La escalabilidad vertical ya está llegando a su límite.
Para scar provecho a este nuevo paradigma es necesario especialización en programación concurrente.
Respecto a la planificación de arquitectura Diego mencionó que en muchas ocaciones conviene que el diseño de la arquitectura sea emergente en vez de prescriptiva, haciendo participar al aquipo de desarrollo ensu definición, esto tiene la ventaja de motivarlos en la creación de la misma y el desarollo del sistema y permite un mejor refinamiento mientra se crea el sistema.
Planteó conceptos de modelado de arquitecturas que pueden ser centralizadas o satelitales.

Un tema que recordó es que por lo general es una desición por defecto que la base de datos a utilizar sea del tipo relacional, esto no siempre es una correcta elección, hay casos donde se requieren datos temporarios, no es tan exigible que sea transaccional en donde la RDBMS no resultan ser lo más apropiado. Ejemplos de uso de este tipo de base de datos son aplicaciones del tipo redes sociales como Facebook.
Las bases de datos no relacionales tienen entre otras las siguientes características:

- key-value db y document db.
- Buen soporte para lenguajes dinámicos.
- Facil cambio en la aplicación.
- Datos a-normalizados. etc.

Productos: SQL Services, Drizzle,Amazon WebServices etc.

Windows Communication Fundation

2009-05-25T17:01:00.001-03:00

El WCF fue dado a la luz junto con el framework .Net 3.0 en 2006. En ese momento existían addíns para el Visual Studio 2005 que permitían generar proyectos WCF en forma simple, muchas de esas herramientas eran beta, y se debían usar un poco por linea decomandos y un poco dentro del VS2005,algo muy poco práctico para implementar en una empresa o sector de desarrollo de software.
No voy a describir los problemas que tuve con el desarrollo de proyectos WCF en VS2005 pues el el Visual Studio 2008 incluye todas esas herramientas que se debian agregar a la anterior versión del IDE pudiendo generar proyectos WCF en forma mucho más simple.

Para aquellos que aún no han trabajado con el WCF o necesitan una capacitación de diferentes aspectos que provee esa tecnología les sugiero los siguientes recursos. Los WebCasts están basado enel Visual Studio 2008, por ese motivo es conveniente usar ese entorno.

En ingles
WCF Getting Started
http://msdn.microsoft.com/en-us/library/ms734712.aspx

Microsoft Windows Communication Foundation Step by Step, John Sharp
Disponible para su compra en Microsoft-Press

http://www.microsoft-press.co.uk/scripts/product.asp?ref=811252

O bien en librerias online como http://www.books24x7.com

Pro WCF: Practical Microsoft SOA Implementation

by Chris Peiris, Dennis Mulder et al.
Apress © 2007 (505 pages) Citation
ISBN:9781590597026

Providing coverage of the unified programming model, reliable messaging, security, peer-to-peer programming, and more, this is a complete guide to WCF from the SOA architecture perspective and shows why WCF is important to web service development.
(este aun no lo lei,pero me parece muy interesante)

En Portugues (Brasil)

MSDN Webcast: Melhores práticas no uso do WCF
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032409560&flag=3

Webcast Arquitetura: Arquitetura Orientada a Serviços: WCF Boas práticas (do levantamento, construção e hospedagem
https://msevents.microsoft.com/CUI/EventDetail.aspx?culture=es-ar&eventid=1032415471&flag=3

¿Por qué es necesario un arquitecto de software?

2009-05-19T11:11:00.002-03:00

“Architecture in an over used term and therefore doen’t mean anything anyway”

“Oh we don’t need training, we are Enterprise Architecture”,

“Help I need to hire architects but cannot define the role”, HR manager

“Why should I hire architects?, No one has ever made the case to me ”, CEO

“Architects just vision jockeys right?, We need coders no talkers”, developer manager

Estas frases fueron recolectadas de varias conferencias sobre arquitectura de software, encuestas y otros eventos de IT [Preiss Paul T, 2006, “Magician apprentice”] e indican en grado de confusión que existe respecto a la arquitectura de software, entonces como arquitectos es importante tener una buena respuesta a la siguiente pregunta: ¿Por qué es necesario un arquitecto de software?

Los sistemas de información soportados por aplicaciones informáticas son cada vez más comunes y en muchos casos imprescindibles para el funcionamiento del negocio de la empresa. En estas últimas dos décadas la evolución de esos sistemas fue exponencial y además los procesos son más complejos y la tecnología permite hacer más cosas en forma más sencilla y más rápida. Este aspecto tiene el riesgo de crear grandes sistemas en forma relativamente simple y rápida sin tener el adecuado control en la calidad, el costo de esto es grande a la hora de mantener el sistema, de solucionar errores y fallas y de evolucionarlo para agregar nuevas funcionalidades.

Standish Group en su “Chaos Report” describe un estudio realizado sobre mas de 175000 proyectos en donde los resultados no fueron nada alentadores. La siguiente tabla indica los valores promedios de sobre costo, exceso en tiempo y baja satisfacción de la funcionalidad del producto con los deseado.

Parámetro (exceso sobre los estimado)	% promedio
Costo	189%
Tiempo	222%
Deficiencias en el producto final	60%

De los proyectos relevados solo el 12% terminó en tiempo y dentro del presupuesto asignado.

La investigación mencionada incluye el resultado de un encuesta entre algunos de los CIOs de esas empresas preguntando cuales serían los aspectos que se deberían mejorar para reducir estos indicadores en los proyectos. De esa encuesta surgió que los tres principales factores a mejorar fueron un mejor involucramiento del usuario, mejora en la administración del proyecto y tener requerimientos claros y bien documentados.

En cambio si consideraban que aspectos perjudicaban el éxito del proyecto se consideraron como prioritarios aspectos tales como malas de comunicación con el usuario, requisitos y especificaciones incompletas y cambios constantes en especificaciones y requerimientos.

De este análisis se describe que es muy importante tener una buena planificación, documentación de requisitos y especificaciones y fluída comunicación con el usuario para tener éxito en el desarrollo del software. Los cambios en las especificaciones y requisitos son imposibles de detener pues muchas veces son causa de cambios en el contexto del negocio que las crearon, por eso una buena planificación y requisitos bien documentados mitigan este riesgo, además si se trabaja con un entorno de trabajo estable, bien documentado que resuelva las tareas rutinarias, de mayor complejidad y administradas por la menor cantidad de roles posibles se mitiga en gran medida los riesgos en todas las etapas del desarrollo del software.

Por este último aspecto es que se necesito un grupo de arquitectura, pues interviene en como un grupo staff en todo el ciclo de vida del desarrollo, definiendo estándares, buenas prácticas, ofreciendo soporte, coaching al desarrollo y diseño, metodologías, frameworks (conceptúales y ejecutables): Participan también en definiciones o adopción de metodologías de desarrollo de administración de cambios que faciliten la tarea de los de más integrantes del equipo de desarrollo y de los stakeholder .

Por lo tanto necesitamos arquitectos para afrontar la complejidad de los sistemas, para ofrecer agilidad en los negocios, para reducir los costos en IT, para mejorar la alineación del área de IT en los negocios etc .

Como se habia mencionado las soluciones de software distribuidas sueles tener una alta complejidad, esa complejidad puede ser inherente a la tecnología y la especificación funcional del negocio o bien puede ser accidental. Muchos procesos de negocio presentados como complejos luego de una buen análisis se pueden simplificar, es importante recordar que los sistemas se basan en los procesos y no lo procesos a los sistemas, por lo tanto dedicarle tiempo a optimizar los procesos de negocios a ejecutar es fundamental en la etapa de inicio pues la construcción de los sistemas se basarán en esos procesos. El arquitecto debe tener la habilidad necesaria para entender el proceso, el problema y crear un modelo que se ajuste al mismo.

En cambio, la complejidad accidental está muy relacionado con las tecnologías y estilos de las arquitecturas elegidos. Una tarea muy importante que debe cumplir el arquitecto es la determinación de aspectos no funcionales de la arquitectura, tales como flexibilidad al cambio, mantenimiento, escalabilidad, reusabilidad, usabilidad, monitores, performance , seguridad etc.

Cuando se tienen definidos estándares de calidad no funcionales y restricciones tecnológicas impuestas por políticas de la compañía muchas veces la arquitectura puede ser más compleja porque se debe alinear a las mismas.

Además tiene que considerar políticas tales como restricciones debido a estándares externos, como por ejemplo SOX , internos de negocios , regulaciones gubernamentales etc.

El cumplimiento de estos conceptos permite reducir costos de IT, mejorar la satifacción del cliente interno proveyendo para el primer caso mejores herramientas que faciliten las tareas del personal de la empresa dedicada a la operatoria diaria del negocio y áreas relacionadas. Estas mejoras también benefician a los clientes externos puer les permite disponer de mayor control en sus pedidos, despachos de los productos adquiridos.

Arquitectura de Software

2009-04-20T15:39:00.001-03:00

Continuando con el tema, posteo este sitio de una empres de Argentina con mucha informacion referente

http://www.epidataconsulting.com/tikiwiki/tiki-index.php?page=Arquitectura%20de%20Software

Micaela, en su primeras vacaciones.

2009-01-26T11:41:00.001-02:00

Arquitectura de Software

2008-10-09T15:21:00.000-03:00

Ultimamente se habla mucho de un nuevo rol en los profesionales de IT que es el de arquitecto. Uno por lo general asocia esa palabra con la de Arquitecto de contrucciones, pero el mundo IT esmuy diferente.
Planteo algunas dudas

1- ¿Qué es la Arquitectura de Software? Introducción, clasificación, historia, comparación con la arquitectura en contrucciones.
2- ¿Cuál es el rol de un arquitecto de software clasificados según el tipo de industria, tamaño de la empresa, metodologías de desarrollo utilizadas y grado de madures en aplicación de estándares de desarrollo de software?
3- ¿Cuál es la currícula a seguir para que un profesional de sistemas de información sea considerado un arquitecto de software?
4- ¿Cuáles son los estándares aplicables a la arquitectura de software?

Continuare con post para tratar de responderlas.

Micaela

2008-10-09T15:16:00.001-03:00

Ahora con 18 meses, hiperconcentrada con un juego.

Primer cumpleaños de Micaela

2008-03-13T13:30:00.000-02:00

Las fotos lo dicen todo

Ceferino

2007-12-08T10:24:00.001-03:00

La otra historia o la verdadera historia?"

¿Cómo llamamos esto? ¿Una cachetada más? ¿Otro atropello? ¿Otra maniobra macabra para justificar lo injustificable? Sí... es todo eso, más todo lo que podemos decir y testimoniar los pueblos originarios ante tanto avasallamiento, persecución y "evangelización". Asumo la total responsabilidad de lo que digo, y con toda la documentación en mano que da testimonio de lo expresado.

Ceferino Namuncurá "santo". ¡No! Ceferino fue y es un fiel reflejo de la espiritualidad natural de nuestra pasión mapuche. Todo nuestro pueblo fue y es así, a pesar de que nos impongan y sigan marcándonos con la cruz y otros "santos sacramentos" de la Iglesia, que sabemos y sentimos es una vulgar u otra vulgar y nefasta muestra del gran poder que ejerce este organismo. Agreguemos aquí que si bien los pueblos originarios sufrimos esto, también lo sufren los humildes, obreros, campesinos, etcétera, si no, remontémonos sólo a 30 años atrás, cuando este poder bendecía las armas y a los criminales que mataban a nuestros hermanos, no sólo indios, sino a todo aquel que exigía respeto, derechos e igualdad y no se sometía a la injusticia, al saqueo o a la hipocresía de unos pocos poderosos... es decir, no ponía "la otra mejilla".

Aquí sí rescato a Cristo como el primer revolucionario de la historia. ¡Oh casualidad!, a él también lo mataron, justamente porque luchaba y quería que todos fuéramos iguales y tuviéramos las mismas oportunidades. Pero claro, la Iglesia acomodó esto a su antojo y conveniencia, como siempre. Sí, existieron algunos curas -muy pocos- que se jugaron por sus ideales y su gente. ¡Pobre Cristo! ¡Cuántas veces lo crucifican sus mismos "fieles seguidores"!

Con Ceferino pasó algo igual; nació y heredó el poder espiritual de los Namun-Cura, su destino dentro de nuestro pueblo era el de machi, por eso esa aparente mansedumbre. Poseía la capacidad de reorganizar nuestro pueblo, podía curarnos de las heridas internas que nos habían dejado los valientes conquistadores, llámense Colón, Roca u otros. Por estas cualidades de seguro lo captó la Iglesia; valiéndose de los eternos "espejitos de colores" logró arrancarlo de su comunidad e incorporarlo a su "grey". Por supuesto; la sangre derramada y la fuerza ancestral que fluía en él no lo abandonaron. Sí, sufrió, padeció el cruel desarraigo, tan lejos de todo lo amado, de su tierra, que para el indio es su cuna y su tumba. Lejos de esto, que era su esencia, se enfermó; su mente se enfermó y, por lo tanto, su cuerpo. Solo, lejos, enfermo, fue confinado a morir abandonado en una habitación. ¡Ah! Eso sí, ¡en la casa de Dios! Sí se cuidó que nadie se acercara a él, no fuera que se contagiaran de tuberculosis algunos de esta "casta privilegiada".

¡Santo! ¿De qué estamos hablando? ¡De Ceferino Namuncurá, noble señor de las pampas, hijo de un noble e integrante de un pueblo valiente e indómito nunca vencido! Tal vez le cortaron las ramas, le talaron el tronco, pero ¡jamás le arrancaron las raíces! ¡Somos un pueblo-nación libre, con ideales nobles y una espiritualidad que nos hace distintos y respetables!

Se debe respetar el don maravilloso que poseemos de tener el color de la tierra, la fuerza del viento, el calor del sol. Se debe respetar nuestra rica cultura; respetarla, no robarla o quitarla. ¡No queremos que nos sigan imponiendo una cultura ajena, pobre y materialista! Somos de la orgullosa estirpe mapuche, Ceferino es de esta estirpe, tiene aún un camino que nos marcará llegado el momento, el cual seguiremos. Será cuando haga surgir desde el fondo mismo de la tierra una roja daga que surcará el espacio hasta llegar a los mal paridos protagonistas de esta nefasta historia de imposición y saqueo. Dejará nuestro espíritu sereno y puro de todo interés monopólico que atente contra nuestro pueblo y nuestro espíritu.

No olviden ni pasen por alto esto: estamos de pie, no nos vencieron. Tenemos intacta nuestra capacidad de organización. Ceferino es el baluarte de la verdadera emancipación americana. Ésta es la voz de mi pueblo-nación mapuche. Quedará seguro en el camino tanta hipocresía, tanta soberbia; quedarán en el camino los mal paridos, reflejos fieles de las imposiciones y nefastas "marcas". No queremos ni creemos en los "espejitos de colores". ¡Tal vez ustedes lleguen a necesitarlos, guárdenlos por si acaso!

Telésfora Pichilef, DNI 4.270.366 - Maquinchao

Por suerte no le hizo caso

2007-12-05T11:17:00.000-03:00

Señor rey Juan Carlos de Borbón:

Quiero recordarle, señor rey de España, que aquí en estas tierras llamadas las Indias Occidentales por los primeros invasores, hubo hace poco una espantosa, cruel y fierísima guerra contra ustedes y precisamente para desconocer su corona, su voz, su mandato. Fue una guerra reciente y aún estamos pagando sus horribles consecuencias. De modo que no pensábamos más, en estas tierras, tener que darle cuentas a usted de nada de lo que hacemos en estas regiones. No tenemos aquí reyes en América, y nuestro Libertador Simón Bolívar despreció en todo momento ese título, además de desconceptuar y echar al desprecio a quienes quisieron convertirlo en monarca.

Somos libres, republicanos y socialistas, señor rey, y el único soberano entre nosotros es el pueblo. En verdad que hemos venido luchando desde hace siglos para no tener nunca más entre nosotros una voz despótica y agresiva como la que usted usó en la última Cumbre Iberoamericana, en Chile. Usted, además de no ser verdaderamente miembro de esta comunidad, por no ser elegido por pueblo alguno, debe también recordar que aquí ya no existen vasallos suyos. Yo, señor rey, provengo de aquellos que indios y negros que sufrieron los destrozos de los demonios voraces que aquí enviaban sus ascendientes. Y aún viven en mí, sus ayes, sus dolores, sus temblores de ira y el deseo de vengar tantas atroces matanzas y afrentas. Usted, señor rey debe recordar esto en cada instante, a aquellos demonios a los que se les abrió un apetito de muerte sin límite ni medida, y acabaron con nuestros indígenas y llenaron de pestes, odios, maldades y esclavitud por más de 300 años estas tierras. Señor, ¡qué categoría de fieras aquéllas!, ¡qué joyas de tan elevados pedigrí!, que en pocos años había suficiente crímenes y desastres entre nosotros como para dejar pálidos a cuantos cometieron juntos Atila, Caligula, Nerón, Hitler o Franco.

No tenía usted por qué estar allí, entre nosotros en esa Cumbre, quienes sufrimos el holocausto de las monstruosas acciones de sus tatarabuelos. Entienda señor rey que nada aportaron ustedes a la causa humanitaria de nuestros pueblos. Nos dejaron durante siglos sin educación, sin justicia, sin instituciones, sin disciplina, sin sentido de hermandad ni valores humanos de ningún tipo. Lo que quedó aquí fue un grito horrible que usted ha revivido en Chile y que nos llega hasta más allá de los tuétanos: “¡A callar, a callar, a callar!”

¡Ay, rey, que poco sabes del dolor que hay en nosotros! Un dolor que cubre todo el tiempo de la humanidad. Señor rey, usted se ha expresado como lo que es y han sido todos tus parientes. Sólo le voy a poner aquí, digno monarca de sus antepasados, unas palabras de Bolívar para que las enmarques y las lea todos los días, y para que también se las envíe a su querido José María Aznar: “Un continente separado de la España por mares inmensos, más poblado y más rico que ella, sometido tres siglos a una dependencia degradante y tiránica… Tres siglos gimió la América bajo esta tiranía, la más dura que ha afligido a la especie humana… El español feroz, vomitado sobre las costas de Colombia, para convertir la porción más bella de la naturaleza en un vasto y odioso imperio de crueldad y rapiña… Señaló su entrada en este el Nuevo Mundo con la muerte y la desolación: hizo desaparecer de la tierra su casta primitiva; y cuando su saña rabiosa no halló más seres que destruir, se volvió contra los propios hijos que tenía en el suelo que había usurpado.”

Un hombre, señor rey, que escriba así, es porque lleva sangre india y negra en sus venas.

El indio Bolívar, en negro Bolívar, el mulato Bolívar, ese es el que cada venezolano lleva hoy en su sangre, en sus nervios, en su corazón.

Larga paciencia hemos aguardado esperando este momento de hoy en el que somos libres, y gracias a Dios no tenemos que entregarle cuenta a ningún soberano extranjero, y España nos importa menos que un comino. Allá ustedes que siguen sometidos a vírgenes de siete puñales, a los toros, al fútbol, a los cantantes espantosamente sifrinos y a los cotilleos de las revistas del corazón. Que les aproveche, pero aquí nunca nadie jamás callará, señor rey.

Ya debe saber, pues, señor rey, por qué no me callo ni nadie podrá callarnos, que hemos venido a decir nuestras verdades que son las mismas que Bolívar proclamara hace unos ciento noventa años. Que esa misma imprecación suya fue la que se impuso el día del golpe del 2002, cuando todos los medios poderosos (que también son suyos) que le aman y le veneran con pasión pesetera, pretendieron acallar la voz del pueblo. Ya aquí no hay Cristo que nos pueda hacer callar.

Aquí, señor rey, a lo único que veneramos es la libertad del pueblo. No obedecemos a aristocracia alguna sino al talento creador, al amor y a la igualdad. Si no se excusa ni pide perdón a la ofensa hecha a la majestad de lo que el pueblo en tres elecciones ha ratificado, habrá usted sencillamente hecho honor a la soberbia que tanto caracteriza a los monarcas que cada cincuenta años sumergen a España en horribles guerras fraticidas. Ya hemos dicho lo en este caso teníamos que decir.

Sin otro particular,

Hugo Chávez Frías

Presidente de la República Bolivariana de Venezuela

Informatica y la calidad de atencion medica (una breve reflexion)

2007-11-16T22:04:00.000-03:00

En las últimas décadas hubo un proceso de transformación en varios países de América Latina y España tendientes a la búsqueda de un acercamiento a las necesidades de salud de la población, con la creciente búsqueda de la equidad en la atención en los servicios médicos.
La atención primaria de salud se convirtió para la OMS en un concepto fundamental a raíz de la Declaración de Alma-Ata de 1978, en que se adoptó la meta de la salud para todos, sobre todo a las poblaciones menos favorecidas (OPS, 1978).
En los sistemas de salud tanto públicos como privados existen procesos de manipulación de información necesarios para el funcionamiento de los mismos, estos sistemas incluyen entre otros la administración de turnos, de historias clínicas, de inventario de farmacia, manejo de resultados de laboratorios (Sigulem, 1997). Según estimaciones el procesamiento de la información ocupa aproximadamente un 25% de las actividades de los profesionales de la salud .
Por lo tanto es importante que estos sistemas se manejen con eficiencia y eficacia para garantizar la accesibilidad y equidad en los servicios prestados.
La mejora de los mismos podría ayudar a aumentar la calidad de atención médica y la satisfacción de los usuarios internos y externos.
La informática médica permite manipular datos y de estos datos se puede obtener información, esa información proporciona una ayuda al profesional médico para reducir la incertidumbre frente a los problemas del paciente , y ayuda a la toma de decisiones.
Dado que esta información está vinculada a seres humanos la manipulación de la misma debe seguir ciertas normas de ética aplicables tanto a los profesionales de la salud como de la informática médica (IMIA).

Micaela, ahora con 8 meses de vida

2007-11-16T22:00:00.001-03:00

Nuestra princecita

2007-02-26T13:22:00.000-03:00

El martes 20 de febrero nacio Micaela Belen, nuestra primera hija.
Nacio con 3,150 kg y tanto ella como la madre estan bien de salud.

Atencion primaria de la salud

2006-08-10T11:58:00.000-03:00

En la ultimas decadas hubo un proceso de transformación en varios paises de América Latina y España tendientes a la búsqueda de un acercamiento a la necesidades y de demás de la población, con la creciente búsqueda de la equidad en la atención en los servicios médicos.

La Conferencia Internacional sobre Atención Primaria de Salud, realizada en 1978 en Alma Ata (Kazajstán), en la antigua URSS, supuso un potencial avance mundial en los derechos sobre la salud.

La pueden leer en castellano en

http://www.femeba.org.ar/fundacion/quienessomos/Novedades/declaracionalmaata.pdf

Informatica medica

2006-08-10T11:41:00.000-03:00

La informatica medica IM es una rama d ela informatica encargada de la maniupulacion, almacenamiento, comunicacion de informacion referente a la salud , datos biologicos, historias clinicas, señales e imagenes biologicas etc. En el sistema publico de salud tiene como principal finalidad mejorar la accesibilidad de los servicios de salud.

Existen varias asociaciones que se dedican a difundir, normalizar y promocionar esta rama de la informatica
En Argenitna tenemos ente otras al Grupo de Bioingenieria de Buenos Aires www.gibba.org.ar y la Asociacion Argentina de Informatica Médica www.aaim.org.ar.

En España existe la Sociedad Española de Informatica en Salud www.seis.es.

De mis incipientes investigaciones el pais latinoamericano que mas invierte , desarrolla y promueve la IM es Brasil, instituciones como la Escolha Paulista de Medicina www.epm.br desarrollaron interesantes trabajos al respecto.
Desde lso profesionales y asociaciones apoyada por el gobierno (por suerte se continuo luego de varios cambios) se trabaja son Sistema Unicao de Salud SUS que intenta mejorar la calidad de atencion medica en el extenso territorio de Brasil tratando de llegar a sus mas de 180 millones de habitantes, ardua tarea.

Algo que aun no existe en Argentina, la informacion gubernamental referente a indicadores de salud, demograficos, economicos etc son de libre acceso (el INDEC Argenitno solo publica indicadores globales, los demas hay que pagarlo).

Solo miren www.datasus.gov.br para verificar lo que digo.

Viaje por el NOA Argentino

2006-03-02T12:20:00.001-03:00

Les comparto algunas fotos de nuestra luna de miel en el NOA Argentino Es muy recomendable para aquellos que les gusta la natuleza y conocer la historia de nuestra argentina.

Anfiteatro de Cafayate al sur de Salta.

Petroglifos camino a las cascadas en Cafayate.

Saliendo de la ciudad de Cafayate se accede luego de 10 Km de recorrido a la zona de viñedos y bodegas, desde allí con la ayuda de guias locales se sube a pie a través de los cerros hasta llegar a las cascadas. La de la foto es la primera y se llega luego de mas de 2 hs de caminata, los paisajes que se ven durante el trayectos son espectaculares, es una excursión recomendada para todo aquel que visite esta ciudad del sur de Salta.

Cuesta de Lipan - Viajando por encima de las nuebes

Desde San Antonio de los Cobres (Salta) viajado hacia el Norte se recorre un camino de tierra en una zona muy arrida. A una hora de viaje esta en limite en entre Salta y Jujuy, de alli ya se ven las maravillosas Salinas Grandes, estas forman una
planicie de Sal de varias miles de hectareas.
Por alli cruza una ruta que hacia el Oeste se puede cruzar por el paso de Jama a Chile y por el este se ingresa luego de varios kilometros a la maravillosa Cuesta de Lipan (en honor el pueblo que está el final de la misma).
Esta cuesta es un camino serpenteante que en su punto maximo llega a los 4170m snm. Aqui estamos en el punto mas alto literalemtne sobre las nubes (es paisaje es increíble).
Luego de Lipan se puede llegar a Purmamarca (es un camino muchos mas largo que llendo desde San Salavador e Jujuy, pero para los amantes de los paisajes y los cerros es lo ideal).

Purmamarca - El pueblo del cerro de los 7 colores.

Desde San Salvador de Jujuy , camino a Humahuaca se accede a este maravillo puble insertado entre los cerros que entre otras cosas tiene este hermosos cerro de 7 colores.

Es ideal para tomarlo como punto de hospedaje y de allí hacer excusiones hacia las Salinas Grandes, Tilcara, Humahuaca (y de alli a Iruya).

Es el paraiso de la gente que le gusta la tranquilidad y la naturaleza, tambien de los hippies y aventureros de todo el mundo.