Tip para el SoapUI

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

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

 

Arquitectura de software, rol e integracion de aplicaciones

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

 

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

 

1. [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 
2. [Hofstader Joseph, 2008], “We Don't Need No Architects”, Architecture Journal 15, http://msdn.microsoft.com/en-us/architecture/cc505974.aspx

 

 

 

Tutorial de Linq

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)

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>

.....

<bindings>

<basicHttpBinding>

<binding name="BasicHttpBinding_IService1">

<security mode="TransportCredentialOnly">

<transport clientCredentialType="Windows" />

</security>

</binding>

</basicHttpBinding>

</bindings>

<services>

<service behaviorConfiguration="WCFTest.ServiceBehavior" name="WCFTest.Service1">

<endpoint address="" binding="basicHttpBinding" contract="WCFTest.IService1">

<identity>

<dns value="localhost" />

</identity>

</endpoint>

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

</service>

</services>

<behaviors>

<serviceBehaviors>

<behavior name="WCFTest.ServiceBehavior">

<serviceMetadata httpGetEnabled="true" />

<serviceDebug includeExceptionDetailInFaults="true" />

</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>

.....

<serviceHostingEnvironment>

<baseAddressPrefixFilters>

<add prefix="http://<host header IP>" />

</baseAddressPrefixFilters>

</serviceHostingEnvironment>

The sevice and behaviors sections change too.

<service behaviorConfiguration="WCFTest.ServiceBehavior" name="WCFTest.Service1">

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

binding="basicHttpBinding"

contract="WCFTest.IService1">

</endpoint>

<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />

</service>

<behaviors>

<serviceBehaviors>

<behavior name="WCFTest.ServiceBehavior">

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

<serviceDebug includeExceptionDetailInFaults="true" />

</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

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

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