SOA, aproximación práctica ¿Mito?

Decidí escribir este artículo ya que muchas veces se escuchan muchas versiones de un concepto, además de recrear mitos conceptuales o bien esquemas faraónicos del tópico, por este motivo el objetivo del artículo es mostrar una aproximación a SOA que está muy de moda, pero es simples pasos.

Ahora bien, veamos algunos conceptos básicos, esto es siempre necesario para comenzar un desarrollo.

En primer lugar, SOA no es derivado de una propuesta académica porque generalmente se piensa eso cuando se expone el concepto, no hay technical report del SEI si esa es su pregunta en estos momentos. El concepto empieza a sonar por el año 2000 y si la información que manejo es consistente quien lo mencionó por primera vez fue Gartner por el año 1996.

Esto nos trae varias conclusiones, pero una fundamental es que el concepto es relativamente nuevo, es lógico esto por la creciente evolución de las arquitecturas en el exponencial crecimiento del mundo de la ingenieria de software.

Veamos una definición de SOA de W3C

"Conjunto de componentes que pueden ser invocados, cuyas descripciones de interfaces se pueden publicar y descubrir"

Otra definición, en este caso de CBDI

"Estilo resultante de políticas, prácticas y frameworks que permiten que la funcionalidad de una aplicación se pueda proveer y consumir como conjuntos de servicios, con una granularidad relevante para el consumidor…"

SOA desde mi perfil de arquitecto es "Un estilo de arquitectura" y ahí dejo la definición, ya que la cantidad de variantes y agregados al inicio de la frase lo vamos a ir modelando con el ejemplo que les voy a plantear.

Para esquematizar un ejemplo de SOA, voy a desarrollar un ejemplo de Autenticación de Usuarios, donde la idea es brindar este servicio para poder usarlo desde (enumeren…)

  1. Aplicación Escritorio, puede ser un cliente inteligente (delgado).
  2. Aplicación Wap , para esquema de telefónica con esta tecnología.
  3. Aplicación Mobile, para pocket pc en este caso Mobile 6.0 de la empresa MS.
  4. Y también estaría habilitado para esquemas web por supuesto.

Manos a la obra con nuestro ejemplo, en primer lugar voy a mostrarles un preliminar y básico diagrama de componentes para que entiendan lo que voy a crear.


Bien simple, tenemos el servicio "Service" y los componentes satelitales con relaciones de uso. Veamos el esquema de nuestro servicio Web.


El servicio se compone de las clases detalladas donde he realizado implementaciones genéricas de respuestas y solicitudes para especializar a las de inicio de sesión particular de esta problemática. Posteriormente podemos visualizar nuestro servicio Web llamado "ShopService" (tiene que ver con un esquema que me es familiar actualmente)

Les muestro programáticamente como está constituido, lo he desarrollado en tecnología MS, en lenguaje C#.


La figura anterior muestra la implementación y veamos algo del IDE.


Con este modelo, tendremos publicado un servicio que brinde autenticación de forma personalizada tratado de forma fina y detallada cada solicitud y respuesta. (Algo más que les voy a mostrar es el esquema de configuración del Servicio).


En este punto les voy a detallar las aplicaciones que van a consumir este servicio, esto va a ir completando nuestro esquema SOA de interacción. Veamos una aplicación Escritorio tradicional que hace uso del servicio:


Para el servicio necesitamos las credenciales y un código de seguridad para el esquema de autenticación propuesto, pueden validar esto en el diagrama de clases que coloqué en el detalle del servicio.


Esta última figura muestra el detalle de la llamada al servicio, ya tenemos funcionando el esquema en la aplicación escritorio, vamos a detallar el mismo esquema sobre una aplicación Mobile 6.0:


Ahora veamos la implementación del servicio.



Y una cosa a remarcar, no es la misma captura pero la particularidad, es el mismo código!!, interesante no?

Sigamos para completar un esquema WAP que se conecta al servicio desarrollado.


Veamos el código.


¿Muchas similitudes en el código no?

Bien en resumidas cuentas hemos implementado nuestro servicio en un esquema SOA muy rudimentario pero que nos acerca a conclusiones interesantes, es como les decía un estilo de arquitectura sin lugar a dudas, además propone una descomposición funcional lo vimos en el diseño preliminar que les expuse del servicio web, acordarse de que surge en el mercado no en el entorno académico y relaciona conceptos ya conocidos como el bajo acoplamiento, granularidad gruesa, componentes y mensajería.

Espero que les sea de utilidad….

Comentarios

  1. Muy buena descripción. Hace muchos años que estudio el tema SOA, y siempre que debo exponer sobre el tema, doy vueltas por el web para buscar visiones novedosas o distintas.

    Que buena manera de describir esta arquitectura. Serás sin duda el blanco de muchos pragmáticos que buscan explicar SOA como una arquitectura empresarial donde un servicio es justamente una abstracción, no necesariamente tecnológica.

    Pero es justamente ahi donde me gustó tu ejemplo. El primer paso hacia SOA es entender, desde el punto de vista de TI, que debe existir una visión agnóstica e independiente de la plataforma concreta subyacente, para definir un servicio. Esta es quizás la primera lección a aprender.

    ;)

    Andrés

    ResponderBorrar

Publicar un comentario

Entradas más populares de este blog

Modelando relaciones en UML, un acercamiento a las Asociaciones

Utilizando Intents implícitos para crear actividades

Secuencias…Modelado indispensable