19/08/2008 13:41 por
zorry
En muchos casos he observado que, no se muy bien porqué, pero la gente no se para a pensar un rato de qué manera diseñar sus proyectos de una manera eficiente (a mi me pasa muchas veces)... A menudo nos pasan unos requisitos y lo primero que hacemos es crear una orquestación para empezar a diseñar.
Pero, ¿nos paramos a pensar si esto es totalmente necesario? Por ejemplo, la orquestación que estamos diseñando podría resolverse empleando únicamente mensajería de BizTalk, si lo único que hay que hacer es por ejemplo, una transformación y un enrutamiento basado en contenido, y sin embargo, mucha gente se crea una orquestación para aplicar un mapa y una decisión. Y ni que decir tiene que este cambio tiene mucho impacto en el rendimiento de nuestra aplicación. Supongo que esta situación es en parte explicable por el hecho de que cada vez que nos enseñan una demo, nos meten por los ojos las orquestaciones de BizTalk.
Pero veamos un caso particular: Supongamos que nuestro caso es una aplicación que tiene que enviar un XML con un formato diferente dependiendo de los datos que contiene un documento original (por ejemplo, un identificador de cliente).
En todos los casos, tendremos que diseñar (si no nos los han facilitado ya) el esquema del documento original, así como los esquemas de los documentos de los clientes. Y adicionalmente, tendremos que diseñar los mapas entre el el esquema original y cada uno de los esquemas de los clientes.
A partir de aquí, tenemos dos opciones:
- Diseñar con orquestaciones: Creamos una orquestación que tiene un puerto de entrada, y un shape de decisión con todos los posibles clientes. Finalmente, de cada posible decisión, creamos un shape de transformación, que llama al mapa de transformación y finalmente se entrega al cliente. Finalmente, una vez desplegada la solución, crearemos todos los puertos de entrada y salida que requiera la misma.
- Diseñar mediante mensajería: Como primer paso, promocionaremos el elemento del identificador de cliente en el esquema original. Una vez desplegada la solución, creamos un puerto de entrada, y un puerto de salida con cada uno de los clientes de destino. En cada uno de los puertos de salida, creamos un filtro con la propiedad promovida en el esquema, creando de esta manera el enrutamiento. Y finalmente en cada puerto, establecemos el esquema que tiene que emplear para cada cliente.
Las dos opciones pueden ser válidas funcionalmente, porque obtenemos el mismo resultado. Pero la primera no es óptima desde el punto de vista del rendimiento y desde el de la mantenibilidad:
- En caso de que haya que modificar la solución porque haya que integrar un nuevo cliente, hay que modificar el desarrollo para incluir la decisión en la orquestación (en el primer caso). En el segundo caso podemos desplegar un nuevo proyecto con el nuevo esquema y transformación sin tocar lo que ya hay.
- En el primer caso la base de datos MessageBox tiene mucho más tráfico. Esto es debido a la persistencia de la orquestación, que en el caso de la mensajería obviamente no se realiza. En concreto, se realiza persistencia cada vez que se envía un mensaje o se finaliza un Scope, además de la finalización de la orquestación. En esta persistencia se salva todo el estado de la orquestación. De modo que se está incurriendo en una sobrecarga para la base de datos que hay que estudiar si es necesario emplear.
Y sin embargo, habrá ocasiones en las que sea necesario realizar esta operación en una orquestación, por ejemplo, si necesitáramos transaccionalidad.
En resumen, que tenemos que pensarnos muy despacio cómo planteamos una solución antes de empezar a desarrollarla.
da51498a-2d96-4f12-b19b-6b696bc4a4e1|0|.0