Process Design Considerations
In process-driven design, the business processes or integration flows are first realized and captured. Service contracts might be applicable in a process-centric application, especially for batch or EAI-type automation scenarios. This topic describes some important factors to be considered when using a process-driven approach.
Choosing Between Stateful and Stateless Processes
Stateful processes maintain the state across multiple operations. They are better suited when you need the server to maintain the state across operations. For processes that involve related message exchanges between the same or different consumers, conversations can be used to maintain state across operations.
Stateless processes do not maintain state. They are better suited when you need to process higher loads of requests as each operation is executed independently. They do not require correlation or conversations between multiple operations in a process, thus allowing the server to process each operation without maintaining any state information. The client can choose to maintain the state information, if needed.
Process | Maintains State | Data Sharing | Conversations |
---|---|---|---|
Stateful Processes | Across multiple operations and interfaces. | Data can shared by activities across operations that executing as part of the same job. | Uses conversations to enable correlation. |
Stateless Processes | Does not maintain state. | Data is not shared. | No conversations. |
Choosing Between Properties and Variables
Properties are used to save configuration data at different levels. They can be classified into application properties, module properties, and process properties. For more information, see Choosing Between Process Properties, Module Properties, Shared Module Properties, and Application Properties.
Variables are used to save the state at different levels. They can be classified into process variables, scope variables, and shared variables. For more information, see Choosing Between Process Variables, Scope Variables, and Shared Variables.
Choosing Between Process Properties, Module Properties, Shared Module Properties, and Application Properties
Properties can be classified into application properties, module properties, shared module properties, and process properties. Properties follow the layered configuration model where configuration is pushed from top to the bottom as seen in the illustration:
![](GUID-85EBED01-5992-4FF9-A883-6CD6D540F550-display.jpg)
Properties defined in the inner layer can reference a property defined at the parent layer. For example, a process property can reference a module property instead of providing a literal value. Public properties are visible to the encapsulating layers.
Choosing the right level ensures an easier to maintain list of properties in your application and keeps the number of properties at the application level to a minimum.Choosing Between Process Variables, Scope Variables, and Shared Variables
A process variable saves the state at the process level and a scope variable saves the state within the scope.
Variables defined within a scope are visible only within the scope. If the scope variable name is the same as a process variable name, then the scope variable takes precedence over the process variable within the scope.
- Module shared variable - saves the state at a module level.
- Job shared variable - saves the state for the duration of a job.