Sugerir una estrategia persistente para un sistema de flujo de trabajo

Question

Estoy en el proceso de crear una herramienta de configuración de UI para mi proyecto de mascota. Un aspecto de esta herramienta permite que el usuario final define su orquestación. Luego necesito guardar esta definición de orquestación en una base de datos. Habrá una versión ejecutable de esta definición en un sistema en ejecución. La versión ejecutable se crea dinámicamente bajo demanda.

La idea es separar el DEFINICIÓN de EJECUTABLE Versión para que tenga la flexibilidad de elegir la versión de tiempo de ejecución entre BPMN o JPDL o una solución de flujo de trabajo basada en POJO (Beanflow).

Limitación: No puedo usar los editores BPMN que vienen con marcos como JBPM, Activiti, etc., ya que no puedo usar mi propia interfaz de usuario que sea específica para mi dominio.

Necesito sugerencias sobre cómo persistir la definición.

1. ¿Debo usar tablas RDBMS? Si es así, ¿hay un esquema de DB en el que pueda pedir prestado que esté cerca de los conceptos de orquestación?

2. ¿Debo serializar mi definición al documento de instancia BPMN/JPDL XML?

3. ¿Hay otros formatos simples que pueda usar?

Answer 1

Por "orquestación", supongo que te refieres a un máquina de estados finitos. Donde el estado actual dicta qué transiciones se pueden seguir a otros estados. La representación de estados y transiciones como bordes y vértices a menudo produce un Gráfico Acíclico Dirigido, sin embargo, hay momentos en que el gráfico en bicicleta (p. Ej.

En la práctica, separar la definición de la ejecución requiere un formato de persistencia que pueda acomodar fácilmente la personalización. A medida que evoluciona su sistema, encontrará una serie de casos de borde no anticipados cuya solución no debe requerir alterar un esquema de persistencia, solo código. Esto implica XML o una solución nosql, algo cuyo esquema se cambia fácilmente o no existe.

Ahora, después de haber escrito mi propia definición XML para este propósito (por razones poco interesantes, excluiré), mi sugerencia es usar JPDL (o BPMN). La razón es que sus definiciones probablemente incorporan lo que esté considerando ahora, en el futuro y habilitará la personalización, como colgar datos arbitrarios o comportamiento de ellos en un punto dado. También obtiene la ventaja de las herramientas ya construidas, no solo la interfaz de usuario, para lidiar con la detección de ciclo y garantizar que haya una ruta para completar, por ejemplo.

Algunas de las características interesantes que sé que posee JPDL son la capacidad de ayudar a fusionar procesos bifurcados, tareas cronometradas (incluidas las que se repiten periódicamente) e instalaciones para enviar notificaciones. Este último elemento - Notificación - lleva una mayor exposición. Una de las cosas que he encontrado con mi propio sistema es la necesidad de enviar un correo electrónico configurable cuyo contenido se basa en los datos que fluyen. Estos motores existentes lo hacen relativamente fácil al proporcionar una forma de completar las variables, por ejemplo, en un texto que luego se evalúa dinámicamente en el tiempo de ejecución antes de la transmisión. También proporcionan puentes entre el motor y cualquier almacenamiento de usuarios con el fin de enviar notificaciones a grupos de personas, tardarlos y hacer cumplir la política de seguridad.

Finalmente, dependiendo del alcance de su sistema, probablemente también usará una base de datos. Lo que sugiero es almacenar el XML y los datos que se orquestan en la base de datos en un formato serializado. Luego, si los datos se alteran a medida que viaja a través de la ejecución, escriba serializaciones de los datos, y quizás también se cambia el flujo de trabajo si también se cambia, en una tabla de registro de historial/auditoría.

Answer 2

No usaría tablas RDBMS, o si lo hace, almacenar las definiciones como blobs de texto. Intentar hacer registros para la definición es una mala idea porque es mucho más inflexible y difícil cambiar su definición con el tiempo. Muchas personas usarían diferentes enfoques, pero usaría JSON o YAML, y evitaría XML. La motivación para eso es hacerlo lo más simple posible. Intentar usar XML, especialmente un formato específico formal de XML, te hará pasar mucho más tiempo cumpliendo con una especificación exacta que en realidad no hace nada para ayudar a lo que estás tratando de lograr. JSON y YAML son muy fáciles de trabajar desde una perspectiva de código. Yaml es más fácilmente legible por los humanos y más fácil de editar, y no es tan complicado para la puntuación y escapar como JSON. JSON se usa más ampliamente y es más pequeño que YAML. JSON también tiene una contraparte binaria, BSON, si el tamaño del documento es una preocupación.

Una vez que tenga un importador/exportador que va a/desde sus objetos internos a su formato de datos, entonces persistirá usando RDBMS u otros mecanismos, será sencillo. Incluso podría usar CouchDB, que podría ofrecer otros beneficios a su aplicación y puede ser un gran ajuste.

Answer 3

¡Muy buena pregunta! Aquí están mis dos centavos:

1. RDBMS: Si hace esto, podrá consultar las instancias de flujo de trabajo, por ejemplo, ¿qué tokens están en 'nodo X'?
2. Almacenamiento XML Como CLOB: La simplicidad es la verdad de esta solución, pero en realidad no puedes consultarlos, solo obténlos por identificación
3. Coso: Hay muchas soluciones diferentes para diferentes problemas. Mongodb es una solución popular, proporciona persistencia orientada a documentos.

Answer 4

¿Qué tal una serialización simple de la interfaz de usuario compuesta, por ejemplo? Xstream y luego almacene los bits serializados en la base de datos como una columna binaria. Luego, cuando el usuario inicie sesión, obtenga los datos asociados, deserializa, inicializa si es necesario y muestra.