Definición de lenguaje de definición de Patrones y Modelos de Procesos
De MorfeoWiki
Tabla de contenidos |
Discusión
A fin de fijar ya las ideas, en esta sección se plantea la discusión. Se agradecen las contribuciones.
Un patrón es la definición, mediante algún modelo de proceso como por ejemplo una red de Petri, de un flujo de trabajo.
Un patrón es genérico, vale para todos los posibles recursos que sigan dicho patrón. [OK]
Los recursos siguen o hacen uso de patrones. Cuando un recurso indica que va a hacer uso de un patrón se comprueba si ese patrón está ejecutándose en algún motor, en caso afirmativo se creará un nuevo caso de la red asociada para el recurso. En caso negativo se elegiría el motor en el que se desplegará y se instalará. [OK]
¿Quién decide en qué motor se instanciará el patrón? [ En principio podemos pensar en un usuario/agente/sistema que se encargará de navegar entre recursos y "seleccionar" para el despliegue. Esta funcionalidad podrá ofrecerla el motor como un añadido, pero en una primera aproximación yo me limitaria a incluir una funcionalidad que permita asignar una URI al motor "a mano o a interfaz" y que este se encargue del proceso de "carga". La URI seré de un recurso, el motor cargará/creará redes y casos de todos los patrones asociados al recurso]
Cada patrón se ejecutará en un motor de Workflow (DUDA: El mismo patrón puede estar ejecutándose en diferentes motores?) [Se generarian inconsistencias si un mismo caso esta en varios motores a no ser que se provea de un mecanismo de federación/reflexion, pero no parece problematico que un patron lo esté, salvo porque se pueda instanciar un caso ya instanciado en otro lugar. (Imaginemos) El motor "Modifica" los recursos que instancia/ejecuta de modo que quedan marcados como "Desplegados" a fin de evitar esto. De todas formas yo me restringiria a un unico motor en el modelo por simplificar]
Cuál sería la razón para mantener todas las instancias de un patrón en un único motor? Porque es más rápida la creación de la instancia? Y la carga a la que se sometería al motor? [el motor traga mas (bastantes mas actualmente creo) de 30.000 nuevas averias diarias con sus cambios de estado, rendir rinde... que todo se despliegue en un motor evita contemplar mecanismos de inconsistencía y simplifica los escenarios. Por lo demás, es factible (a bote pronto) presentar N motores de N fabricantes ejecutando un patron concreto, siempre y cuando no se compartan casos, si quereis complicarlo por este punto no le veo el problema]
Si el recurso elige el motor donde desplegar su patrón, se reduciría a comprobar si ya está en ese motor y si no, desplegarlo. [OK, o si alguien lo elije]
Los datos que almacena el patrón no deben ser relativos a los recursos que lo usan. Estos datos relativos a recursos se almacenarán en los recursos. Si el patrón necesita leer o modificar esos datos del recurso en algún momento, se los pedirá al recurso en cuestión mediante su interfaz REST. [OK]
«El patrón es como si fuera la clase, no tiene datos de instancia (estos los tiene el recurso)». Aun así, podría tener entonces datos del caso del patrón, necesarios para su funcionamiento interno, pero que no afectan al recurso? Necesita ejemplo. [OK, datos comunes como... "Numero de reintentos"...]
Interfaz REST
Se mantendría la interfaz REST del recurso? Parece que sí, pero se darán situaciones en las que un cliente modifica el estado del recurso a través de su interfaz REST y al mismo tiempo un patrón intenta cambiar ese estado. Todo el mundo es bueno? [NO, si se encarga el motor... se encarga el motor. Un recurso que decice poner al servicio de un patron una serie de atributos no debe permitir que estos se modifiquen por otros medios. Ahora mismo no se como garantizar esto, pero asi debe ser, por construcción del recurso. El recurso sólo aceptará peticiones del motor para aquellos atributos que controla un patron instanciado. Tema peliagudo... para empezar yo pernsaria que "todo'er mundo es gueno"...]
A lo largo de su vida, un recurso establece relaciones con otros recursos. Éstos hacen uso de su interfaz REST para trabajar con él. Si en un momento dado incorpora un patrón, los demás recursos deberían poder seguir trabajando como hasta entonces.
Compilación de un patrón
A partir de la definición de patrón en el lenguaje de definición de patrones se compilará al lenguaje que entienda el motor de workflow donde se va a desplegar. Por ejemplo, si se va a desplegar en el motor de Morfeo, se compilará a PNML [+ Acciones + Manejador OK].
Acciones
Qué debe quedar especificado en la definición del patrón? Un patrón, al relacionarse con tipos diferentes de recursos, accederá a los datos que debe gestionar de forma distinta. Por ejemplo, un recurso ofrece «GET …/tiempo» y otro «GET …/cuenta-tiempo». Así de simple, podría solucionarse con un patrón parametrizado. Es esa la idea?
Las acciones que ahora mismo se definen en el flujo de trabajo, deben quedar fijas al definir el patrón? O a la hora de relacionarlo con un recurso, se podrían añadir acciones para esa interacción?
Eventos
Al definir un patrón, se especifican sus eventos. A la hora de compilar esa definición para un entorno determinado, por ejemplo la máquina de estados, habrá que transformar esos eventos REST al tipo de evento necesario, por ejemplo CORBA.
Y… qué es un evento REST?
Los eventos permiten la interacción entre patrones. Un patrón tiene eventos de entrada y eventos de salida (generados por el propio patrón). Se podrá enlazar un evento de salida de un patrón con uno de entrada de otro patrón. Esos enlaces son, por ahora, fijados en la definición del recurso.
Un tipo de recurso TR1 puede estar utilizando dos patrones, de los tipos TP1 y TP2. Si el recurso puede ser receptor de eventos, debe enviarlos a todos sus patrones, consultar las definiciones de los patrones para saber qué patrones tienen ese evento como entrada, o se especifica en el evento qué patrón (o patrones) es el destinatario?
Tanto el motor, como el patrón o los recursos que siguen el patrón pueden ser receptores de eventos. Si es el motor el receptor, se le debe indicar el patrón y el recurso. Si es el patrón, se le debe indicar el recurso.
Descripción (draft)
Llamemos Patrón a un recurso (contenido accesible por HTTP) que define el ciclo de vida, los cambios de estado y las acciones/interacciones (transformar datos/evaluar expresiones/comunicarse con otros recursos... ) que un recurso realiza durante estos cambios.
Un recurso puede relacionarse con un Patrón a fin de modelar su comportamiento y permitir que este sea gestionado de forma automática (mediante un motor de workflow). Esta relación bien podría ser N:M un recurso se relaciona con N Patrones (i.e un Patrón por cada "situación" "escenario" en el que pueda evolucionar el estado del recurso). Un Patrón se relaciona con M recursos (i.e todos los recursos de una cierta clase emplearan el mismo Patrón para modelar su comportamiento).
Los procesos dentro de este escenario quedarían descritos por el conjunto de los Patrones interrelacionados entre si para dar solución a un problema concreto. Este modo de definir un proceso es claramente convergente con el concepto de Coreografía ( concepto mas avanzado que el de orquestación ). Es posible que no sea necesario definir el Lenguaje de Modelos de Procesos ( que combinaría Patrones ), dado que la interrelación entre patrones puede ser suficiente.
La plataforma SmartFlow podrá obtener (HTTP GET) un Patrón a partir de su URI, verificar si ese Patrón ya esta en el sistema y añadirlo en caso de ser necesario. A partir de ese momento será capaz de dirigir las evoluciones de cualquier recurso que se asocie a ese Patrón. El recurso en cuestión no tendría porque estar "instanciado" en el motor, es decir el motor podría o no encargarse de almacenar los datos relativos el recurso (las dos opciones son interesantes, el motor permite la gestión de recursos externos // el motor permite crear y dar soporte a recursos internamente).
Recursos y patrones
Un recurso es una entidad con un conjunto de atributos que configuran su estado. A esos atributos (a uno o varios en general, pero podemos dejarlo en uno para un caso básico) se asocia un «ciclo de vida» o Patrón. Por Patrón definimos un conjunto de estados y reglas que determinan la evolución de un conjunto de atributos a lo largo de los distintos valores/estados que pueda tomar. Un mismo recurso se puede relacionar con «N» patrones, es decir, un recurso puede tomar parte en varios procesos, tantos como distintos comportamientos puedan asociarse a sus posibles evoluciones.
Por ejemplo, un recurso «Trabajador» puede tener un patrón «Asignación», asociado al atributo "Estado-Asignacion", con un ciclo de vida con estados «disponible» y «asignado». Por otro lado tambien puede tener asociado un Patrón "Gestion Disponibilidad" asociado a un atributo "Disponibilidad" del "Trabajador" con un ciclo de vida que podria tener estados como: "Disponible" "No disponible" "Vacaciones" "Fuera de Turno" "Baja". [ Las evoluciones del Patrón «Asignación» estaran condicionadas a los valores del atributo "Disponible", evoluciones en el atributo "Disponible" pueden implicar cambios en el atributo "Estado-Asignacion"]
Por otra parte, un mismo patrón puede representar una característica interesante para otros tipos de recursos; por ejemplo, un patrón «Cumplir Años» podrá ser utlilazado y compartido en todos aquellos recurosos que tengan la capacida de Cumplir años asi como un atributo Edad.
Así se establece otra relación N:M entre patrones y recursos.
Orquestación y coreografía
Entendemos por Orquestación, la acción de controlar y dirigir de forma centralizada resolución de un problema en la que intervienen diferentes agentes capaces de solucionar si mismos únicamente partes concretas del problema total.
Otro concepto interesante que conviene diferenciar del concepto de orquestación, es el Coreografía, una coreografía también trata de gestionar la resolución de un problema complejo, pero no de forma centralizada. Cada uno de los agentes involucrados en resolución es el encargado de controlar y dirigir su participación en la resolución problema global, no siendo necesaria la existencia de ninguna pieza central que controle dirija las interacciones entre los diferentes agentes. Las coreografías tienen sentido problemas muy grandes, para los que la definición de un único flujo de control es una tarea casi inabarcable.
Orquestación y Coreografía pueden constituir dos formas distintas de afrontar el mismo problema y no deben verse como alternativas incompatibles, más bien todo lo contrario, deben considerarse como dos aproximaciones complementarias, siendo posible pensar coreografías de orquestadores como la forma ideal de afrontar los problemas más complejos gracias a la unión de las ventajas de ambas aproximaciones.
En la actualidad no existe ningún estándar de coreografía suficientemente maduro como para pensar en su posible implantación, tampoco se conocen productos capaces de implementar ejecutar estas coreografías. Siendo hasta la fecha estándares meramente descriptivos.
Recursos y patrones — REST
Tanto los recursos como los patrones se presentan como «recursos REST» accesibles por tanto vía HTTP. A la hora de gestionar un recurso se localizarán los patrones que tenga asociados y se instanciarán (si aún no lo están) en el motor de estados; la máquina de estados podrá controlar a partir de entonces su evolución.
Por ejemplo, se desarrolla un patrón «Cumplir Años» y se publica. Le pedimos a la máquina de estados que gestione un recurso «Persona» que lo utiliza. El motor localizará los patrones asociados a la persona, los descargará y creará tanto la red asociada al patrón (donde se modela el ciclo de vida de la edad), como un caso de dicha red asociado a la persona.
Composición de recursos
Para avanzar un poco es conveniente dar definiciones que fijen conceptos y ejemplos que clarifiquen pensamientos. En una sesión de trabajo hemos "visto" un posible concepto de recurso rest que no sabemos si encaja en todo esto pero que ponemos aquí para discutirlo.
Entenderemos por recurso una entidad con una dirección bien definida, con capacidad (funcionalidad) propia y con un conjunto de atributos que pueden ser accedidos mediante sus propias direcciones y su capacidad de responder a peticiones GET, POST, etc. Además de esto, un recurso tiene la capacidad de incorporar nuevos recursos que, esencialmente, suponen ampliar su espacio de direcciones. Esta ampliación conlleva que el recurso en sí mismo es capaz de responder a nuevas peticiones, aunque sea via delegación al recurso nuevo. Por ejemplo, si nos ponemos en la época pre-móviles, un recurso "proyecto" puede contener múltiples recursos "personal", de tal forma que las direcciones /proyectos/idproyecto/personal/idpersona tienen sentido y responden adecuadamente a las peticiones pertinentes. Cuando aparecen los móviles, una persona adquiere un nuevo recurso y con él la capacidad de responder por ejemplo a /persona/idpersona/movil que devolverá el número de móvil. "Proyecto" no sabe nada de móviles pero en cambio la dirección /proyectos/idproyecto/personal/idpersona/movil ahora tiene sentido y responderá con el móvil de la persona.
Cuando se defina un recurso, se tendrá que definir un conjunto de parámetros, tanto de entrada como de salida, que el recurso requiere para estar bien configurado. La instalación de un recurso nuevo conllevará resolver la necesidad de esos parámetros y habrá que definir unas ligaduras entre los datos del recurso a instalar respecto al recurso donde se instala. Por tanto para todo esto se requerirá un lenguaje de definición de recursos de este tipo y un lenguaje de definición de ligaduras para propiciar la instalación de nuevos recursos.
La pregunta es si ésto tiene o no relación con "patrones", entendidos estos como redes de petri que definen el flujo de control de algún aspecto de un recurso. Es evidente que algunos de los recursos pueden ser perfectamente procesos de negocio en sí mismos y que el establecimiento de una ligadura con el recurso contenedor puede suponer (no sabemos si será así) una "coordinación" entre ambos.
El modelo descrito tiene sentido al pensar en servicios. Por ejemplo, la universidad podría tener un servicio de matriculación por red y en uno de sus pasos hay que realizar el pago. Ese pago puede realizarse por múltiples bancos. Si un banco se asocia con la universidad, podría ofrecer su recurso de pago por red en el momento de la realización del pago de la matricula. Eso supondría añadir un nuevo recurso "pago por banco xxx" al recurso "matricula" de la universidad. El recurso "pago" requerirá unos datos de entrada, que pueden resolverse por el usuario o bien pueden mapearse a datos de la matricula, y producirá unos datos de salida, que también pueden mapearse a datos del recurso "matricula", que seguirá, a partir de obtener esos datos, su flujo de ejecución. ¿Es esto coreografía?
Finalmente, ¡¡¡es importante aclararnos si vamos en buena dirección!!!.
Ejemplos
Creo que nos ayudaría plantear alguna situación concreta de estos conceptos. Aunque lo ideal sería un caso de cierta complejidad, podemos empezar por ejemplos que pongan de manifiesto las principales características y ventajas de alguno de los términos que hay que fijar.
Asignaciones
Se necesita gestionar la asignación de trabajos («Assignments») a recursos humanos («Worker»). Para cada asignación, se mantendrá información sobre el tiempo invertido en su realización, su situación respecto al recurso responsable (ofrecida, asignada, etc.) y su progreso. Los trabajadores disponen de un atributo que modela su disponibilidad.
Los patrones a utilizar son los siguientes:
- elapsed timer — mantiene un contador de tiempo. Dispone de operaciones para arrancar y parar el reloj.
- progress — progreso de una tarea, con estados como created, started, failed, etc.
- allocation — gestiona la asignación de una tarea a un recurso: unassigned, offered sigle, allocated, etc.
- availability — para un recurso que puede estar en los estados free, unavailable y working.
Los recursos que toman parte en este ejemplo serían:
- Worker — un recurso humano que recibe asignaciones y utiliza un patrón availability.
- Assignment — una asignación. Mantiene información sobre su progreso, tiempo invertido y asignación a un recurso.
- Monitor — un recurso interesado únicamente en el aspecto duration de las asignaciones, modelado por el patrón elapsed timer.
En la siguiente figura se muestran los elementos y una posible interacción (coreografía?) entre los patrones. Un trabajador deja de estar disponible, y su patrón availability dispara una transición al estado «unavailable». Ese cambio de estado provoca que el atributo progress de sus asignaciones cambie, mediante una transición en el patrón correspondiente al estado «suspended». Éste cambio a su vez provoca la parada del reloj que contabiliza el tiempo invertido en la asignación.
Arquitectura (draft)
Características de la arquitectura:
- Uso intensivo de URLs. Está claro que una de las ventajas de REST es el poder identificar un recurso con su URL. Habría que plantear cómo lograr que la arquitectura gire en torno a esta idea.
- En el uso habitual de la red el usuario proporciona los datos que permiten a una aplicación ofrecer un servicio. Por ejemplo, al terminar la compra hay que completar un formulario con los datos bancarios. Sería interesante llevar esta idea a la arquitectura, de forma que se solicite un recurso cuando sea necesario.
- En principio el objetivo es lograr una especificación de alto nivel en términos de patrones, recursos y sus relaciones. Al entrar en detalles comienzan a aparecer objetos propios de REST. Por ejemplo, un evento de entrada de un patrón tendrá su correspondiente URL y podría ser considerado un recurso REST. En el momento del despliegue habrá que generar, a partir de esa especificación, el nivel de detalle suficiente para lograr la implementación en algún servicio de contenedor de recursos REST o similar.
Patrones, recursos, roles
La unidad más simple será el patrón, que ofrece un paquete de datos, eventos de entrada y eventos de salida. Al instanciar un patrón en el contexto de un recurso, se obtiene un nuevo recurso (instancia).
Por ejemplo, se dispone de un patrón «cronómetro», con un paquete de datos «tiempo-transcurrido» y eventos para parar y arrancar el cronómetro. Otro patrón «progreso» proporciona estados «en ejecución», «detenido», etc. Se pueden utilizar estos patrones para definir un recurso «monitor de tiempos» que modele el estado de ejecución/parada de una entidad y el tiempo que ésta permanece en determinados estados. Para ello habrá que incorporar al recurso las instancias necesarias y enlazar los eventos para lograr que los cronómetros hagan su trabajo.
Patrón
Un patrón tiene una descripción estática en forma de documento XML con al menos la siguiente información:
- Identificador: La URL asociada a la especificación y que permite descargarla.
- Paquete de datos: Descripción del conjunto de datos gestionados por el patrón.
- Meta-información: Información para catalogar y recuperar patrones. Por definir.
- Documento que define el flujo de trabajo asociado.
- Eventos de entrada: Una instancia del patrón será capaz de aceptar estos eventos.
- Eventos de salida: Se asocian a cambios de estado (alcanzado, abandonado) y transiciones.
- Lista de requisitos: Cada requisito consiste en una lista de los patrones y roles del recurso con el que se relaciona el patrón y los enlaces que se establecerán entre ellos.
- Lista de recursos requeridos: Es posible que un patrón necesite un recurso para funcionar. Por ejemplo, un servicio de reloj para un patrón temporizador.
- Definiciones de roles: Descripción de los papeles que juegan los patrones requeridos.
Paquete de datos
Conjunto de datos que mantiene el patrón. Por ejemplo, una instancia de «cronómetro» tendrá como dato el tiempo transcurrido.
Documento del flujo de trabajo
Especificación del flujo de trabajo, bien en PNML o en WDL, para incorporar fácilmente las posibles extensiones de PNML.
Eventos de entrada
Deben especificarse los eventos de entrada que define el patrón y asociarlos a eventos del flujo de trabajo. Podría ser suficiente con proporcionar un enlace al evento del flujo de trabajo, pero probablemente haya que incluir aquí propiedades que no están presentes en el PNML como el conjunto de datos asociados al evento.
Eventos de salida
Los eventos de salida serán definidos mediante la condición sobre el flujo de trabajo que provoca su lanzamiento. Quizá baste con dar la posibilidad de especificar eventos al «alcanzar un estado determinado», «salir de un estado determinado» y «disparar una transición determinada».
En el evento de salida se incorporan los datos del propio evento. Podrían ser fragmentos del paquete de datos del patrón.
Lista de requisitos
Un patrón puede necesitar enlaces a varios recursos para funcionar. Por ejemplo, un «cronómetro» podría requerir un enlace a un servicio de reloj.
Por otra parte, también es posible que el requisito consista en una serie de patrones que el recurso a enlazar debe incluir. En este caso no basta con indicar el tipo de patrón, sino que es necesario distinguir entre ellos, ya que por ejemplo, dentro de un mismo recurso puede haber dos instancias de «cronómetro» con diferente papel.
De aquí surge la idea de «role» como el papel que un patrón está desarrollando dentro de un recurso.
Instancia de patrón
Además de una referencia a su definición, incluye los valores del paquete de datos y la lista de las instancias de patrones (URLs) que resuelven los requisitos.
Recurso
La especificación de un recurso constará de la siguiente información:
- Identificador: URL donde descargar la especificación.
- Paquete de datos.
- Lista de patrones obligatorios (estáticos) con sus respectivos roles.
- Enlaces estáticos: Propagación de eventos entre los patrones estáticos.
- Lista de recursos asociados obligatorios. Por ejemplo, a un recurso «Venta» es obligatorio asociarle un recurso «Cliente».
Por ejemplo, al combinar dos instancias de «cronómetro» con una de «progreso» y enlazar los eventos adecuadamente, se obtiene un recurso «monitor de tiempos» que modela el progreso de una entidad que puede estar en ejecución o parada y el tiempo invertido en ambos estados. Cada instancia de «cronómetro» está identificada por su role dentro del nuevo recurso: «tiempo de actividad» y «tiempo de inactividad».
Aquí cabe preguntarse ¿dónde está la definición de cada role y qué importancia tiene? En la definición de «monitor de tiempos» se podría incluir la de los roles «tiempo de inactividad» y «tiempo de actividad», ya que son conceptos relativos a ese recurso.
Un nuevo recurso «asignación estudiante» puede hacer uso de «monitor de tiempos» para incorporar esa funcionalidad. Otro recurso «reparación» también la incluiría y podría además añadir otro requisito estático, una instancia del patrón «prioridad». Los enlaces estáticos asociarían los eventos del patrón «cronómetro» que desempeña el papel «tiempo de inactividad» con el evento de entrada que provoca el ajuste de la prioridad.
Instancia de recurso
A lo largo de su ciclo de vida, una instancia de recurso podrá incorporar nuevos patrones y enlaces. En la descripción de una instancia del recurso habrá que incluir:
- Referencia a su especificación.
- Valores del paquete de datos.
- Lista (estática) de las instancias de cada uno de los patrones obligatorios.
- Lista (dinámica) de instancias de patrones con los que este recurso ha establecido una relación.
- Enlaces entre eventos de las instancias asociadas con el recurso, tanto de la lista estática como de la dinámica.
Propuesta de codificación en RDF
Aunque sería posible definir la codificación de estas entidades en XML mediante un esquema, quizá sea más adecuado utilizar documentos RDF, ya que precisamente ponen el énfasis en la descripción de recursos con sus URLs.
En la descripción (especificación) de un patrón, por ejemplo, se daría una lista de recursos como eventos de entrada. A continuación se procedería a describir cada uno de esos eventos.
<rdf:Description rdf:about="http://xerxes.local/patrones/cronómetro">
<ps:incoming-events>
<rdf:Bag>
<rdf:li rdf:resource="http://xerxes.local/patrones/cronómetro/eventos/entrada/parar"/>
…
</rdf:Bag>
</ps:incoming-events>
…
</rdf:Description>
…
<rdf:Description rdf:about="http://xerxes.local/patrones/cronómetro/eventos/entrada/parar">
<ps:description>El evento «parar» detiene el cronómetro</ps:description>
…
</rdf:Description>
Si una instancia de patrón hace referencia a su especificación, se podría favorecer un proceso de descubrimiento, como por ejemplo consultar los eventos de entrada que ofrece el patrón o cuál es el paquete de datos que acompaña a un evento de salida determinado. Ya se ha comentado en alguna ocasión la gran diferencia que supone establecer una relación entre varios patrones cuando es una persona la que lo supervisa, frente a la posibilidad de que se procese de forma automática. Creo que en ambos casos RDF puede ayudar a describir los recursos involucrados.
Posibles ventajas de la arquitectura
- Reutilización de patrones. Composición de patrones para definir unidades más complejas.
- Incorporación de nuevas características (patrones) en ejecución a un recurso.
- Si se contempla la posibilidad de especificar como requisito un patrón abstracto (por ejemplo, sin dar el flujo de trabajo), en tiempo de ejecución podría instanciarse un patrón concreto. Por ejemplo, un recurso «Venta» que requiera un patrón «Progreso de la venta» que gestione el ciclo de vida de la venta: El usuario está seleccionando productos, ha solicitado terminar, en espera del pago, etc. En función del cliente se podría instanciar un caso específico de «Progreso de la venta».
- Quizás favorezca un proceso de crecimiento de una solución a un problema dado, en forma de creación de recursos y establecimiento de relaciones. Por ejemplo, en una venta por Internet, podría comenzarse tan solo con un «Cliente» que solicita una «Compra» a su «Tienda». El cliente modifica el estado del recurso «Compra» añadiendo productos. Al terminar, «Compra» solicita al cliente un «Medio de pago»; no importa cómo el cliente proporciona el medio de pago, aunque quizá contacte con su banco y lo solicite. La «Compra» mantiene una visión simple: Un evento de «iniciar pago» y dos eventos de salida «pago con éxito», «pago fallido». Sin embargo, el proceso de pago puede ser complejo e implicar más interacciones entre «Medio de pago», «Cliente» y «Banco», como solicitar la emisión de una firma digital al cliente.
- Una visión REST de los recursos propone que operaciones de administración se ofrezcan también en los recursos. Si un patrón tiene como requisito un servicio de cómputo de SHA1, habrá que configurarlo al crear una instancia. Esto podría suponer una consulta al RDF de la especificación, la búsqueda de un recurso que cumpla el requisito y una operación PUT contra el recurso «requisito de servicio de cómputo SHA1» para modificar su estado y añadir la URL del servicio.
