Business Process Execution with vertigo
43 views
Skip to first unread message
Oliver Rolle
Oct 25, 2014, 10:58:41 PM10/25/14
to vertx-...@googlegroups.com
Hi community,
I have written a proof of concept (PoC) which allows to execute a business process as vertigo network. The project and a description is located here: https://github.com/orolle/verticleflow.sbpm-flows
The central idea is to enrich FBP with a concept which allows to model business processes - I use subject oriented business process management (SBPM). The founder of FBP played around with a similar idea but its very confused imo (http://www.jpaulmorrison.com/fbp/bdl.shtml).
SBPM is a modelling language for business processes, like UML is for software. Modelling business processes is relevant in many organizational fields, like purchase order processing (customer orders something, which causes a credit assessment of the customer, products have to be shipped to warehouses and bill has to made for controlling / financials). SBPM allows to model these economic (trans-) actions. SBPM has some advantages in comparison to BPMN, as it is turing complete, "supports" process algebra and relatively intuitive imo (but I am biased ;-). Therefore SBPM can be much more easily translated into software than a BPMN modelled business process.
Here is an open book about SBPM: http://www.springer.com/computer/database+management+%26+information+retrieval/book/978-3-642-36903-2
This PoC fuses SBPM and FBP. FBP is a procedural language, which applies a predicate (method) onto an object (data). It has the implicit assumption that the predicate on the object is the same in all contexts. This is not true, as "score with a ball" (predicate = to score; object = ball - I hated grammar in school, never thought I would need it again) is not the same for a soccer player and a football player. The soccer and football player are subjects, which both have to do different "hidden" activities as they score - here we find our FBP components as black boxes. In the PoC I use stateful VertigoComponents as Subjects. These subjects are final state machines which receive and send data to other Subjects and do something - in my implementation they do something when they receive data. The routing of data is managed by the network.
I introduced a new type of selector (but implemented as a simple component) which instantiates business processes and routes data to the right instance (It is related to composite networks: http://www.jpaulmorrison.com/fbp/compos.shtml). I named it ScopeSelector, I called it Closure on this list earlier - I have no idea what is the correct name for such an operator. The business process instance is a deployed vertigo network with stateful componets which interact with each other based on the network topology and a WebService subject which allows the front-end user to interact with these subjects via http + html. The ScopeSelector translates http requests which are routed to its corresponding subject of the right process instance, in which the subject acts on the received request and generates an html response. This selector is needed because the subjects are always stateful and 2 process instances should not influence each other. Many selectors of vertigo do not make sense for processes (as far as I see it, because in a process with multiple instances of the same subject do not make sense because of the subjects statefulness). But one subject (aka. Component instance) might be part of multiple networks at the same time. Maybe a problem for vertigo?
I hope I could transmit on what I am working on. Questions? Suggestions?
best regards
Oli
I have written a proof of concept (PoC) which allows to execute a business process as vertigo network. The project and a description is located here: https://github.com/orolle/verticleflow.sbpm-flows
The central idea is to enrich FBP with a concept which allows to model business processes - I use subject oriented business process management (SBPM). The founder of FBP played around with a similar idea but its very confused imo (http://www.jpaulmorrison.com/fbp/bdl.shtml).
SBPM is a modelling language for business processes, like UML is for software. Modelling business processes is relevant in many organizational fields, like purchase order processing (customer orders something, which causes a credit assessment of the customer, products have to be shipped to warehouses and bill has to made for controlling / financials). SBPM allows to model these economic (trans-) actions. SBPM has some advantages in comparison to BPMN, as it is turing complete, "supports" process algebra and relatively intuitive imo (but I am biased ;-). Therefore SBPM can be much more easily translated into software than a BPMN modelled business process.
Here is an open book about SBPM: http://www.springer.com/computer/database+management+%26+information+retrieval/book/978-3-642-36903-2
This PoC fuses SBPM and FBP. FBP is a procedural language, which applies a predicate (method) onto an object (data). It has the implicit assumption that the predicate on the object is the same in all contexts. This is not true, as "score with a ball" (predicate = to score; object = ball - I hated grammar in school, never thought I would need it again) is not the same for a soccer player and a football player. The soccer and football player are subjects, which both have to do different "hidden" activities as they score - here we find our FBP components as black boxes. In the PoC I use stateful VertigoComponents as Subjects. These subjects are final state machines which receive and send data to other Subjects and do something - in my implementation they do something when they receive data. The routing of data is managed by the network.
I introduced a new type of selector (but implemented as a simple component) which instantiates business processes and routes data to the right instance (It is related to composite networks: http://www.jpaulmorrison.com/fbp/compos.shtml). I named it ScopeSelector, I called it Closure on this list earlier - I have no idea what is the correct name for such an operator. The business process instance is a deployed vertigo network with stateful componets which interact with each other based on the network topology and a WebService subject which allows the front-end user to interact with these subjects via http + html. The ScopeSelector translates http requests which are routed to its corresponding subject of the right process instance, in which the subject acts on the received request and generates an html response. This selector is needed because the subjects are always stateful and 2 process instances should not influence each other. Many selectors of vertigo do not make sense for processes (as far as I see it, because in a process with multiple instances of the same subject do not make sense because of the subjects statefulness). But one subject (aka. Component instance) might be part of multiple networks at the same time. Maybe a problem for vertigo?
I hope I could transmit on what I am working on. Questions? Suggestions?
best regards
Oli
Jordan Halterman
Oct 28, 2014, 4:09:27 PM10/28/14
to vertx-...@googlegroups.com
Sorry, I've been meaning to respond to this but I'm out of town at a conference. Basically, my response is: that is awesome! Seriously, this is amazingly interesting!
I don't know if you saw my other response yesterday, but this is very much in line with my plans for Vertigo 1.0. State in Vertigo I think will become a central theme precisely for these types of applications, the goal being that Vertigo components can be reliably use to model state machines. So, since this post and the other post motivated me, I'm going to write a separate lengthy post detailing the plans for Vertigo 1.0 to kick off the development as Vert.x 3 is stabilizing. I hope everybody will give their input on that discussion. I think your experience here could be a great contribution to that discussion.
In the mean time I'm definitely going to check out this project!
--
You received this message because you are subscribed to the Google Groups "vertigo" group.
To unsubscribe from this group and stop receiving emails from it, send an email to vertx-vertig...@googlegroups.com.
To post to this group, send email to vertx-...@googlegroups.com.
Visit this group at http://groups.google.com/group/vertx-vertigo.
To view this discussion on the web visit https://groups.google.com/d/msgid/vertx-vertigo/ecad25dd-2ca6-4632-b71f-4a28135a9777%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Oliver Rolle
Oct 28, 2014, 6:08:12 PM10/28/14
to vertx-...@googlegroups.com
Perfect! I am very happy you like it. I was not sure if I could transmit my message in an understandable way (I came drunken from a birthday party of my buddy but wasnt tired ;) All in all we have very cool stuff in our pipeline. I think the best stuff is yet to come!
I have read the thread and I am happy that you will make a roadmap / project plan. I will definitely contribute!
About this business process execution project (code name BPE; the name changes if I find a better (viral) one ;-).
I think BPE should be a separated project on top of vertigo as it uses higher level concepts (SBPM) and keep vertigo focused on the network level.
I plan to add the following features in BPE & vertigo:
* BPE: Integrate Yoke for nice and easy to use web stuff
* BPE: Actor (User or Machine), Subject and Role rights management. (requirement of SBPM)
* BPE: model business processes and generate code stubs
* first a command line tool (like a compiler)
* second a UI with runtime process integration
* vertigo & BPE: Proxy components / subjects, so on network instantiation a component is represented by a proxy and the proxy is replaced by a component instance on a condition (A Customer sends a purchase order and the concrete Employee instance (which represents a real employee) is later delegated (by the boss / task scheduler) to execute the customer purchase.)
* vertigo: integrate ScopeSelector in vertigo for fail-save & high performance network instantiation. The ScopeSelector uses message attributes like a primary key to instantiate a process or lookup a running one. I think this concept is interesting, maybe we could use a similar key to address specific componet instances. This is very similar to hash selector.
* vertigo & BPE: state persistence of components / subjects. Maybe we need to persist all previous so that business processes can be investigated later (think of a customer purchase process which customers aborted half the time, so you need all previous states to see what has happened and lead to the abortion)
* MAYBE vertigo & BPE: use a single component instance in multiple networks; not sure if we have such a requirement; maybe the proxy components are enough
PS: As a side note to efficient a message acking: I talked last week with the founders of Flink (http://flink.incubator.apache.org/) and ask them how they handle message acking efficiently. Basicly they put multiple messages in a bucket and ack the whole bucket, which reduced the acking overhead dramatically. I was puzzled because this solution is simple and leads to good results in environments with low error rate. Maybe this trick helps you to increase vertigo performance.
I have read the thread and I am happy that you will make a roadmap / project plan. I will definitely contribute!
About this business process execution project (code name BPE; the name changes if I find a better (viral) one ;-).
I think BPE should be a separated project on top of vertigo as it uses higher level concepts (SBPM) and keep vertigo focused on the network level.
I plan to add the following features in BPE & vertigo:
* BPE: Integrate Yoke for nice and easy to use web stuff
* BPE: Actor (User or Machine), Subject and Role rights management. (requirement of SBPM)
* BPE: model business processes and generate code stubs
* first a command line tool (like a compiler)
* second a UI with runtime process integration
* vertigo & BPE: Proxy components / subjects, so on network instantiation a component is represented by a proxy and the proxy is replaced by a component instance on a condition (A Customer sends a purchase order and the concrete Employee instance (which represents a real employee) is later delegated (by the boss / task scheduler) to execute the customer purchase.)
* vertigo: integrate ScopeSelector in vertigo for fail-save & high performance network instantiation. The ScopeSelector uses message attributes like a primary key to instantiate a process or lookup a running one. I think this concept is interesting, maybe we could use a similar key to address specific componet instances. This is very similar to hash selector.
* vertigo & BPE: state persistence of components / subjects. Maybe we need to persist all previous so that business processes can be investigated later (think of a customer purchase process which customers aborted half the time, so you need all previous states to see what has happened and lead to the abortion)
* MAYBE vertigo & BPE: use a single component instance in multiple networks; not sure if we have such a requirement; maybe the proxy components are enough
PS: As a side note to efficient a message acking: I talked last week with the founders of Flink (http://flink.incubator.apache.org/) and ask them how they handle message acking efficiently. Basicly they put multiple messages in a bucket and ack the whole bucket, which reduced the acking overhead dramatically. I was puzzled because this solution is simple and leads to good results in environments with low error rate. Maybe this trick helps you to increase vertigo performance.
Jordan Halterman
Oct 28, 2014, 6:18:52 PM10/28/14
to vertx-...@googlegroups.com
I'm working on the road map. Give me a couple hours and I'll post it.
Inline...
Perfect! I am very happy you like it. I was not sure if I could transmit my message in an understandable way (I came drunken from a birthday party of my buddy but wasnt tired ;) All in all we have very cool stuff in our pipeline. I think the best stuff is yet to come!
I have read the thread and I am happy that you will make a roadmap / project plan. I will definitely contribute!
About this business process execution project (code name BPE; the name changes if I find a better (viral) one ;-).
I think BPE should be a separated project on top of vertigo as it uses higher level concepts (SBPM) and keep vertigo focused on the network level.
I plan to add the following features in BPE & vertigo:
* BPE: Integrate Yoke for nice and easy to use web stuff
* BPE: Actor (User or Machine), Subject and Role rights management. (requirement of SBPM)
* BPE: model business processes and generate code stubs
* first a command line tool (like a compiler)
* second a UI with runtime process integration
* vertigo & BPE: Proxy components / subjects, so on network instantiation a component is represented by a proxy and the proxy is replaced by a component instance on a condition (A Customer sends a purchase order and the concrete Employee instance (which represents a real employee) is later delegated (by the boss / task scheduler) to execute the customer purchase.)
* vertigo: integrate ScopeSelector in vertigo for fail-save & high performance network instantiation. The ScopeSelector uses message attributes like a primary key to instantiate a process or lookup a running one. I think this concept is interesting, maybe we could use a similar key to address specific componet instances. This is very similar to hash selector.
* vertigo & BPE: state persistence of components / subjects. Maybe we need to persist all previous so that business processes can be investigated later (think of a customer purchase process which customers aborted half the time, so you need all previous states to see what has happened and lead to the abortion)
* MAYBE vertigo & BPE: use a single component instance in multiple networks; not sure if we have such a requirement; maybe the proxy components are enough
PS: As a side note to efficient a message acking: I talked last week with the founders of Flink (http://flink.incubator.apache.org/) and ask them how they handle message acking efficiently. Basicly they put multiple messages in a bucket and ack the whole bucket, which reduced the acking overhead dramatically. I was puzzled because this solution is simple and leads to good results in environments with low error rate. Maybe this trick helps you to increase vertigo performance.
This actually sounds similar to what Vertigo does currently. Each output connection maintains a monotonically increasing index of the last message it has sent and input connections maintain an index of the last message they received. If an input connection receives a message out of order (index 101 before index 100), it responds with the index of the last message it received in order, allowing the sender to start resenting from that point. Once an input connection has received n messages (or a timeout occurs, whichever is first) it sends an "ack" message back to the sender indicating the last index it received. The sender then removes messages up to that index from memory since it knows they were sent successfully. This allows receiving connections to only ever have to respond periodically, and all sending/acking can be done asynchronously. In my benchmarks this was about twice as fast as the original Storm-like algorithm - which is why I replaced it - and this algorithm will be built upon in Vertigo 1.0.
More to come...
To view this discussion on the web visit https://groups.google.com/d/msgid/vertx-vertigo/685323cf-7bc3-4111-8985-66eb544a3b01%40googlegroups.com.
Amit Kumar
Oct 28, 2014, 11:35:31 PM10/28/14
to vertx-...@googlegroups.com
Awesome !! Kinda perfect use of vertigo except for state persistence (coming soon I guess). Great work Oliver.
Jordan Halterman
Oct 29, 2014, 1:03:21 AM10/29/14
to vertx-...@googlegroups.com
It is perfect! Vertigo is just lacking some obvious features which will be resolved over the next few weeks. In sure I'll be hitting it hard this weekend.
To view this discussion on the web visit https://groups.google.com/d/msgid/vertx-vertigo/44933030-307f-4c08-8154-63d168406c7d%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages