Effecect inside 5-workflow Overview

View the world with architect's eyes-talking about Workflow

Zhang dalei

Many people know that computer programming begins with learning flowcharts. simple diagrams with diamond rectangles often give the process logic a clear view. However, Flowcharts are not software that can be run. They are only a document at best. Therefore, after getting started, you often leave the flowcharts behind and directly analyze and design handwritten code. But can a flowchart be used only as a document? In many aspects, the Code cannot match the flowchart:

1. A programmer writes a program and another person needs to take a long time to understand the logic. It is not as clear as a flowchart.

2. You cannot see the code running status during running, and you do not know the stage of the code running, which brings obstacles to large-scale project management.

3. Code is always encapsulated in an object or process. Additional logic is required between objects (processes) to share the state.

Although it has never been the mainstream of software development, it is always a good idea to use flowcharts at runtime, especially in scenarios such as document lifecycle management, internal application logic flow, BPM, and pageflow, the advantages are particularly obvious: Flowcharts are highly flexible and easy to design, highly visible during operation, and more convenient to manage. In the future, many companies will continue to accept the introduction of workflow engines to their products to improve their efficiency, in accordance with the rules for the software industry to survive, so as to avoid repeated invention of poor wheels, the primary task is to select an appropriate workflow engine. What is the ideal workflow engine? Some people have summarized some supported modes that the workflow should have. For more information, see workflow pattern.

Http://en.wikipedia.org/wiki/Workflow_patterns

Http://www.workflowpatterns.com/

These are very useful summaries, but some manufacturers are involved in commercial interests, so some process model things are hard. Many people, like me in the past, have written their own workflow engines for reference to openwfc, BPEL4WS, or some other functional points to be implemented and named themselves intellectual property, but there is still a gap between real workflows. In short, a relatively complete workflow platform must have the following functions:

1. The process jump can be completed.

2. The host process, host, runtime, workflow engine, and other layers are completely decoupled.

3. The host process is diversified. At least it should be able to stay on the mainstream application servers, so as to prevent users from writing their own application servers if not necessary.

4. The host layer contains runtime services such as persistence, timer, tracking, and transaction support.

5. At the runtime layer, the required schedulers, rule engines, and basic tracing frameworks for workflow execution are decoupled from the State management, activation, and hibernation required for workflow lifecycle management.

6. The workflow engine supports models including common time series and statuses.

An ideal workflow engine also requires the following features:

1. The host layer supports runtime services such as external interaction and multi-thread multi-process support, and supports custom runtime services for extension.

2. the workflow engine supports well-encapsulated time series, status, and other models for easy calling. The engine supports policy/rule-based models and custom activities, this leaves a way for partners who develop industry component packages based on them.

3. the API is well organized and easy to call. It is best to support multiple languages and scripts. There should be no strange Process Definition Language, preferably existing in the industry or accepted quickly.

4. There are many auxiliary tools and code injection points at design and runtime.

5. user-friendly development, debugging, and test template views and designers are available during design and operation.

6. good support for common intermediate formats such as plain text, XML, and office Doc; support for common databases and common industrial exchange standards or interfaces with extended support.

In addition, there are many other functions that are not focused on workflows, but the ideal workflow engine must also be considered because of the needs of technical decision makers:

1. Clear borders, service autonomy, shared schema and policy, rather than class, policy-based service compatibility. Obviously, we may have to figure it out. Isn't this the design principle of distributed application services such as WCF? How can we get it down to the workflow? The reason is very simple, because the workflow that is easy to publish into a service is the most plasticity workflow, so the workflow has to bow down under the eaves, Which is why Microsoft silver (in. net3.5 releases WF as WCF.

2. supports Process Collaboration in four ways: Man-person, man-system, system-person, and system-system. supports dynamic and transparent management throughout the lifecycle, the model is highly scalable.

3. The operation status and data can be easily transferred between different workflow processes/threads, and other operations such as compensation and billing can be conveniently performed.

 

Based on the above considerations, we can see that Microsoft's Windows Workflow Foundation is fully available, of course, not the most ideal. One thing to note is that the author estimates that Microsoft's workflow engine will encounter a strange development trend in the future. Although WF is more mature than most domestic companies, however, the abstract level is not high. Although enterprise libraries are currently working on pageflow, the previous sliver and other repairs and supplements are still difficult to take over the entire world. The bigger reason is that you may encounter the BizTalk Server or BizTalk Service website (clarify again that neither of them is a workflow engine ). It can only be expected to show in Oslo.

In general, process-based development will have a profound impact on software development in recent years. You can now select your desired workflow based on the above criteria and apply it to your daily work.

Important statement: the above is purely a personal opinion and does not represent any opinions of the company. Please indicate the source for reprinting.
I would like to extend my gratitude to Paul Andrew and James conard for their reference!