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:
¿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.
No hay comentarios:
Publicar un comentario