La arquitectura orientada a servicios no es una tecnología, sino una forma de hacer negocios. Ella podrá incluso modificar la forma en que se hacen negocios.

 

Moverse hacia SOA le constará tiempo y dinero, por lo cual el “driver” por el cual usted toma la decisión de hacerlo debe estar muy bien fundamentada. SOA incrementará su agilidad y eventualmente disminuirá sus costos de desarrollo de sistemas.

 

Para poder llevar adelante este cambio, y hacer lo correcto, usted debe hacer que la gente de IT cambie su forma de ver el negocio. Esto fuerza a que la gente del lado de negocio postergue oportunidades de corto plazo versus objetivos de largo plazo. Por otro lado la gente de IT debe cambiar su forma de ver los sistemas, pensando ahora en niveles de servicios y reusabilidad.

 

Definición de SOA

 

En palabras simples, SOA trasforma las funcionalidades de las aplicaciones en piezas de Lego. Toma una pieza de software con una interfaz bien definida y la pone a disposición de diferentes aplicaciones a través de un contrato de uso. Lugo usted puede construir nuevas aplicaciones como construye nuevas figuras de Lego, uniendo las piezas.

 

Esto suena a juego de niños, sobre todo la parte Lego de los servicios. Debemos ser escépticos, SOA no soluciona todos los problemas ni es tan simple como suena.

 

 

La tecnología es dura, pero el staff es peor

 

Los precursores de SOA en una organización tienen claro que no será fácil cambiar la inercia de “la forma como hacemos las cosas”. Por eso la mejor aproximación es tomar pequeños procesos de negocio de alto impacto y llevarlos a SOA. Siempre la decisión de que pieza del proceso de negocio será transformada, se debe tener en mente el riesgo y retorno de la inversión.

 

Lo que se espera como resultado inmediato es que la pieza llevada a SOA reduzca la complejidad de integración y mantención. Esto impacta directamente los costos operacionales del sistema.

Hola,

 

Un cliente me preguntó ¿Tienes Links de buenas prácticas?

 

Yo dije “…por supuesto, miles de millones..”

 

Así que me puse a googlear, no fue nada fácil. Todo el mundo habla de las mejores prácticas pero nadie las explica, clasifica, desarrolla etc.

 

Así que hablando con diferentes personas y consultando en foros llegué a esta lista de mejores prácticas para ASPNET.

 

 

Poderosa recopilación de links

 

http://weblogs.asp.net/Varad/archive/2005/09/25/425938.aspx

 

Buenas prácticas organizadas como el ciclo de vida (10 eventos) de ASPNET.

 

http://www.aspfree.com/c/a/ASP.NET/ASP.NET-Life-Cycle-and-Best-Practices/

 

Para aplicaciones escalables y rápidas

 

http://msdn.microsoft.com/msdnmag/issues/05/09/SessionState/default.aspx

 

http://www.codeproject.com/useritems/ASPNET_Best_Practices.asp

 

http://www.codeproject.com/csharp/effective1.asp

 

Mejores prácticas de PAG, diferentes guías.

 

http://msdn.microsoft.com/practices/guidetype/Guides/default.aspx

Cuando escribí el post sobre “Arquitectos que andan a 10.000 metros”, lo hice para promocionar una conferencia para Developer que bajaba la propuesta de arquitectura en capas a directivas de diseño para Developer.

 

Diegum, ex arquitecto de Microsoft Chile lo tomó muy en serio y escribió un POST de comentario sobre el mío. No era mi intención pero creo que esto está siendo muy positivo porque genera dialogo sobre el verdadero rol de un arquitecto de software.

 

Primero,  creo que el concepto de arquitecto de software está sobre utilizado. Es algo similar al titulo de ingeniero, en Chile existe ingeniería en Marketing o ingeniería comercial, por ejemplo.

 

Coincido con diegum en su definición de Arquitecto cómo “El arquitecto de software es un administrador de la complejidad, lidia con ella todo el tiempo”. Ahora, en clases de arquitectura de software, en la universidad es posible encontrar cursos de cualquier cosa, me dijo mi profesor que la arquitectura de software “habla del software que se va ha hacer” y que el diseño “baja como esa arquitectura se implementa”.

 

Ahora, revisando la lista de tareas que nos propone diegum para los arquitectos de software tenemos:

 

• Descomponer la aplicación en capas, al menos, lógicas
• Descomponer cada capa lógica en componentes
• Seleccionar tecnologías y/o frameworks de implementación
• Realizar una Prueba de Concepto (Proof of Concept o PoC) de la arquitectura
• Brindar algunos casos de uso de referencia

 

Si un Arquitecto de software hace eso, me sentiría muy contento. Ahora creo que esa felicidad sería máxima si agregamos lo siguiente:

 

En “descomposición lógica en componentes” apoyaran a los diseñadores dando directivas claras de cómo bajar la arquitectura del sistema a un diseño de software codificable por Developer.

 

Ocurre que muchas veces no existen diseñadores de software, por lo que nadie hace este trabajo. Esa es mi principal observación a los arquitectos  de "coloquios de café".

 

Yo no creo que sea importante para un Arquitecto de Software saber programar en la tecnología que se use en estos momentos, si es impórtate que tenga experiencia y habilidades de comunicación que le permitan hacer un “puente de plata” entre el negocio, Driver de toda empresa, y el equipo de desarrollo.

 

 

PD:

Como siempre, saber programar y gustarme mucho hacerlo, me trae problemas 😉

La semana pasada, junto con David, dimos una conferencia técnica de un tema que no es de visión sino fundamental. Repasamos los conceptos necesarios en el desarrollo de aplicaciones en capas.

 

Nuestra apuesta es que todo el mundo habla en alto nivel de este tema pero que no existe un real entendimiento entre los Developer. Esto no por falta de interés o capacidades sino porque los Arquitectos de Software cercanos tienen facilidad para hacerse entender con los Stakeholder pero muy poca práctica en bajar en diseños concretos sus ideas hacia los Developer.

 

En esta conferencia mostramos una herramienta muy buena para generar código llamada CODESMITH (http://www.codesmithtools.com/ ). En particular el Script http://www.nettiers.com/  para generar un modelo ORM a partir de una base de datos.

 

 

Algunos de los links recomendados en la conferencia son los siguientes:

 

·         Arquitectura de aplicaciones de .NET: Diseño de aplicaciones y servicios

http://www.microsoft.com/spanish/msdn/arquitectura/das/guias/AppArchCh1.asp

 

·         Designing Data Tier Components and Passing Data Through Tiers

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/BOAGag.asp

 

·         .NET Data Access Architecture Guide

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/daag.asp

 

·         3-tier architecture in C# By Rahman Mahmoodi
http://www.codeproject.com/csharp/three_tier_architecture.asp

 

Enjoy

Conceptos importantes

 

• Autentificación: Proceso de verificar la identidad de una persona.
• Autorización: proceso de permitir el acceso de una persona a un sistema.
• Credenciales: El juego de artefactos usados para proveer la identidad a un cliente.

Introducción

 

En la historia de la física Albert Einstein resolvió las 3 preguntas que hasta ese momento quitaban el sueño a los físicos de finales del siglo IX y principios del siglo XX, pero al hacerlo dejo al descubierto muchos nuevos desafíos para los físicos modernos.

 

De una manera análoga, los Web Services vinieron a solucionar los 3 problemas fundamentales de la interoperabilidad de sistemas. Esta tecnología resolvío los problemas de descripción de los contratos de los servicios (WSDL), la invocación de procedimientos (SOAP) y la interoperabilidad entre plataformas (Uso de XML). Al utilizar está solución, los desarrolladores se enfrentaron a nuevos problemas  generados por el uso de está tecnología. Algunos ejemplos de los esos problemas son seguridad, desempeño, manejo de contextos trasnacionales y confiabilidad, por nombrar algunos.

 

En esté articulo revisaremos los conceptos más importantes de seguridad en Web Services. Abordaremos los patrones de autentificación y protección de mensajes.

 

Patrones de autentificación

Los patrones de autentificación tienen como objetivo guiarnos en las decisiones de la aproximación con que nuestro sistema enfrentará el problema de la autentificación de los clientes que quieren usar los recursos expuestos por nuestros servicios.

 

En está sección veremos dos patrones fundamentales:

 

• Autentificación directa
• Autentificación indirecta (Brokered Authentication)

 

Ambas alternativas buscan solucionar el problema de identificación del cliente que hace uso de los recursos del Servicio Web. Cuando el cliente y servidor tienen una relación de confianza que les permite intercambiar y validar credenciales donde se incluye el password, el patrón de autentificación directa aplica perfectamente.

 

En un escenario en que el cliente y el servidor no tienen una relación de confianza, el camino es utilizar autentificación indirecta. En esta opción el cliente se autentifica contra un tercero (Broker) quien le entrega un Token al cliente para que lo entregue al Servicio cómo credencial. El Web Service toma el Token y lo valida con el Broker. Este tercero, llamado Broker, tiene relaciones de confianza con el cliente y el servidor.

 

Además de la razón de compartir relaciones de confianza entre el cliente y el servidor existen múltiples criterios que se deben tener en cuenta para la toma de decisión de cuál aproximación utilizar para la autentificación de los Web Services. Algunos de los criterios que se deben considerar al momento de evaluar son:

 

• ¿Qué necesita el servicio para autentificar al cliente? ¿Password? ¿Certificados? ¿Algo más?
• ¿El Web Services es capas de acceder al servicio de autentificación directamente?
• ¿Cuál es la infraestructura existente?
• ¿Es necesario soportar SSO?
• ¿Necesita la aplicación un contexto de sesión?
• ¿Estamos trabajando en el mundo Microsoft? ¿Tenemos Windows Impersonate?

 

Estas preguntas y más se deben tener en cuenta al momento de optar por un patrón de autentificación.

Autentificación directa

El escenario de la autentificación directa es que el Servidor Web espera del cliente las credenciales que él mismo validará con el servicio de autentificación (Identity Store).

 

El problema de está aproximación es el cómo el Servicio Web validará las credenciales presentadas por el cliente.

 

Las principales razones para utilizar autentificación directa son:

 

• Las credenciales presentadas por el cliente al Servicio Web son basadas en un secreto compartido, por ejemplo un password.
• El Servicio Web tiene capacidad para validar credenciales contra un servicio de autentificación.
• El Servicio Web es simple y no necesita SSO o soporte para asegurar la no repudiación.
• EL cliente y el Servicio Web confían uno en el otro en el manejo de seguro de credenciales.

 

Se puede utilizar autentificación directa cuando el Servicio Web actúa cómo un servicio de validación de las credenciales del cliente. Las  credenciales usadas, que se aceptan por el hecho de poseerlas (proof-of-possession), están basadas en un secreto compartido y son verificables contra un Identity Store.

 

Los participantes de este patrón de autentificación son los siguientes:

 

• Cliente: Aplicación que accede al Servicio Web, entrega las credenciales para la autentificación.
• Servicio Web: Web Services que requiere las credenciales para el uso de sus recursos.
• Identity Store: Es la entidad que almacena las credenciales de los clientes.

  

El siguiente Diagrama muestra la secuencia de mensajes que se intercambian en entre los participantes de este patrón de autentificación.

 

 

 

Ilustración 1: Mensajes del patrón de autentificación directa.

 

Los beneficios del uso del patrón de autentificación directa son:

 

• Simpleza.
• Si existe un problema de seguridad en la relación de confianza del cliente y Servidor, sólo compromete a este cliente y servidor y no a todo un modelo.

 

Las consecuencias resultantes del uso de autentificación directa son:

 

• Este modelo no permite el uso de SSO, lo que implica el paso de credenciales en cada llamada. Es posible sortear este asunto con cache de credenciales, pero si las credenciales son del tipo password está solución implica problemas de seguridad.
• Si se comienzan ha crear muchos servicios Web, el sistema se vuelve muy complejo porque las relaciones de confianza entre clientes y servidores son punto a punto, dificultando las labores administrativas del sistema.
• Si un cliente llama muchas veces al mismo servicio, el desempeño que obtiene es pobre porque cada vez el Servicio Web debe validar contra el Identity Store.
• Las credenciales de un cliente deben estar replicadas en todos los Identity Store, lo que lleva a tener actividades de sincronización y actualización.

 

Algunas consideraciones de seguridad que se deben observar al momento de implementar autentificación directa son:

 

• Es posible que ataques al canal entre el cliente y el Servidor Web puedan obtener las credenciales del cliente y atacar el servidor usando esas credenciales.
• El Identity Store puede ser foco de un ataque, con el objetivo de obtener las credenciales, por ejemplos password guardados en texto plano.
• El cliente puede implementar un Cache de Login y Password para entregarlos en cada requerimiento. Esto es un foco de riesgo de seguridad.

 

Autentificación indirecta

 

………………continuará……

 

 

 

 

Próxima conferencia técnica

 

 

Espero ver a los malos de siempre en este evento, veremos cosas interesantes

WCF se llamaba indigo antes. Si buscamos Indigo en wikipedia nos dice:

 

El color añil, también conocido como índigo corresponde a una longitud de onda de la luz de 4500 a 4770 angstrom, o entre 450 y 477 nm, se encuentra pues entre el azul y el violeta.

 

Bueno, para los perdidos ese no es el tema. Indigo es un framewrok que se comporta como el aceite en un motor. En un motor existen piezas que cumplen roles, estas piezas interactúan con otras. El aceite juega un rol especial en comunicar esas piezas y ahcer que trabajen de manera “suave”.

 

Indigo hace lo mismo que el aceite, pero entre dos piezas de software.

 

Si no se lo imaginan como yo, o quieren revisar que es, les recomiendo que lean este articulo que está muy bien escrito.

 

http://msdn.microsoft.com/msdnmag/issues/06/02/WindowsCommunicationFoundation/default.aspx