I’m going to ask an ignorant question (feel free to point and laugh). Would it make sense to put Mbeans in a workflow running in a clustered environment?
As I thought through how clustered Camunda servers operate it’s obvious that a specific task could execute on any of them, so you couldn’t poll a specific Mbean server for an attribute. If the task were long-running, you might be able to get the value, but it would be hit and miss?
I’m really just looking for confirmation of my assumption that implementing Mbeans (as attributes, not notifications) in a workflow doesn’t really make sense.
Thanks.
@mppfor_manu - Good question.
You mentioned “clustered environment” and MBeans. I’m pointing this out because it is possible to have two distinct architectures. Though both subscribing to JMS/messaging infrastructructure: One clustered and the other federated. Just wanted to say that a federated architecture, though following similar qualities, applies a few different patterns (though still employing message/middle-ware, EAI, etc.). And, your question was about MBeans…
So, back to your question: “Would it make sense to put Mbeans in a workflow running in a clustered environment?”
If we’re strictly talking about an executable, Camunda process-model (the model itself), then my answer is “no” - it doesn’t make sense. However, MBeans do make sense within the surrounding architecture. And, there are options for extension.
Reason behind my answer:
And, in terms of your executable-model, “polling a queue” (though I prefer the reactive pattern), the Camunda engine internalizes event subscription. Meaning that, at least from my experience, the BPMN message receiver does not subscribe to external event infrastructure.
HOWEVER… I still rely on EAI-messaging infrastructure. And, an MBean is a good approach for getting a message-event off the queue and into Camunda. Though I prefer implementing this requirement with Apache Camel because it offers additional features; supporting general event-routing/management - matter of preferences…
Back to details - a scenario illustrating my answer:
- MBean pulls the message from the queue
- Forward the message by calling on the camunda API (directly or via ReST) and send the event-message payload (text, json, etc) to your waiting BPMN message receiver. In BPMN terms, a “catching” start or intermediate message event
- The Camunda runtime then saves the message to its system database (basically - see source-code for implementation details)
- whereby one of the Camunda nodes picks it up and either starts a new process or correlates to existing, in-flight process instance.
I have examples for calling on both ReST and Java APIs. Let me know if you’d like to see these… My code leans towards Apache Camel (my preference). Camunda also provides excellent examples.
Firstly, thank you so much for taking the time to answer, Gary. It sounds like you’re confirming what I thought, however.
Our implementation will take advantage of Mbeans outside of the process. I’ve also asked our developers to investigate the use of Mbean notifications, which could be valuable within a process to send an “alarm” under certain circumstances.
Michael
Because you referenced clustered servers - I didn’t bring up CDI events. However, WildFly/JBoss look to be getting closer to reasonable event technology supporting cross-node requirements.
Optionally, use CDI-Events (resources) with hooks into cross-node JMS services… and this does work and provides robust transaction requirements.
The technology really gets interesting also when bringing such this as “grid” DBMS (etc.). It’s a loose tech’ definition… I think Camunda has a demo. Lost the link/reference though (i.e. Kafka?).