11.25.2012

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

 

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

Reutilización de la lógica de negocios

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

Gobernabilidad de la solución

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

Escalabilidad

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

Calidad

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

Movilidad

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

Seguridad

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

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

Technorati Tags:

11.17.2012

Un Bus de Servicios en Windows – Parte 1

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

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

Windows Service Bus

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

Características de Messaging del Windows Service Bus

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

Service Bus Queues

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

Service Bus Topics

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

Technorati Tags:

11.13.2012

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

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

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

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

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

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

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

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

image

¿Que tecnologías debo utilizar?

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

Technorati Tags: ,