WinFX Workflow学习笔记-Core Workflow Tenets

参照Service Oriented的四宗旨：
Boundaries are explicit
Services are autonomous
Share schema and contract and not class
Service compatibility is based on policy
仅仅这四个宗旨，对于将分布式的服务进行重构整合的SOA来说是不够的。少了什么呢？ 所缺少的关键点在于：如何和将这些服务整合的指导，系统地特征，和将人作为应用整合的一个因素考虑在内。考虑到这些就是下面的四个新的，更加全面的宗旨：
1.Workflows are long-running and stateful: Fundamentally, systems are created by the composition of multiple services and, following good design practices, components that perform specific roles should be created as autonomous services. The behavior between these services can be as simple as passing and mapping behaviors or more complex such as sharing transactional semantics and temporal constraints. The temporal aspects of service composition enforce asynchronous requirements on the system. A service that submits a purchase order to other services as part of a composite application waits for two hours for an acknowledgement. This asynchronous controller, or model, should be independently factored as a specialized service component. Hand in hand with the requirement to model asynchrony is the need to include state as part of the model. The service that sent out a purchase order and received an invoice requires information on the purchase order to later update another service. State may be relevant to a single call, relevant across multiple calls, or relevant across an entire asynchronous workflow.
2.Workflows are transparent and dynamic through their lifecycle: Services and the applications to which they compose should not be, as they are today, like concrete bunkers with no windows. Although policy provides rigor in the definition of how to talk to the service, what the service does—its behavior—is opaque beyond its method call syntax. System behavior should be transparent, enabling the developer to rapidly ascertain the behavior at design-time and make a change in that behavior. Even more importantly, system behavior should be transparent at the runtime level. If the behavior of each service in a composite application were transparent the advantages would be significant. No longer is the service a concrete bunker; rather, it is more analogous to a greenhouse. Troubleshooting, tracking, and understanding the overall composite application behavior becomes dramatically simpler because of the additional visibility into the thread of execution. Entirely new scenarios can be envisioned where the behavior of the system thus far executed can be queried at runtime and used to influence of the future behavior. With access to the system behavior metadata, the thread of execution can analyze the currently completed behavior and make changes to its behavior on the fly on the basis of new program conditions. Having asserted that system behavior should be transparent by default, there are times when the developer will want to decrease the level of transparency. For example, some service behavior may need to be obstructed for intellectual property reasons, or specific service behavior is visible within a bounded set of services but not beyond that. The dial that sets the service transparency should be set through policy and access control rather than the traditional development approach where a transparent system is not a default and developers add small windows to prebuilt concrete bunkers.
3.Workflows coordinate work performed by people and by software: The original tenets for services make no reference to people and yet people are a vital part of any composite application. Today services typically send messages to people through email and pagers, or receive inputs from people through user interfaces that pass their parameters to and from services. Sometimes a single person provides the information required for the composite application to continue but more often than not an entirely out-of-band interaction occurs between multiple people in a manner that has been historically challenging to model in software before a result is returned to the composite application to continue. People are important; optimizing their behavior as part of the overall system behavior may provide as high a return as optimizing the system behavior itself with some systems having 80% of their cost in exceptions managed by people. The downside of including people from a software engineering perspective is that modeling their behavior is significantly less straightforward than modeling service behavior. People tend to work in a more ad hoc manner—it is typically more challenging to be imperative with people, and the flow of information between people may not be easily drawn in a flow-based sense because they make choices that may change the workflow at runtime, but is more ad hoc and is better represented as a set of interacting exception conditions.
4.Workflows are based on extensible models: Every workflow comprises some number of steps, each of which performs a particular part of a complete business process. The set of actions that are used to construct a workflow can be thought of as comprising a model for that particular problem domain. Different problem domains have different actions, and so a single model isn't appropriate for all workflows. Instead, different groups of actions—different models—can be created for specific domains. Those actions can then be used to construct workflows supporting various business processes in that domain.