Como les comente en un post anterior, los videos del webcast de arquitectura están disopnibles en channel9. Sin embargo, me tomo la libertad de ponerles el video en el blog para que lo puedan visualizar desde aca – aunque en “streamming” desde channel9.
5.08.2013
Webcast de Arquitectura
La serie de web cast acerca de arquitectura de software que finalizaron el mes pasado, está disponible en Channel9. Ahí los pueden ver o bajarlos en el formato de su gusto. Les dejo los links de cada uno de los webcasts:
Webcast 1 – Arquitectura de Software – definición y Evolución
Webcast 2 – Arquitectura Distribuida
Webcast 3 – Workflows de Negocio en la arquitectura de software
Webcast 4 – Diseño y polimorfismo
Webcast 5 – Seguridad a nivel de software
Webcast 6 – Gobernabilidad
Webcast 7 – SOA
Webcast 8 Pruebas Unitarias
http://channel9.msdn.com/Blogs/DevWow/Visual-Studio-para-Arquitectos-de-Software-8-Pruebas-Unitarias
Technorati Tags: .NET,Arquitectura de software
4.30.2013
Utilizando un cache distribuido en nuestro middleware – Parte 1
Cuando creamos un middleware para exponer servicios y procesos de negocios estamos aprovechándonos de las capacidades que nos brindan los componentes centralizados de estas arquitecturas – servidores de aplicaciones, bus de servicios, etc. Por ejemplo, del servidor de aplicaciones podemos aprovecharnos de las capacidades adicionales de hosting y trazabilidad, y del bus de servicios ruteo, escalabilidad, desempeño, etc. Sin embargo, existe una característica muy común que normalmente aplicaciones solo a a nivel de aplicación web: el caching.
El caching a nivel web es muy utilizado a través del objeto cache. Sin embargo, este cache esta limitado al uso por parte de la aplicación que lo contiene; es decir, normalmente cuando ponemos variables o recursos en el cache, lo hacemos para que estos puedan ser accedidos por usuarios de un sistema en particular. Por ejemplo, si tenemos varias aplicaciones en un servidor Web, y dos aplicaciones requieren la lista de países, normalmente cada aplicación pone en cache esta lista, por lo tanto la vamos a tener “duplicada”. La siguiente figura nos muestra este escenario.
Cache Distribuido
La opción para tener cache en arquitectura distribuida es utilizar un cache que me permita hacer “caching” a nivel de servicio y no a nivel de aplicación. En este esquema, como las diversas capas de presentación solamente consumen servicios entonces vamos a aprovechar la posibilidad que se abre a la hora de que muchos UI ( pantallas ) puedan consumir datos del mismo cache, por lo tanto la aplicación móvil de POS puede acceder el cache de países de la misma forma que el sistema web de compras y facturación lo van a utilizar. Esto garantiza que el uso del cache sea lo más optimizado posible. En el siguiente diagrama se ven las diferencias a la hora de utilizar el caching a nivel de servicios y lógica de negocios.
Opciones Disponibles
A nivel de componentes de cache distribuido existen varias opciones como Oracle Coherencia y el Windows AppFabric. Ambas soluciones nos permiten crear un cache de acceso rápido distribuido; es decir, permiten crear un cache compuesto de una hasta cierta cantidad de maquinas – varia por producto – siendo la memoria de estos el espacio total que se tiene para utilizar el cache. En post posteriores vamos a profundizar en el tema de cache de AppFabric y el Oracle Coherencia para .NET.
2.07.2013
WebCast de Arquitectura
Los invito a participar en una serie de webcast que estaré brindando acerca del tema de arquitectura de software. En el mismo se van a estar tocando temas tales como:
- ¿Qué es arquitectura?
- ¿Que hace un arquitecto de software?
- Arquitectura distribuida
- Buses de Servicio
- BPM
- Seguridad
- Gobernabilidad
- Computación en la nube
- Pruebas
y muchos temas más. Son 10 sesiones, las cuales quedarán grabadas y se podrán ver en el mismo url. El link de registro es el siguiente:
http://msdn.microsoft.com/es-ar/jj920131(es-ar)
Etiquetas de Technorati: Arquitectura de Software
1.12.2013
Namespaces–Windows Service Bus
A la hora de trabajar con el Service Bus – tanto en Windows Server como en Windows Azure – vamos a lidiar con varios conceptos que son nuevos desde el punto de vista del bus de servicios, ya que en otros contextos ya es de todos conocidos el término. El primer concepto sin duda será el de los “Namespaces”. Los Namespaces se utilizan en el service bus para hacer todo el trabajo relacionado con direccionamiento, aislamiento y administración. Todas las entidades que se crean lo hacen dentro del alcance de un namespace de un servicio.
Aislamiento
Tal y como se explica en el msdn[1], un bus de servicio en Windows Server puede servir como una plataforma de mensajes para varias aplicaciones. Para poder aislar cada una de estas aplicaciones se utilizan los namespaces, los cuales identifican las aplicaciones dentro del bus de servicios – cada aplicación tiene un namespace único.
Direccionamiento
A nivel de direccionamiento, el bus de servicios utiliza los namespaces para direccionar los mensajes a las entidades correspondientes. Esta dirección – o ruta – inicia con el nombre del namespace del servicio. Además, se permite utilizar nombres específicos de servidores en la ruta. Un ejemplo de una ruta es el que se muestra a continuación:
Endpoint=sb://WIN-A07V80FKRPL/ServiceBusDefaultNamespace;StsEndpoint=https://WIN-A07V80FKRPL:9355/ServiceBusDefaultNamespace;RuntimePort=9354;ManagementPort=9355
Como podemos ver en la dirección anterior, se agrega el nombre del servidor y el namespace del servicio a la dirección en el endpoint.
Administración
A nivel de administración, cuando se crea un namespace se debe indicar cuales usuarios o administradores serán los propietarios del namespace. Los administradores de un namespace puede crear, modificar o eliminar entidades – colas y tópicos {más de esto en los siguientes temas}. Los administradores también pueden definir reglas de autorización para cada una de las entidades del namespace dentro del bus de servicios.
Ejemplo – Crear un Namespace
Para ilustrar el tema, vamos a trabajar directamente en un ejemplo de un namespace en el bus de servicios de Windows. En primera instancia, debemos validar cuales namespaces ya existen dentro del bus, ya que como dijimos anteriormente, los namespaces deben de ser únicos. Para esto, vamos a utilizar Power Shell en la consola creada para el Windows Service Bus.
Una vez en la consola digitamos el comando get-SBNamespace el cual nos va a enumerar todos los namespaces que existen en el bus en el momento de la consulta. En nuestro caso, no existe ninguno, solamente el que se crea por defecto cuando se instala el bus de servicios.
Ahora procedemos a crear nuestro nuevo Namespace, el cual llamaremos Arc3LabsDemo. Para esto, digitamos en Power Shell el siguiente comando:
New-SBNamespace –Name Arc3LabsDemo –ManageUsers Adminstrator
En este caso, estamos creando un namespace que se llama Arc3LabsDemo y estamos agregando al administrador del servidor como propietario del mismo. En la pantalla anterior se puede ver la ejecución del comando y el resultado del mismo.
Ahora que ya tenemos el namespace podemos utilizar Power Shell para ver el namespace con el comando get-SBNamespace, sin embargo, vamos a utilizar una herramienta creada por Paolo Salvatori llamada el Service Bus Explorer la cual nos permite ver de forma visual nuestros namespaces, nuestras entidades y muchas cosas más que iremos abarcando posteriormente. El link de la aplicación es el siguiente à http://code.msdn.microsoft.com/windowsazure/Service-Bus-Explorer-f2abca5a
Una vez descargado, lo ejecutamos y procedemos a conectarnos al namespace correspondiente vía File à Connect. Tenemos varias opciones para esto, pero ya que tenemos creado el namespace, podemos utilizar Power Shell para generar el endpoint del namespace y con este endpoint procedemos vía Service Bus Explorer a visualizar nuestro namespaces y respectivas entidades. Para esto, procedemos a ejecutar el siguiente comando:
Este comando nos va a generar un archivo de configuración con todos los endpoints para todos los namespaces que existen en nuestro bus de servicios. El siguiente archivo nos muestra dos endpoints, uno para el namespace creado por defecto, y otro para el ARc3LabsDemo el cual recién creamos.
Ahora copiamos el endpoint de Arc3LabsDemo y procedemos a pegarlo en el ServiceExplorer tal y como se ve en la siguiente figura.
Como se puede ver en la figura anterior, seleccionamos la opción ServiceBusForWindowsConnectionString y procedemos a pegar la hilera generada en el archivo de configuración. Al darle click al botón Ok, vamos a poder ver todas las entidades que tenemos en nuestro espacio de nombres.
En el siguiente post continuamos trabajando con las colas y los tópicos en el bus de servicios.
[1] http://msdn.microsoft.com/en-us/library/windowsazure/jj193009(v=azure.10).aspx
Etiquetas de Technorati: Windows Service Bus
12.30.2012
QueryInterceptors en WCF Data Services
Los QueryInterceptors son atributos que nos permiten personalizar la forma en que se llevan a cabo las consultas utilizando WCF Data Services – aunque en realidad sirven para muchas otras cosas más. Creando un servicio para consumirlo desde un dispositivo móvil utilice estos atributos para llevar a cabo una tarea de consulta de forma sencilla utilizando WCF Data Services y utilizando notación JSON. El escenario lo describo a continuación.
Resulta que tengo un conjunto de registros pero solo necesito los registros que tienen una propiedad especifica seteada con un valor especifico. En WCF Data Services esto implica hacer una consulta en Linq y proceder con el filtro. Sin embargo utilizando los QueryInterceptors ya no es necesario crear la consulta en Linq del lado del cliente y puedo proceder directamente desde el servicio. Para ilustrar este caso vamos a ir con un ejemplo.
Supongamos que tenemos una tabla de películas con todas las películas del año, tal y como se ve en la figura ( datos de ejemplo por supuesto )
Ahora bien, resulta que la aplicación móvil solo debe de desplegar las películas que están en cartelera, es decir EnCines = 0. Para llevar a cabo esta tarea, hice un WCF Data Services y le configuré el modelo del Entity Framework para que pueda devolver las entidades. Si no agregamos ningún método o un QueryInterceptor, entonces vamos a poder filtrar utilizando un browser y modificando el query string, o creando un cliente y utilizando Linq. Sin embargo, como ya sabía que requería solo las películas que estaban en el cine proyectándose, procedí a crear un interceptor que me permita devolver solo las películas cuya Propiedad EnCines = 0.
Como se ve en la figura anterior, el QueryInterceptor es un atributo que se le aplica al conjunto de registros que se específica en el atributo, en este caso “Películas”. Seguidamente procedemos a crear una Expresión de Linq en donde establecemos que esa expresión recibe Película y retorna un booleano. Luego con una expresión lambda procedemos a aplicar la comparación deseada.
Como vemos en la siguiente figura, la consulta inicial solo nos retorna los registros de las películas que tienen el atributo EnCines = 0.
Etiquetas de Technorati: WCF Data Services,QueryInterceptos
11.25.2012
Memorias - Arquitectura de Software: !No necesito un Servidor de Aplicaciones
| Leyendo por ahí un blog de arquitectura en inglés me encontré con una aseveración que me dejó pensando seriamente en como discernir en que leer y que no leer en la web. El autor – un arquitecto de software – daba 4 razones por las cuales el observaba que un servidor de aplicaciones era innecesario. Las razones eran un tanto básicas, pero el blog ha causado hasta cierto punto, movimiento en el sitio. Por este blog sentí un sentido de urgencia en escribir un post acerca del porqué SI debemos tener un servidor de aplicaciones y de eso se tratará este post. |  |
Reutilización de la lógica de negocios
En muchos casos los desarrolladores usan el término reutilización para vender positivamente una idea, y al mismo tiempo pueden usar el término para minimizar el impacto que pueda tener el hecho de reutilizar la lógica de negocios en algún desarrollo. Sin importar si utilizamos un servidor de aplicaciones o no, la reutilización es lo que nos ha motivado a evolucionar a la hora de hacer software; haciendo memoria podemos ver claramente que primero queríamos reutilizar tipos, luego componentes, luego procesos de negocios internos y luego procesos de negocio externos. Es necesario reutilizar para prevenir la duplicación del código, el sobre trabajo y sobre todo para permitir integrar procesos de negocios que nos permitan crear de forma RÁPIDA y CONSISTENTE procesos de negocio para apoyar el buen funcionamiento de los diversos clientes externos e internos que puedan necesitar de los servicios del área. En que casos no es relevante reutilizar – bueno, si tu aplicación es algo monolítico, que nadie más va a necesitar entonces no creo que sea necesario el sobre esfuerzo requerido para hacer una aplicación con servicios reutilizables – una aplicación para estacionamiento o un sistema de inventario para la panadería de la esquina son ejemplos de estos casos.
Gobernabilidad de la solución
La gobernabilidad es una palabra de moda en nuestros días a la hora de desarrollar software, pero nadie puede negar su importancia en una arquitectura de software. El software que construimos debe de ser monitoreable, es decir, debe darnos información suficiente para saber que está ocurriendo con nuestros servicios, que excepciones pasan en nuestro eco sistema, cuál es el servicio que más se utiliza, sobre que protocolo es que más se utiliza – así es, el mundo es más que solo HTTP. Si no tenemos un servidor de aplicaciones me pregunto ¿ Cómo vamos a tener gobernabilidad? En .NET, tenemos el Windows AppFabric para tener gobernabilida sobre los servicios y procesos de negocio que tenemos automatizados, y toda esta información queda en una base de datos SQLServer desde donde tenemos la capacidad de ver en que estado esta nuestra plataforma. Volviendo con la argumentación del blog que leí – y que no les voy a mostrar – no me explico como tener gobernabilidad sin un servidor de aplicaciones.
Escalabilidad
Por supuesto que existen diferentes niveles de escalabilidad en las aplicaciones de software. En una arquitectura distribuida, es necesario tener la posibilidad de que la aplicación pueda escalar pero no a nivel de interface de usuario si no a nivel de procesos de negocio. ¿Qué sentido tiene tener una aplicación web que sea escalable si tengo un proceso instalado en dos servidores distintos ( como suele ocurrir cuando no tengo un servidor de aplicaciones ) y solo en uno de los dos esta escalable? ¿No es mejor tener un solo proceso cacheable, muy escalable, donde todas las aplicaciones que consumen el servicio tengan la misma experiencia a la hora de interactuar con el proceso?
Calidad
El hecho de no tener un servidor de aplicaciones ( o varios ) en donde los procesos automatizados residan y puedan ser reutilizados por todas las aplicaciones que lo requieran nos va a permitir garantizar que la calidad de nuestros productos se va a ir incrementando. Por ejemplo, si tengo un servicio que tiene una operación que me retorne el estado de cuenta de un cliente, y este funciona correctamente en la aplicación 1 – la que inicialmente llevo a crearlo – cual es la probabilidad de que me funciona correctamente desde otra aplicación – 100%.
Movilidad
Indudablemente que uno de los cambios más drásticos en estos días es la incorporación de dispositivos móviles. Si tenemos un servidor de aplicaciones, nuestras aplicaciones móviles serán en su gran mayoría construidas con composición de aplicaciones; es decir, consumiendo servicios y construyendo los servicios que hagan falta. Es claro que estos servicios que consumimos desde nuestros dispositivos móviles son exactamente los mismos que usa nuestro software en la empresa, por lo tanto tenemos garantía de que el software que utilizamos tendrá el mismo comportamiento a nivel de negocio sin importar desde donde se ejecuta. Sin un servidor de aplicaciones los servicios estarán en un limbo en donde nadie sabe que existen ( solo los creadores ) y por lo general nadie los reutiliza, por lo que cada aplicación tiene que desarrollar completamente sus soluciones. Además por lo general, estas soluciones van ligadas al UI seleccionado para desarrollar la aplicación.
Seguridad
La seguridad parece ser uno de los temas más importantes en temas de tecnología, sin embargo, a la hora de analizar como es manejada en cada uno de los sistemas desarrolllados en las empresas, parece que no importante tanto como se preveía. Esto se da principalmente porque la seguridad parece de entrada delegada a las personas encargadas del área de infraestructura y nosotros como desarrolladores olvidamos que somos los primeros responsables de que nuestro software sea seguro. En este aspecto, un servidor de aplicaciones es un componente ideal para poner nuestros procesos de negocios a funcionar de forma correcta, ya que la autenticación y la autorización podemos aplicarla de forma uniforme a los servicios que tenemos funcionando y por lo tanto, todas las aplicaciones que utilicen nuestros servicios utilizarán los mismos mecanismos de seguridad.
Estos son solamente algunas razones por las cuales debería utilizarse un servidor de aplicaciones dentro de la empresa: sin embargo, podríamos escribir un capítulo de un libro – ya en camino 
- de las razones por las cuales en muchos aspectos más, un servidor de aplicaciones me va a ayudar a tener una plataforma más segura, estable, ágil y escalable.
Technorati Tags: Application Server
11.17.2012
Un Bus de Servicios en Windows – Parte 1
Uno de los términos más de moda en este tiempo es el bus de servicios. Gracias al impulso que la arquitectura orientada a servicios le ha dado, es normal ver que las empresas tengan un bus de servicios implementado, estén implementado uno, o en este momento estén pensando o en el proceso de adquirir un bus de servicios.
Durante mucho tiempo, en el mundo de Windows, hemos carecido de un bus de servicios por parte de Microsoft y lo único que hemos tenido al alcance es el Bus de Integración de Biztalk Server – que es algo parecido { pero diferente, al menos con objetivos diferentes}.
Windows Service Bus
Pero la espera ha terminado. En días pasados, se liberó el Windows Service Bus 1.0. ¿Y qué es el Windows Service Bus? Como lo dice su documentación en el msdn, es un conjunto de componentes que proveen las capacidades de “messaging” del bus de Windows Azure pero sobre Windows – on premises. Este bus, nos va a permitir crear y ejecutar aplicaciones desacopladas y basadas en mensajes ( Definición típica de un bus de servicios 
).
Características de Messaging del Windows Service Bus
El Windows Service Bus soporta el mismo conjunto de caracterísitcas del Azure Service Bus; lo que quiere decir que nos ofrece almacenamiento confiable de mensajes y obtención de mensajes desde el bus a través de varios protocolos y APIs. Para llevar a cabo estas tareas, nos ofrece dos formas para interactuar con el mismo: Service Bus Queues y Service Bus Topics.
Service Bus Queues
Las colas del bus de servicio nos permiten crear aplicaciones en donde se le permite al recibidor del mensaje procesarlo a su propio ritmo. Además, nos permiten tener balanceo de cargas al poder tener múltiples procesadores que aceptan el mensaje desde la misma cola. Existen muchos escenarios en donde se pueden utilizar este tipo de esquemas a través de colas de mensajes, pero quizás el más popular es el caso del “check out” del carrito de compras de Amazon, el cual por escalabilidad esta implementado utilizando un esquema de colas.
Service Bus Topics
Este es un esquema pub/sub – publicador /sucriptor – que nos permite que muchos suscriptores – y de forma concurrente – puedan de forma independiente obtener una copia de un mensaje. Este escenario es muy común en los buses de integración, en donde un mismo mensaje puede activar muchos componentes del bus, tales como adaptadores, orquestaciones o mapeos. Igualmente se da en escenarios donde un mismo mensaje esta obligado a tomar dos caminos diferentes a la vez para su respectivo procesamiento.
Technorati Tags: Windows Service Bus
11.13.2012
Memorias - Arquitectura de Software: Hágalo todo con SOA !!!
Una de las afirmaciones más temerarias que esucho con mucha frecuencia, esta relacionado con el hecho de que las empresas creen que por el simple hecho de implementar una arquitectura orientada a servicios – SOA – todos sus problemas están resueltos. Esto también se ve reforzado por la idea que venden los proveedores de productos SOA cuando dicen: “Pasálo todo por el BUS de servicios y todo listo”. Esto por supuesto es incorrecto ya que aunque SOA como arquitectura ayuda a paliar los dolores normales de una organización en materia de sistemas, hay que recalcar que el fuerte de SOA va más por un tema de integración de aplicaciones heterogeneas y por extender la vida de un producto de software, que por un tema de arquitectura de dominio – ejemplo de que no se debe de pasar por un bus es el pago de tarjeta de crédito, ya que el timeout de una transacción del lado del cliente puede tener resultados inesperados en la transaccionabilidad del sistema.
Respecto a este tema, es importante diferenciar los tipos de arquitectura a los que nos vemos enfrentados todos los días. Esto principalmente porque no tienen sentido hacer una aplicación en .NET, pero como ahora estoy utilizando SOA le voy a poner un “overhead” innecesario a la transacción – no solo .NET Java, PHP o cualquier otra plataforma.
Nuestras aplicaciones de dominio – ejemplo RRHH, ERP, CRM, etc. – deben ser expuestas a través de servicios pero a través de un servidor de aplicaciones o un bus de dominio – tal como el Windows Service Bus – sin tener que ir a pasar por un bus de SOA que te va a solicitar transformar tus esquemas SOAP a un formato neutral – por lo general XML – para que pueda ser consumido desde cualquier aplicación en otro formato.
Ahora bien, para los que ya se están preguntando porque a través de servicios si no va a pasar por un bus de datos la respuesta es muy sencilla: nunca sabemos quien va a necesitar nuestra funcionalidad. Esta es una premisa que todo arquitecto debe de tener en cuenta a la hora de desarrollar sus aplicaciones “esperar lo inesperado”. Para entender un poco mejor el escenario vamos a poner un ejemplo:
Supongamos que tenemos una aplicación financiera que se va a utilizar entre otros roles, por oficiales de servicio al cliente. Considerando que los agentes de servicio al cliente ya utilizan un CRM, no existe necesidad de parte de la institución de tener dos aplicaciones corriendo y poniendo a la agente a digitar en dos lados distintos con una alta posibilidad de error, además de incrementar la superficie de ataque ( a nivel de seguridad ). Es casi seguro que la solución óptima y que atraerá más a los clientes es el poder desarrollar sobre el CRM las interfaces contra la aplicación recién adquirida, lo cual justifica el uso de servicios para que al final solo sea pintar pantallas y consumir servicios.
Y entonces cuál es el rol de una arquitectura orientada a servicios? SOA nos va a permitir integrar nuestras aplicaciones sin importar la plataforma, y para ganarme esa versatilidad en la integración puedo darme el lujo de tener esa latencia en la transacción.
El escenario antes descrito desde el punto de vista de arquitectura se puede ver en la siguiente figura:
¿Que tecnologías debo utilizar?
En una arquitectura de dominio desarrollada en tecnologías microsoft lo mejor es utilizar el Windows AppFabric y el Service Bus de Windows – tema a tratar en otro post. En una arquitectura SOA si la tecnología que se utiliza es microsoft lo recomendado es utilizar Biztalk Server.
Technorati Tags: SOA,Arquitectura de Dominio
8.12.2012
BPM y Workflow Foundation – Parte 3
Continuando con la tercera entrega de la serie de BPM utilizando tecnologías Microsoft, en este post vamos a realizar un workflow básico, lo vamos a instalar en el IIS/WAS y lo vamos a monitorear utilizando el Windows AppFabric.
El Workflow
En esta ocasión vamos a crear un workflow muy simple que va a llevar a cabo dos operaciones muy básicas a partir de una lista de números. Primeramente va a calcular el valor promedio de los ítems contenidos en la lista, y seguidamente va a dividir la lista de números en números pares y números impares. Iniciamos creando el workflow para ser consumido a través de WCF tal y como se ve en la siguiente figura.
El workflow se puede ver en la siguiente figura.
Las figuras marcadas con rojo son las de activación del workflow vía el proxy de WCF y la de respuesta respectivamente. En la de activación se recibe como parámetro la lista de números con la que vamos a trabajar.
En la de respuesta se retorna la lista de pares, la lista de impares y el promedio calculado.
Probamos el workflow ejecutándolo en el WCFTest y vemos que funciona correctamente.
Ahora procedemos a instalar el workflow en el IIS/WAS, teniendo al AppFabric para monitoreo del workflow –el tema de los perfiles de deployment lo trataremos en otra serie. Para esto creamos una aplicación de consola y agregamos una referencia al servicio para poder activar el workflow.
Luego consumimos el servicio desde la aplicación de consola.
Si ejecutamos el código anterior el resultado es el siguiente:
Ahora procedemos a ver en el AppFabric como se ha estado comportando este workflow y este servicio en WCF; para esto vamos al sitio web dentro del IIS y vemos el dashboard del IIS.
Como podemos ver en el Panel del AppFabric, se han ejecutado 15 llamados a diversos servicios, y se han activado 5 workflows en ese lapso de tiempo ( 1 hora ).
Como podemos ver en este post, cumplimos con 3 de las 4 características de un BPM:
- Tener un diseñador de BPM en el Visual Studio ( en este caso 2012)
- Tener un motor de ejecución –> el que instancia y ejecuta el workflow, que es activado por un proxy WCF.
- Se puede monitorear utilizando el Windows AppFabric.
Suscribirse a:
Entradas (Atom)
