In the past two days, I wrote the fifth chapter "workflow mode" of "Starlight of Workflow", and re-read the workflow pattern of Aalst master in detail.
I have a marble-carved pressure book stone, which is carved with a "warm and new", as if it was given by my father in elementary school. Of course, it is left in my hometown now, I don't know whether it is, but it is always in my mind when it comes to that sentence-the ancient philosophy is always right (haha, this is a bit of nonsense ). Re-reading workflow pattern has different benefits.
Something like WP cannot be understood without reading it several times. Of course, if you do not actually practice it several times, it would be useless to read it multiple times. At this time, I had to admire the intelligence of the First People-Theory and Practice. practice is the only criterion for testing the real world ······
Workflow pattern is a very abstract layer. It cannot be analogous to the design pattern in J2EE. I used this analogy in the early days, but now I don't think so. DP has actually standardized your Implementation ideas and basic implementation relationships. WP does not have many actual paradigm constraints on Workflow. It is just an abstract description of the running mode of workflow. That is to say, you can use any means to implement the scenario described in each mode. For example, if deferred choice compromises the workflow mode, you can use the PN mechanism or hard code.
In addition, the modes described in WP allow "Combination". The combination of these modes can express more complex process running scenarios. If we use metamodel, a popular one, we can say that what workflow pattern does is to find the minimum element of the metamodel in the process running scenario.