Desde que salio la primera versión del Workflow Foundation con el Framework 3.0, se ha ido incrementando su uso en las organizaciones para llevar a cabo diversas tareas que por lo general, son procesos que no se ejecutan de inmediato, si no más bien son procesos que perduran en el tiempo. Igualmente, el WF se esta conviertiendo en el framework de preferencia cuando se trata de procesos que necesitan enviar notificaciones, o hacer seguimiento estricto de los procesos que se van ejecutando - tracking.
Esto es una muy buena noticia ya que nos permite desarrollar de forma más simple nuestras aplicaciones utilizando el Workflow Foundation, lo que además nos permite tener una forma más sencilla y mantenible de orquestar nuestros procesos de negocio. El uso del workflow foundation nos trae otra pregunta, ¿dónde en mi arquitectura n-layer pongo mis workflows? Esta es la pregunta que vamos a contestar en este blog post.
Es muy común asociar los framework para crear workflows con pantallas y demás componentes que nos facilitan el desarrollo de aplicaciones – en realidad no lo facilitan, solo lo aceleran y solamente en el caso de que sea estándar, cuando aparecen cosas que requieren de programación, por lo general es más dificil crear el cambio personalizado que hacerlo manualmente. Sin embargo, al utilizar estos workflows que me generan automáticamente los procesos y las pantallas, quedo automáticamente atado a la interface gráfica seleccionada, por lo tanto si deseo permitir el acceso de otros esquemas de interacción a mis workflows voy a tener que hacer el workflow de nuevo, específicamente para el tipo de front end al que deseo crearle el workflow. Esto por supuesto no es lo que se persigue con las arquitecturas n-layer. Por esta razón es que lo ideal es tener workflows que permitan ser activados desde distinitas fuentes, ya sea UI o capas de servicios. Para lograr esto, debemos empaquetar los workflows en librerías lo que nos permitiría invocar estos workflows ya sea desde servicios, aplicaciones web, aplicaciones móviles, y aplicaciones RIA, etc.
Por otro lado, como mencionamos anteriormente, la función del workflow es orquestar procesos de negocio. Como claramente lo dice la oración anterior el workflow nos debe ayudar a orquestar el negocio por lo tanto se denota claramente que debemos orquestar procesos de negocio basándonos en nuestra lógica de negocio, no basados en un tipo de interacción que vayamos a tener con alguna interfase gráfica o con una capa de servicios. Esto esta reflejado así por el grupo de pattern and practices desde el año 2002 mucho tiempo antes de que saliera el Workflow Foundation como se puede ver en la siguiente figura obtenida de la guía Application Architecture for .NET: Designing Applications and Services.
.png)
Como podemos ver en esta figura, en la parte de lógica de negocios están estipulados los workflows de negocio, pero ¿por qué así? Bueno, porque la idea del workflow es orquestar procesos invocando métodos del negocio, no creando el código del negocio dentro del workflow todo esto con el fin de facilitar la mantenibilidad del proceso. Además, que pasaría si queremos llamar un método sin usar el workflow que lo contiene, pues si el código esta en el workflow, tendríamos que reprogramarlo, pero si esta dentro de un componente de lógica de negocios el mismo código se utiliza en el llamado desde el workflow como del servicio o el UI que lo este invocando.
Wrokflow as a Service
Si revisamos los componentes disponibles en la versión del workflow que esta en el framework 3.0 y la que esta en el 3.5 vemos que solo varía en dos figuras.
El SendActivity es para consumir un servicio – ojo que no dice un servicio Web aunque esta incluido a la hora de escribir servicio - y el ReceiveActivity. Este último nos permite exponer un workflow como un servicio, lo cual nos permite a cumplir en parte la arquitectura que estamos viendo en la figura tomada del pattern and practices.
No hay comentarios:
Publicar un comentario