Workflow Second Edition Design Summary
First, EXISTING ProBLEMS
There is no further summary of the workflow domain model, which is basically in the first edition level, resulting in:
Attachment, there is no clear increase in new features difficult transaction scripts, bring repetitive code
Component responsibilities are relatively confusing, especially if the service components are coupled to other modules, and should be clearer to define that one core service layer does not do concurrent design, resulting in:
Low performance deadlock
Second, DESIGN Principles
Inverted for interface programming and control
The entire system is programmed for interface, reducing compilation dependencies; using IOC, to assemble the system, custom runtime behavior; bring the biggest advantage, we get a switch between distributed and embedded Engine, no need to modify the source code, greatly improve the convenience and speed of continuous integration, improve applicability
Third, Architecture Patterns
1, layering (POSA1)
Universal Category Library: All other layers are called
Nuclear service layer: for kernel call
Kernel: Independent operation or as a common class library is called
Nuclear development package: use when developing peripheral services
Peripheral service: run with the kernel, supply development package call
Application development package: use when developing specific applications
Specific application: call application development packages and system interaction
Among them, the model model in the kernel is divided into three layers.
Syntax: responsible for transforming the text form of the process to memory objects
Semantic Layer: Responsible for interpretation of extension attributes with these memory objects as meaningful model properties
Example layer: Indicates the semantic layer object of the running period, where each attribute uses the actual value of the running period.
2, microenvironment (POSA1)
The kernel service layer kernel has completed the most basic workflow engine, such as instantiation processes and schedules, producing task sheets, processing message requests, etc., peripheral services provide a product-based workflow engine. Features, such as persistence, timeout processing, task notification, query interface, command interface, etc. Configured in the system in the form of plug-ins.
Four, Design Patterns
1. Area Model (PEAA) Visitor (GOF) Transaction Script (PEAA) Command Processor (POSA1, GOF)
PROBLEM:
P1: Currently understanding of the workflow field model is not thorough enough, and the development process needs to continue to increase the functionality that the current model cannot be directly supported, such as withdrawal, rollback, etc. P2: If you adhere to the field model, add a function of the basics. Increase the corresponding method for the domain object, while increasing multiple functions, the difficulty of increasing parallel development and version control is added, and the development efficiency is reduced.
Constraint:
C1: Dynamic increase function in the case of non-modifying the domain model C2: Need to dynamically provide new function call interfaces for the client without modifying the domain model
Solution:
S1: Using the "Field Model (PEAA) models to model the currently understood workflow, support basic functions S2: Use" Visitor (GOF "as domain model dynamic adding functions, these features are usually not very clear, need iteration Development, gradually merge into the domain model S3: Using message objects to add calling interfaces for client dynamics, using the "command processor (POSA1, GOF)" to increase the corresponding processing interface S4: command processor execution The body is "Transaction Script (PEAA)", which calls the method of the domain object, or "VISIT" domain object to complete the function; there is a repetition code, need further weaken or reduce transaction scripts, plump field model; another The program is "Yuan Workflow", that is, the transaction script in the workflow system is also implemented in workflow, and difficult is to abstract the meta level 2 of a workflow. 2, active object (POSA2) asynchronous completion flag (POSA2)
Used for automatic activities; automatic activities are independent, active operation in their own thread, get parameters from the asynchronous completion flag from the engine, and fill in the results into the asynchronous completion flag after execution, and send the completion message to the engine. To make the process of "blocked" continue to operate ("blocked" here is not really blocked, but when the automatic activity must be synchronized to the process, the process has an unensual state); here More like "Collection Parameters (TDD)" mode, not asynchronous completion flags
3, reactor (POSA2) listener
Used to send the kernel event to the peripheral service, in fact, a manual AOP implementation, the next version can be refactored to PointCuts, the next version can be reconstructed as Advisors
4, plugin (PEAA)
Used to configure peripheral services to the system
5, query object (PEAA)
It is the "General Query Interface" of the previous version, this version is refactored with "Generic Functional Programming"; all query conditions in the current system are set and acquired by query objects, and the problem is less efficient.
6, wrapper appearance (POSA2)
Used to access external resources such as XML, Message system, when transplanting the system from the .NET platform to the J2EE platform, this mode has played a huge role, which greatly reduced the transfer time.
See Also:
"Workflow: The first release, design summary"
