Se hace camino al andar... » soa

BeCodeWeek : Día 2

jmbeas — Wed, 06 Apr 2011 07:20:10 +0000

Hoy he tardado casi dos horas en escribir el post del día 1, así que esta noche me he traído el portátil. Quizás no me de tiempo a escribirlo todo, pero sí lo más importante.

Hoy he acabado bastante cansado a pesar de haberme levantado “a mi ritmo”. Bueno, tardé bastante en llegar al taller, pero es que el concepto Metro no se maneja mucho por la zona; tampoco es que yo pusiera mucha atención al concepto Callejear. Así que pasó lo que tenía que pasar.

Miguel Angel estaba terminando de preparar el backlog en el que trabajamos ayer mientras yo escribía el post del día 1, aun así contrastamos un par de dudas sobre cómo enfocar las tareas de la primera historia de usuario. Yo esperaba terminar pronto pero, la verdad, Xavi es bastante ruidoso. Por suerte, mañana estará casi todo el tiempo fuera, así que podremos concentrarnos sin problema. Eso sí, cuando vuelva está claro que tendré que ponerme los cascos.

Después de publicar el post me senté un rato con Xavi para que me ampliara sobre sus planes para dominar el mundo, con unas patatas fritas y una litrona. Eso sí, entre papa y papa: SOAUI y otras lecciones de arquitectura. Además, es evidente que Xavi tiene clarísimas las fuerzas que hacen funcionar un producto y se le ilumina la cara cuando habla de cómo hará funcionar su próximo proyecto.

Después de comer me quedé con Miguel Angel para empezar la primera historia de usuario. Menos mal que él ya había empezado antes de comer porque avanzamos muy poquito. Mi desconocimiento de Javascript, de Mootools y del dominio del problema a resolver hicieron que no avanzaramos mucho. Xavi dice que, además, también influye mi habilidad natural para cuestionarlo todo. (Él lo dice con otras palabras, pero mi ego me impide reproducirlas).

Xavi y Emma nos hicieron llegar tarde a la reunión de @AgileLevante. Miguel Angel se ha propuesto recuperar la actividad del grupo. Para ello cuentan con el apoyo de Emma y de Ricardo Borillo. A Ricardo le voy avisando desde ya que le voy a grabar un @podgramando muy pronto. Tenemos mucho de qué hablar. El grupito que se juntó era una mezcla de “veteranos” y “novatos”. Para mi fue estupendo ver caras nuevas. El final de la reunión terminó con una retrospectiva en la que tomaron varias acciones (con sus respectivos responsables). Entre ellas, Miguel Angel, se encargará de crear un site para el grupo donde poder ir anunciando la siguiente reunión.

Tras la reunión: cena, ducha, blog y a la cama. (No sin antes tener con Emma una conversación sobre SOA mientras revisaba mis viejas entradas en el blog y me instalaba Jasmine para mañana no estar demasiado pez)

P.S.

Tengo el teléfono estropeado. Nunca os compréis un HTC Tattoo. Tendré que buscarme un teléfono nuevo. ¿Sugerencias? Igual hago como Xavi y vuelvo a un concepto más básico de teléfono-que-sólo-sirve-para-hablar.

Servicios autónomos

jmbeas — Wed, 29 Apr 2009 18:15:00 +0000

Hace un par de semanas escribía sobre un curso al que asistí impartido por Udi Dahan y recibí varios comentarios que me pedían los ejemplos que usó Udi para explicar su enfoque SOA basado en el diseño de servicios autónomos en vez de en la reutilización de servicios. Hoy he estado tomando café con mi paisano Jose Carlos del Arco, miembro del comité organizador de JSWEB (Jornadas Científico Técnicas en Servicios Web y SOA) y hemos hablado (¡por supuesto!) de todo esto (y sobre más cosas, claro). Así que no me queda otra que rebuscar entre el desorden de mi mesa dónde demonios dejé esas notas y tratar de explicarlas. Por suerte, este fin de semana pasado he recuperado mi antiguo escáner y creo que podré escribir un poco menos.

Recordemos que Udi plantea que nuestros servicios deben ser diseñados para ser autónomos. Esto es, para que colaboren con otros servicios, pero que no estén acoplados a ellos (o que el acoplamiento sea el mínimo posible). Para ello trata de que la mayoría de las colaboraciones se hagan asíncronamente (“fire and forget”) y que los datos no sean compartidos sino que haya siempre una única autoridad certificadora de los datos (sólo un servicio escribe y el resto sólo lee). Para lograr que los cambios en los datos estén disponibles en el resto de servicios propone suscripciones a los eventos de cambio en los datos que cada cuál necesita.

Vamos al ejemplo y lo veremos más claro. Cuidado, es un ejemplo para ilustrar la idea de fondo. No lo toméis al pié de la letra.

Supongamos tres departamentos en una empresa (ventas, almacén y marketing).
Supongamos que trabajamos para el departamento de ventas para implementar una aplicación web que permita comprar nuestros productos desde internet. ¡Qué original! ¿Verdad?

La solución que propondríamos sería implementar la aplicación web como más bonita y usable resulte, pero que componerla teniendo en cuenta nuestra orientación a servicios. Así, el catálogo de productos es “propiedad” del Departamento de Ventas, pero el precio y disponibilidad no. Por tanto, para mostrar esta información que nos es ajena tendremos que realizar peticiones a otros Departamentos, es decir, llamadas a los servicios de marketing (para el precio) y de almacén (para la disponibilidad).

Udi, durante el curso, nos habló de cómo se componían las UIs de sitios como eBay o Amazon. Todas tenían en común que se componían a partir de llamadas a diferentes fuentes. Fijaos que hay partes de la UI que son muy estáticas (o casi), como las categorías de productos. Esa parte de la UI puede ser perfectamente el resultado de una llamada a un servicio. A nuestra aplicación web le viene a dar bastante igual si esta semana hemos empezado a vender “palos de fregona”, simplemente debería ser una nueva categoría y poco más, porque nuestra aplicación sabe vender productos que tenemos en nuestro catálogo.

Pero vayamos un poco más “adentro” de la capa de presentación (o incluso podríamos hablar de las aplicaciones, sin más). Los servicios se diseñarán e implementarán buscando que sean autónomos, es decir, que no requieran de otros para completar sus responsabilidades.

En nuestro ejemplo, el proceso de compra de un producto requerirá de la colaboración con otros servicios. Será necesario conocer el precio de un producto o las promociones o el precio de envío por correo urgente… Pero esto no quiere decir que nos tengamos que quedar esperando a que cada uno de los servicios nos responda.

En la figura 1 vemos cómo se suscribe el servicio de Ventas a los otros dos servicios. Así, obtiene los datos que necesita para operar de manera autónoma.

Paso 1) Ventas se suscribe al valor de los precios que posee el servicio de Marketing
Paso 2) Marketing informa de los precios a Ventas (porque éste no tiene ningún precio anterior)
Paso 3) Ventas se suscribe al valor de disponibilidad (“stock”) de los productos que posee el servicio de Almacén
Paso 4) Almacén informa de las cantidades disponibles en almacén de los productos en el catálogo

Por tanto, nuestra aplicación de Ventas puede mostrar toda la información necesaria para que un usuario inicie la compra de productos. Y dado que estamos suscritos a los cambios que se puedan producir tanto en los precios como en las cantidades disponibles, siempre (con un cierto margen) tendremos la información más actual: que es la única que necesitamos. Ahora veremos qué ocurre durante el proceso de compra.

Paso 1) El usuario (la aplicación) ya tiene toda la información necesaria para realizar el pedido e inicia el proceso de compra llamando al servicio de Ventas.
Paso 2) El servicio de Ventas hace sus comprobaciones, entre las que está el comprobar si hay “stock”, y calcula el total de la factura. Todo esto lo puede hacer porque es autónomo.
Paso 3) El servicio de Ventas informa al servicio de Almacén de que hay un pedido que debe ser servido. Lo hace asíncronamente, es decir, no espera a que el servicio de Almacén haga lo que tenga que hacer. Simplemente se asegura de proporcionarle toda la información necesaria para que se pueda realizar el proceso de empaquetamiento y envío del pedido al cliente.
Paso 4) El servicio de Almacén reduce (en su base de datos) el valor del stock de los productos involucrados en el pedido.
Paso 5) Dado que el servicio de Ventas está suscrito a los cambios de disponibilidad de los productos, recibe un mensaje con estos datos actualizados.

Como véis, el proceso de venta de un producto se puede realizar sin necesidad de esperar la respuesta de ningún otro servicio. Es más, el servicio de Almacén podría estar “apagado” y eso no nos afectaría para nada. El paso 3 se “encola” y el servicio de Almacén ya lo consumirá cuando sea. Por otro lado, si los valores de “stock” se mantienen sin cambios durante mucho tiempo, se planteará la decisión de negocio de qué hacer en esos casos: asumir que hay disponibilidad, que no hay disponibilidad, quedarnos con el último valor conocido…

Lógicamente, hay consideraciones a hacer en el caso de que “no todo vaya como la seda”. Hay que definir operaciones de compensación, por ejemplo. Pero si os fijáis, estaremos hablando realmente de automatizar operaciones que ya (probablemente) se están realizando de manera manual en el negocio actual. Por tanto, estaremos alineando la técnica con el negocio. Y demonios, ¿no es de eso de lo que tendríamos que estar hablando?

SOA no va de reusar

jmbeas — Thu, 16 Apr 2009 10:55:00 +0000

El pasado día 7 asistí a un curso de un día sobre SOA organizado por iMeta e impartido por el reconocido Udi Dahan. Por cierto que fue en las instalaciones de Microsoft en “La Finca”. Uuuuyyy, qué miedooorrr… Bueno, tampoco es para tanto, soy muy Linux y muy Java, pero tampoco soy tan “talibán” como para no “entrar en la boca del lobo”.

Bueno, bromas aparte, la organización de iMeta fue muy buena (el catering estuvo a la altura, je, je) y Udi Dahan es toda una garantía. Además, como Hadi Hariri (de iMeta) me había explicado, el curso no estaba centrado en ninguna tecnología en particular. Yo, por si acaso, advertí de mi “orientación ideológica” en mi presentación. Por cierto, pensé que mi inglés estaba más oxidado, aunque al final de la tarde ya no daba pié con bola…

Pero vamos al tema. Udi Dahan es muy conocido en ambientes SOA (Service Oriented Architecture) y DDD (Domain-Driven Design) porque tiene un enfoque diferente al SOA de otros autores. Durante el curso le pregunté directamente por esto y sobre cómo se encaja con la visión de, por ejemplo, Thomas Erl. Udi me contestó que simplemente no encajan: el enfoque de Erl se centra en reusar, mientras que el de Dahan se centra en la autonomía de los servicios y el principio de única responsabilidad (single responsibility principle). En un correo posterior, Udi me ha aclarado que, según él, Thomas Erl ve los servicios más como construcciones de software, mientras que él los ve más como construcciones de negocio (implementados mediante varias construcciones de software).

No hace mucho leí “Implementing SOA” de Paul C. Brown, y hay muchas más coincidencias con Dahan que con Erl. Y eso que de Erl tengo nada más y nada menos que tres tochacos que voy a tener que rifar, salvo que el último, “SOA Design Patterns” me sirva para algo más que para hacer bulto en la estantería. :-/

Todo esto que resumo en apenas dos frases queda bastante claro a lo largo del curso porque Udi dedica bastante tiempo a explicar que al reusar realmente incrementamos el acoplamiento mientras que lo que realmente buscamos cuando decimos que queremos reusar es reducir el esfuerzo empleado al desarrollar las aplicaciones para nuestros clientes. Por ello explica que, aunque sea paradójico, aquellas piezas de código en las que empleamos mayor esfuerzo, y que por tanto serían las que más nos interesaría reusar, suelen ser aquellas que son más específicas y que son las más dificiles de reusar puesto que están fuertemente acopladas al negocio que resuelven. Y por otro lado, resulta que nos empeñamos en que todas nuestras aplicaciones compartan componentes y diseños poco acoplados al negocio (es decir, que no aportan valor de negocio por sí mismos) con el objetivo de que sean lo más reutilizables posible. Pero parece que nos olvidamos de que, hagamos lo que hagamos, en algún punto de nuestro código tendremos que acoplarnos al negocio puesto que para eso desarrollamos software: para resolver problemas de negocio.

Udi nos presenta los conocidos cuatro principios de la orientación a servicios (según Microsoft):

los servicios son autónomos
los límites son explícitos
los servicios comparten esquemas y contratos, no clases
la compatibilidad de un servicio se determina en base a una política

y se centra en la autonomía de los servicios. Nos explica cómo alcanzar esa autonomía de una manera genuína, llegando hasta el extremo de que cualquier servicio se pueda implementar con el diseño que se quiera y sin la obligación de compartir siquiera la misma base de datos.

- ¡Eh! ¿Qué ha dicho? ¿Qué no se comparte la base de datos?
- ¿Y qué pasa con las restricciones de integridad? ¿Qué hago con mis foreign keys?

Muchos le preguntaron a Udi por esto. Je, je, yo ya sabía por dónde iba él porque esta discusión me la conozco de cuando estaba en Degesys, aunque allí no llegamos a ninguna conclusión (al menos mientras yo estuve). El caso es que la respuesta es bien fácil: las restricciones de integridad en la base de datos sólo sirven para acoplar servicios entre sí. Así que tú verás si quieres estar acoplado o no… Claro, para conseguir esta autonomía hay hacer concesiones:

no tenemos un único modelo de datos compartido por todos los servicios
no tendremos un estado coherente de los datos al que estamos acostumbrados
tendremos que asumir un cierto nivel de redundancia en nuestros datos almacenados

¿Cómo se consigue esto? Pues Udi lo resuelve de una manera muy sencilla a la vez que elegante:

los datos son “propiedad” de una única fuente autorizada, es decir, cada dato en la base de datos sólo es manipulado por un único servicio
los servicios interesados en algún dato se suscriben a los cambios que publicará su fuente autorizada y guardan una copia local del dato (a modo de caché)

Esto, si no estoy equivocado, se viene conociendo como Event-Driven Architecture (EDA).

Pero Udi no nos contó sólo que la manera de implementar SOA es haciendo EDA, sino que insistió en que un servicio debe ser concebido desde el negocio y que se implementa íntegramente desde la UI hasta la BD. Para ello nos explicó diferentes maneras de componer la UI, pero todas evitando el concepto de página monolítica. Y recalcó que no tenemos que tener una única capa técnica consistente, sino que podemos decidir usar diferentes soluciones técnicas para cada problema de negocio. Claro, lo difícil es que hay que acertar en definir los “bounded contexts”, y sólo podremos acertar si tenemos claro que éste no es un trabajo tecnológico sino de análisis del negocio.

- ¡Vaya, claro, por eso hablan tanto del alineamiento de IT con el negocio cuando se hace SOA!
- ¡Ahora lo entiendo!
- ¡Y yo que pensaba que todo esto de SOA iba de reusar componentes tecnológicos y poner webservices por doquier!

Si estáis interesados, otro día puedo recopilar más notas y recordar algunos de los ejemplos que usó Udi en el curso.

¡Ah! Y que no se me olvide. Gracias a Hadi por el detalle que tuvo conmigo para Agile Spain. Lo dejo ahí porque si queréis enteraros tendréis que asistir a la charla que darán Juan, Agustín y Leo sobre “Introducción a Scrum”.

Udi Dahan en Madrid

jmbeas — Sun, 29 Mar 2009 14:51:00 +0000

Los que no conozcáis a Udi Dahan quizás tampoco os suene Domain Driven Design (DDD). Udi Dahan es un reconocido experto en SOA y que además participa activamente en la lista de DDD.

El próximo 7 de abril va a impartir en las oficinas de Microsoft en Pozuelo (Madrid) un tutorial sobre SOA y DDD como parte de los Architecture Days 2009 que organiza iMeta (multinacional con sede en Málaga). Y aunque Udi está relacionado fundamentalmente con el mundo .NET, Hadi Hariri (uno de los organizadores del evento) me ha explicado que el tutorial es a nivel de diseño, por lo que no se entra en detalles específicos de ningún lenguaje o plataforma (léase .NET o Java).

Así que he decidido pegarle otro pellizco a mis deteriorados ahorros para escuchar lo que nos tiene que decir “The Software Simplist” (en inglés, ups).

GeDOS : Nueva etapa, nuevos avances

jmbeas — Sun, 27 Apr 2008 23:57:00 +0000

He estado bastante liadillo estas últimas semanas y no he tenido apenas tiempo de nada. Sin embargo, y no sólo porque tengo como objetivo semestral (en mi empresa) liderar esta iniciativa, hemos tenido un par de sesiones más del Grupo de Estudio “GeDOS”. Hemos cambiado un poco el formato porque no estabamos consiguiendo avances prácticos: nos quedábamos la mayoría de las ocasiones en temas demasiado teóricos.

Hemos pasado a estudiar directamente los Principios de Diseño que explica Thomas Erl en cada capítulo de su libro. Vamos sesión por sesión, capítulo por capítulo. La verdad es que ahora estamos bastante más enfocados que antes y eso se nota. Es como si hubiéramos pasado una barrera que nos impedía hablar de Diseño de Servicios (en mayúscula); quizás la decisión de no hablar de tecnologías, frameworks, etc. haya ayudado en esto.

La siguiente sesión (a la vuelta del puente) será la del capítulo 8 (Abstracción de servicios).

GeDOS : La granularidad de los servicios

jmbeas — Fri, 14 Mar 2008 20:33:00 +0000

La semana pasada celebramos una reunión más del Grupo de Estudio “Diseño Orientado a Servicios” en DEGESYS. Parece que, por fin, nos estamos centrando ya y comenzamos a avanzar.

Os hago un extracto del acta de esa reunión por si alguien tiene curiosidad y/o quiere comentar algo.

Parece que no había quedado bien claro cuál era el tema a tratar, pero JRR abrió la discusión tratando sobre “¿alguien se acuerda cuál fue la pregunta inicial?”.

La conversación derivó rápidamente a discutir sobre la clasificación que hace T. Erl de servicios de entidad, de actividad o de utilidad. Discutimos sobre si los servicios son fundamentalmente de entidad (CRUD-like) en vez de principalmente de actividad (process-like). JRR hizo una anotación interesante: “la diferencia entre un task service y un entity service no es si está componiendo un proceso en base a otros servicios o no, sino en su naturaleza”. Y, ciertamente, Erl nunca hace esa simplificación sino que, en el ejemplo de la pág.45 compara el servicio “Factura” y su operación “Añadir” (claramente centrada en el dominio funcional de las facturas) con el servicio “Consolidación de Facturas de un Cliente” (que manipula un conjunto de facturas para un cliente dado y que no parece claramente centrado en el dominio funcional de las facturas ni tampoco de los clientes). Si este último caso resulta implementado como un proceso de negocio orquestando a otros servicios de grano más fino, hablaríamos de un orchestrated task service. Por último, Erl concluye en esta misma página que reconoce el punto de confusión y establece que la “capa de servicios de actividad” no concentra toda la lógica de procesos de negocio sino que se centra en aquella lógica no-agnóstica.

Iván apuntó la diferencia entre la clasificación de servicios por su modelo de análisis frente al diseño de capas de orquestación, de servicios de negocio y de servicios técnicos, donde esta clasificación de servicios de Erl encajaría enteramente en la capa de servicios de negocio. (Me atrevería a afirmar que Iván estaba pensando en este artículo de IBM cuando decía esto)

También discutimos sobre el peligro de centrar el esfuerzo de análisis/diseño en las entidades (porque eso nos hace derivar peligrosamente hacia servicios CRUD-like que ofrecen al exterior el modelo de datos) en vez de trabajar desde los procesos de negocio (desde donde irían surgiendo los servicios y, de ahí, las entidades). En varias ocasiones tratamos de ejemplificar esta orientación a servicios centrada en los requisitos de negocio en vez de centrada en los datos y parece que un ejemplo sacado del proyecto SGC aclaró un poco las ideas:

El proceso de contratación de un nuevo servicio para un cliente dado consiste en:

formalizar el contrato con el cliente (persistir los datos de la contratación del servicio)

iniciar la provisión de ese servicio (que debe asíncrona porque puede demorarse en el tiempo incluso días, o no acabar nunca…), devolviendo al cliente un “ticket”

Aunque no nos pusimos de acuerdo sobre si debía ser un “task service” o un “proceso orquestador de entity services”, la discusión parece que fue bastante enriquecedora porque durante ella se dijeron frases como:

“Demandar al consumidor un alto nivel de conocimiento sobre mi negocio es malo”.

“El Diseño Orientado a Servicios comienza por el servicio, no por los datos”.

“Es más interesante enfocar el modelado desde el punto de vista de las actividades-procesos porque de ellas se podrán deducir más fácilmente las entidades” (También se escuchó la afirmación contraria)

Para iniciar un diseño SOA tenemos que conocer los procesos de negocio, caso contrario no podremos hacer SOA.

Finalmente, acordamos (a propuesta de JRR) que en la siguiente sesión (la semana que viene) trataremos sobre la cualidad de “distribuibilidad” de un diseño para ser considerado Orientado a Servicios. La idea de fondo es validar la afirmación “una arquitectura basada en un contenedor OSGi, pero que no se puede hacer distribuida (e.d. ejecutada en varios contenedores separados físicamente), es SOA”. No hemos planteado un material específico porque entendemos que en el capítulo 3 da suficientes pistas, sin embargo, quedamos abiertos a alguna aportación que pueda ser de ayuda para esta discusión.

SOFEA: ¿Cómo hacer una capa de presentación orientada a servicios?

jmbeas — Sat, 01 Mar 2008 23:52:00 +0000

Hace ya bastante tiempo que he oido hablar a mi compañero Xavi Gost acerca de SOFEA. He estado leyendo un artículo de Matt Raible y me ha parecido bastante interesante. Pero lo que más me ha llamado la atención es la visita que a continuación he hecho a la demo de AppCelerator. Es realmente espectacular. Visitad el ejemplo de los gráficos (Widgets > Chart > Line Chart).

GeDOS : Contratos de servicio y estandarización

jmbeas — Sun, 24 Feb 2008 21:45:00 +0000

Bueno, pues esta semana que termina hemos dado el siguiente paso en el Grupo de Estudio. No es que haya sido un “Gran Paso para la Humanidad” pero un paso tras otro es como se anda.

ESTADO

Planificada para el día 14/Feb/2008
Pospuesta a la semana siguiente: J-21/Feb/2008 18:30
Reunión realizada
En fase de discusión

TEMA

Contratos de servicio y estandarización

MATERIAL

SOA. Principles of service design. Ch 6. Service contracts.pdf

ORDEN DEL DÍA

La sesión la moderará JMB.
Dado que no hemos participado mucho en las preguntas planteadas en la sesión anterior, propongo que no concluyamos nada y que pasemos directamente al tema del día: “Service Contracts”
La pregunta inicial la hará Xavi G.
Duración: 30 minutos
Es importante (lo ha pedido Iván) que tratemos el tema de discutir sobre los contratos de DEAS-SALES, así que deberíamos dar tiempo a esta discusión para poder sacar conclusiones.
Jose M. explicará los contratos de DEAS-SALES y discutiremos sobre ellos.
Duración: 30 minutos
Conclusiones y a casa.

PONENTE

Xavi G.

MODERADOR

JMB

ASISTENTES

Iván H.
Xavier G.
Jose Manuel B.
Jose M.
Alfredo R.

DURACIÓN

Comenzamos a las 18:40 (otra vez un poco de retraso) y terminamos a las 20:05 (previsto a las 19:30)

RESUMEN

Xavi G. comenzó haciendo un resumen de lo más relevante (para él) del capítulo y así introdujo la discusión sobre la estandarización de los mensajes.

Xavi G. resaltó algunas frases y conceptos que le parecieron especialmente interesantes:

Los contratos deben resistir el paso del tiempo.
Los contratos deben expresar el dominio de su ámbito.
Es interesante que los mensajes sigan un estándar conocido lo más universalmente posible para así no cerrar las posibilidades de interoperabilidad.
Los contratos de servicios deben ser descubribles.

Alfredo R. aprovechó que el tema de esta sesión estaba centrada en los contratos para preguntar sobre cómo deberíamos (en DEGESYS) construir nuestros contratos:

métodos con campos de tipo String (y que luego se parsean en el servicio para comprobar su conformidad al XSD correspondiente)
métodos con campos de tipo ObjetoComplejo (y que sea JAXB y el wsgen el que construya el XSD)

Esta pregunta tiene más que ver con la discusión Contract-First vs Contract-Last y, aunque parece que todos teníamos mucha más simpatía por Contract-First, tanto Alfredo como JMB explicaron por qué estamos usando ahora mismo JAXB (e.d. Contract-Last) y reclamaron una manera diferente de hacer.

También estudiamos los contratos de DEAS-SALES y vimos que no parecía buena idea el seguir el patrón Request/Response puesto que:

no era propio del modelo de dominio, sino más bien una necesidad tecnológica (distinguir entre los mensajes de ida y los de vuelta)
no era necesario puesto que ya SOAP hace ese encapsulamiento

Revisitamos otra vez la discusión Contract-First vs Contract-Last y parece imponerse la necesidad de un prototipo.

Antes de terminar, JMB preguntó a todos si compartían/conocían la clasificación de tipos de servicio que proponía Thomas Erl en sus libros (entity, task y utility services). Así, propuso el material para la siguiente sesión.

SIGUIENTE SESIÓN

Fecha: 28/Feb/08
Tema: La granularidad de los servicios
Material de Estudio: SOA. Principles of service design. Ch 3. Service-oriented computing and SOA.pdf

Modelos de servicio (según Thomas Erl)

jmbeas — Thu, 21 Feb 2008 01:27:00 +0000

En la página 43 del libro “SOA: Principles of Service Design” (y también en el anterior “Service-Oriented Architecture (SOA): Concepts, Technology, and Design“), Thomas Erl presenta una clasificación de servicios que creo bastante útil:

servicios de entidad (entity services)
servicios de tarea (task services)
servicios de utilidad (utility services)

Estos servicios se dispondrían por capas o niveles (layers), estando los de tarea más cerca de las aplicaciones y los de utilidad más cerca de los sistemas externos.

Servicios de entidad

Su ámbito funcional se circunscribe a una o más entidades de negocio, p.ej. Cliente, Empleado, etc. Se consideran servicios muy reusables porque se diseñan agnósticos de la mayoría de los procesos de negocio en los que puedan participar.

Ejemplo:

Employee

GetWeeklyHoursLimit

UpdateWeeklyHoursLimit

GetHistory

UpdateHistory

DeleteHistory

AddProfile

GetProfile

UpdateProfile

DeleteProfile

Sus operaciones pueden ser parecidas al CRUD.

También llamados “business entity services” o “entity-centric business services“.

Servicios de tarea

Su ámbito funcional está directamente asociado a una tarea o proceso de negocio. Este tipo de servicio tiende a ser menos reusable que los servicios de entidad. Normalmente se comporta como el controlador de una composición de servicios (quizás estos más agnósticos).

Ejemplo:

RevenueAnalysis

Submit

Dependiendo de la tecnología empleada, este tipo de servicios pueden ser implementados con un WebService o con una plataforma de orquestación de servicios (definido el proceso de negocio con BPEL, p.ej).

También llamados “business process services” o “task-centric business services“.

Servicios de utilidad

Los anteriores se centran en el negocio, éstos se centran en la tecnología.

En la capa de servicios de utilidad agrupamos servicios reusables, transversales e idealmente agnósticos de la aplicación que lo puede consumir.

Ejemplo:

Transform

APImport

APExport

ARImport

ARExport

También llamados “application services“, “infrastructure services” o “technology services“.

Primera sesión del GeDOS

jmbeas — Sun, 17 Feb 2008 17:29:00 +0000

Más vale tarde que nunca… hace más de una semana adelanté que habíamos creado un Grupo de Estudio sobre “Diseño Orientado a Servicios” y que iba a tratar de publicar los resultados de la primera reunión. Pues bien, aunque esta semana íbamos a celebrar la segunda reunión y hemos tenido que posponerla, ya tengo el resumen de la primera reunión y quería compartirlo.

ESTADO

Planificada para el día 07/Feb/2008

Reunión realizada

En fase de discusión

MATERIAL

“SOA Principles of Service Design” Capítulo 4 : Service-Orientation

PONENTE

Jose Manuel Beas

MODERADOR

No se eligió previamente, pero JMB intentó actuar como tal.

ASISTENTES

Iván H.

Xavier G.

JMB

Jose M.

Marco F.

JRR

Alfredo R.

DURACIÓN

Comenzamos a las 18:40 (un poco de retraso) y terminamos a las 19:50 (previsto a las 19:30)

PRIMERA IMPRESIÓN

Comenzamos comentando el material que se había elegido.

JMBeas apuntó hacia el concepto de interoperabilidad, que es uno de los 8 conceptos de diseño que se identifican en el material bajo estudio.

La discusión rápidamente se desplazó a temas generales y JoseRamon volvió al foco planteando una pregunta acerca de si un servicio era necesariamente distribuido.

Ante la discusión generalizada se decidió ir repasando cada uno de los 8 conceptos y en el primero y al hilo del significado de “Standardized Service Contract” volvió a desviarse hacia temas generales.

La reunión, a partir de ese punto, se desenfoca y acabamos planteando temas demasiado abstractos para ser objeto de estudio. Hablamos de qué es un servicio, de dónde parte, de la importancia del contrato y de cómo es un contrato propiamente dicho.

El tiempo avanza y decidimos cerrar la sesión no sin antes tomar algunas decisiones. Se decide que el tema de estudio para la siguiente reunión es el capítulo del mismo libro dedicado a los contratos. Se formulan tres líneas de debate:

¿El significado de “Standardized Service Contract” es el de generar un estándar propio de la empresa o de acercarse a estándares de la industria?

¿Es necesariamente distribuido un servicio? ¿y distribuible?

Definir el ámbito de discusión y de aplicación de SOA para este grupo… todos estamos de acuerdo en que es Degesys y por lo tanto los escenarios en los que nos movamos deberían estar incluidos en este ámbito.

Planteamos también el escribir para la próxima sesión un contrato tal como lo entendemos cada uno para poder, por síntesis, encontrar un punto de partida común para la siguiente sesión.

CONCLUSIONES FINALES

N/A

SIGUIENTE SESIÓN

Fecha: 14/Feb/2008 (San Valentín)

Material de Estudio: “SOA Principles of Service Design” Capítulo 6 : Service Contracts (Standardization and Design)

Hemos creado un grupo en GoogleGroups para ver qué tal se nos da. Si vemos que la cosa funciona (y hay petición popular), abriremos la participación al público en general. De momento, a medida que vaya pudiendo extraer alguna conclusión suficientemente interesante, trataré de conseguir permiso para publicarla aquí.