\t\tCCR DSS 处理复杂的固有的并行设计和创造分布式应用程序

CCR

并发和协调运行时（Concurrency and Coordination Runtime，CCR)提供一个高度并发的、面向消息的编程模型，利用强大的消息组织机制替代了锁定、信号量等线程操作。CCR通过提供管理异步操作、 处理并发、并行硬件管理以及处理部分错误的编程模型来实现面向服务的应用程序，使得设计低耦合的软件模块和组件成为可能。因此，各模块可以独立的开发并且 不需要对它们的运行时环境和其他组件进行过多的假定。这样就不需要在程序设计一开始就考虑处理并发、错误和冲突的机制。它是整个开发平台的核心运行时。

DSS

分布式系统软件(Decentralized System Services，DSS)提供了一个轻量级的面向服务的应用程序模型，融合了传统网络架构的主要特性和一部分网络服务的架构的特性。DSS定义的应用程 序模型包括服务状态以及针对服务状态的一系列操作，并且能过提供结构化数据操作、事件通知和构成服务扩展功能（结构图如图1）。DSS的主要目标是提高简 单性、互操作性和低耦合性。这使得它特别适合于创建由服务构成的应用程序，而不用考虑服务是运行在同一个节点上的还是在网络上的。因此，基于DSS的应用 程序具有很大的灵活性。DSS使用HTTP和DSSP作为服务交互的基础。DSSP(Decentralized Software Services Protocol)是一个轻量级的基于SOAP的协议，对结构化数据操作和事件驱动模型提供了很好的支持。DSSP实现对服务的管理和订阅并且提供一个简 单的状态驱动的应用程序模型。DSS运行时使用维护运行时环境的方式来管理服务，而且它还提供了像创建服务、登录服务、调试、安全相关以及监视等一系列基 础服务。它是基于CCR核心运行时开发的。

CCR Introduction

Concurrency and Coordination Runtime (CCR) is a managed code library, a Dynamically Linked Library (DLL), accessible from any language targeting the .NET Common Language Runtime (CLR).

The CCR addresses the need of service-oriented applications to manage asynchronous operations, deal with concurrency, exploit parallel hardware and deal with partial failure. It enables the user to design applications so that the software modules or components can be loosely coupled; meaning they can be developed independently and make minimal assumptions about their runtime environment and other components. This approach changes how the user can think of programs from the start of the design process and deals with concurrency, failure and isolation in a consistent way.

Problem Areas

• Asynchrony - When communicating between loosely coupled software components, like programs running across the network, or User Interface (UI) code communicating with the user input and the file I/O subsystem, asynchronous operations enable the code to scale better, be more responsive, and deal with failure across multiple operations. Asynchronous programming however, considerably reduces the readability of user code, since logic is often split between callbacks and the code that originates the operation. In addition, it is an almost impossible task to correctly handle failure across multiple outstanding operations.
• Concurrency - Code that needs to better utilize multiple execution resources, must be split into independent logical segments, that can run in parallel, and communicate when necessary to produce results from the combined execution. Often, that logical segment is captured by the thread OS primitive, that is nothing more than a long lived iteration. Because of thread performance implications on thread startup, the thread stays active for long periods of time. This forces a particular pattern.   Code is structured as long sequences that use blocking or synchronous calls, and only deals with one thing at a time. Further, threads assume that the primary communication between them is shared memory, forcing the programmer to use very explicit, error-prone methods to synchronize access to that shared memory.
• Coordination and Failure Handling - Coordinating between components is where most of the complexity in large software programs lies. A mismatch of interaction patterns, such as calling methods on objects versus using OS signaling primitives versus using queues plus signaling, leads to unreadable code, where the runtime behavior changes drastically between coordination approaches. More importantly, the error handling approaches are ill-defined and again vary drastically.

Application Model

CCR is appropriate for an application model that separates components into pieces that can interact only through messages. Components in this model need means to coordinate between messages, deal with complex failure scenarios, and effectively deal with asynchronous programming. This application model is also very similar to how heterogeneous hardware is integrated and how network applications are built. Most software programs have the same needs, from traditional client PC programs to server applications, to applets running in the Web browser. The software needs to coordinate user input, storage input/output and UI presentation. Although disguised in layers of mostly synchronous application code interfaces, asynchrony is inevitable since the devices operate at different speeds, have large differences in resources available, and we in general know how to use queues to isolate them.

The following sections introduce the CCR programming model and its implementation that addresses the above areas in an efficient, robust and extensible way.