|
Niveles de
abstracción, granularidad y alineación con el negocio:
En la editorial de este mes queremos abordar un par
de temas con los cuales nos venimos encontrando en reiteradas oportunidades
y proyectos desde hace ya varios años. De hecho se podría decir que venimos
hablando y madurando nuestras ideas y experiencias sobre estos temas desde
las épocas de MTS (Microsoft Transaction Server) y COM+ (Windows Component
Services) o más genéricamente hablando desde la época de gloria del
desarrollo de software basado en componentes (Component-Based Development)
y que ahora en épocas de Orientación a Servicios y Arquitectura Orientada a
Servicios (con tecnologías habilitadoras como Web Services) toman especial
relevancia.
El primer punto que queremos analizar tiene que ver
con el nivel de abstracción de los servicios en relación a los componentes
y objetos. En este sentido, más allá que este punto no garantice que el
servicio haya sido diseñado correctamente, los servicios deberían ser
concebidos a un nivel de abstracción más alto que el que habitualmente
tiene un componente de lógica de negocios.
El segundo punto es la granularidad de los
servicios. Este aspecto está directamente vinculado con la
funcionalidad que expone cada servicio, porque por definición, un servicio
debería exponer una capacidad funcional concreta, alineada con las
necesidades de mi negocio. Analicemos este punto a partir de un ejemplo: Si
mi negocio necesita un servicio que procese un orden de compra, entonces la
capacidad funcional de mi servicio debería ser diseñada de tal forma que el
mismo reciba un mensaje con la información de la orden de compra a procesar
para posteriormente retornar un mensaje con el resultado de dicho
procesamiento. Ahora supongamos por un momento que en lugar de diseñar mi
servicio de la forma mencionada anteriormente, diseñamos 2 servicios
aislados que se dediquen a resolver parte de la funcionalidad requerida,
por ejemplo, el primero recibiría un mensaje con los datos del cliente
asociado a la orden de compra y el segundo se encargaría de procesar un
mensaje con los artículos comprados. Si bien, desde el punto de vista
técnico, estaríamos haciendo algo parecido, desde el punto de vista
conceptual no estamos exponiendo la capacidad funcional al nivel de
granularidad que mi negocio requiere. En el primer escenario planteado
decimos que tenemos una interface con granularidad “más gruesa” o “Coarse-Grained
Interface” y a medida que nos vamos metiendo dentro del sistema la
funcionalidad expuesta debe necesariamente ser más rica porque se aleja de
la funcionalidad abstracta de nivel superior y vamos (en el camino
planteado en el escenario 2) teniendo interfaces con granularidad “más
fina” o “Fine-Grained Interface”.
Y por último, la correcta combinación de los dos
aspectos mencionados anteriormente (nivel de abstracción y granularidad)
nos permitiría construir servicios alineados con las capacidades
funcionales requeridas por mi negocio, obteniendo lo que se denomina como “Business-Friendly
Services”.
Para obtener más información sobre estos temas los
invitamos desde aquí a consultar este artículo de arquitectura publicado en
MSDN:
Service-Oriented Architecture: Considerations for Agile
Systems
Será hasta el próximo mes!
Martín Cabrera
Martin.Cabrera@microsoft.com
Arquitecto de Software
Microsoft Cono Sur
Wilson
Pais
Wilson.Pais@microsoft.com
Gerente Socios Desarrolladores & Académicos
Microsoft Cono Sur
|
