协定问答： 定义服务间的会话 (.NET Designers)

http://www.microsoft.com/china/MSDN/library/enterprisedevelopment/builddistapp/ContractTalks-DefiningConversationsBetweenServices.mspx

协定问答： 定义服务间的会话 (.NET Designers)

发布日期： 4/1/2004 | 更新日期： 4/1/2004

Steve Kirk

Microsoft Corporation

2002 年 9 月 26 日

摘要：MSDN 的 Steve Kirk 会见了 Microsoft .NET Platform Strategy 组的解决方案体系结构架构师 Maarten Mullender。后者致力于 Microsoft 基于服务的应用程序体系结构概念方面的工作。他们讨论了如何设计用于管理服务间会话的协定。（4 页打印页）

用于基于服务的应用程序的 Microsoft 体系结构概念已在今年 7 月作为应用 程序体系结构： 概念视图发布，并在.NET Architecture Center 中对这些概念进行了介绍，它们在应用程序设计社区中引发了许多讨论，其中包括本栏目集中讨论的分布式 Microsoft_ .NET 应用程序的设计。

Maarten Mullender 是从事此项工作的 Microsoft架构师之一，本月我们一起就有关话题进行了讨论。Maarten 最近的工作重点是基于这些概念 的应用程序的逻辑和物理体系结构。在未来几个月中，MSDN 上将发布此项工作，而 .NET 体系结构中心 也将介绍此项工作。

Steve Kirk：在应用程序体系结构： 概念视图中，您对基于服务的应用程序体系结构提出了建议。在您的建议中，服务之间的会话通过协定来定义。 您打算怎样定义协定？

Maarten Mullender：要回答这个问题，可以只是简单解释一下概念并介绍一下相关工具，但我更愿意从设计过程开始进行说明。试想一下高级别服务之间的协作。我们首先要做的是定义这些服务的功能，即它们的责任。如果不能用几句话对此加以描述，我们就应该重新考虑。

然后需要说明这些服务应该提供的服务（这两个服务的含义不同）或任务。 我们需要从业务功能以及异步通讯这两个角度来考虑，而不是仅从请求－响应关系角度来考虑： 我向您发出询价请求；您发给我报价。如果您没有及时发送请求，我的响应也会相应推迟，如此等等。应该将消息作为单独的事件进行处理。 不要假设对方能够立即响应。在每一方都应使用独立的 ACID 事务持久保持状态，并且使用可靠的通讯方式。

Steve Kirk： 即使是非常简单的会话，协定也可能将其定义得非常复杂。例如，报价可能在限期内返回，也可能由于系统或业务原因不能按时返回。 针对每种情况，协定可能都要指定不同的行为。那么，如何对此进行最佳的定义或建模呢？

Maarten Mullender：迄今为止，大多数活动都可以通过 UML 使用用例工具来建模，或者使用简单的英文进行建模。选择哪一种方式取决于您和您 的组织的倾向，因为这两种方式并不互相排斥。当然，使用 UML 可以添加各种各样的注释。我个人更喜欢从更高级别的方案描述开始，而不是像大多数人那样从创建用例开始。然后，再将这些方案转变成用例。

Steve Kirk： 我们可以根据其粒度来理解 API。例如，对 API 的调用是粗糙粒度（使用较少或较低频率的调用）还是精细粒度（使用较多或较高频率的调用）？您如何看待相互协作的服务之间的 API 粒度？

Maarten Mullender：高级别服务的责任和任务都应该描述其业务功能，并且这种功能描述应该使用组织中的业务人员能够理解的措辞。也就是说，使用业务处理。这样您就可以跟业务人员讨论他们的需求，同时又可以使定义的协定无需变更。

对这些任务应尽量采用粗糙粒度。因此，例如，应当考虑提交定单或更改定单，而不是考虑更改某一定单项的折扣条件，因为更改定单就已经包含了这些 细节。这是不是就意味着精细粒度不好呢？那也不是。信用卡检查和电子邮件地址有效性的检查都使用了很简单的签名功能，但是您可能仍然需要它们。

我们必须考虑适合所设计部分的抽象过程。对于向组织中其他部分提供的接口，甚至是向组织外部提供的接口，必须从业务过程的角度来考虑。而对于 内部接口，则可以从设计的角度来考虑。设计是一个权衡的过程。我们并不是要提供最漂亮的解决方案，而是力图提供有效的解决方案，并且同时照顾到 近期和远期目标。

Steve Kirk： 您如何看待消息本身？

Maarten Mullender： 我从业务文档的角度来考虑消息。我认为，业务文档本身就是定义明确的消息，其中包含了精心定义的内容、意义和限制条件。 在 .NET 中，很容易定义带有字段和属性、并且只包含用于检查一致性的逻辑的类。而定义正确的内容以及定义业务逻辑传递错误和警告的方法，则可能相当有挑战性。

但是，一旦定义了消息流和消息内容，就会自动获得方法签名。使用接口和类很容易定义方法签名和消息内容，但将消息流映射到现有的基础体系结构却并不容易。 请注意，部分设计时协定可以指定是否使用事务消息以及如何识别请求者（尤其当请求者是人时）。

Steve Kirk：您提到了基础体系结构的作用，以及处理错误和警告的潜在复杂性。 在应用程序体系结构：概念视图中，您说过如果基础体系结构在处理流、 传递错误和警告等方面具有更强大的能力，则使用这种基础体系结构可以大大简化协定的设计。针对目前的基础体系结构以及未来的基础体系结构，您对协定的设计有什么建议？

Maarten Mullender：需要清楚的重要一点是，基础体系结构是可以更换的。新的基础体系结构可以提供更强大的功能，您一定会希望能够确保对它加以利用。 基础体系结构的标准正在制订中。请看一下 Web 服务互操作性方面的进展情况 (WS-I)。很多供应商已经开始定义路由、 安全性、事务等方面的标准；他们也会提供相应的实现。

Steve Kirk： 在您的论文中，您讨论了运行时协定。您怎样将它们应用到设计过程中？

Maarten Mullender：我确实考虑过将其作为服务级协议。 您定义要求、高级目标、安全要求以及性能要求和缩放要求，然后将它们标准化。 我还不知道任何标准化的形式，但我相信将来肯定会有的，因为会有软件用于配置生成的策略。坦率地讲，如果我们在定义所有其他标准的同时定义了 管理接口标准，那将是基础体系结构标准化过程中最重要的一步。

Steve Kirk：在应用程序概念中，您描述了服务和进程（控制其他服务的服务），并将其作为模型视图控制器 (MVC) 和 UI 部件扩展到用户 层（或表示层）。您打算怎样定义 MVC 和 UI 部件？

Maarten Mullender： 目前，它是一个巨大的 “因变量”。它取决于您是否要在基于 Web 的入口中编写部件，是否要为使用 Web 页的业务流程 (LOB) 应用编写用户界面，以及是否要编写客户端应用程序。我和许多同事正在努力统一编程模型。

我认为，您应该考虑可以独立放置在屏幕或页面中的部件。这些部件包含一个视图和一个控制器。视图取决于通道，而控制器会自动确定通道。首先，我考虑了树状控制器。根控制器负责进程（用户如何在部件之间转换、需要显示哪些部件等等），叶控制器负责与部件交互。然后，我考虑了由这些树形成一个森林，树之间使用发布/预订进行交互。这样就可以把似乎显示无关信息的部件连接起来，并且可以在部署期间甚至是在部署之后配置布局。我希望由 此能带来一些启发，但是我也知道，用一本书也不能完全容纳有关这一主题的论述以及相关的内容。

.NET 设计人员

Maarten Mullender 是 .NET Platform Strategy 组的解决方案架构师。这个组负责定义企业解决方案的体系结构准则。在过去四年中，Maarten 一直与我们精心挑选的企业合作伙伴和客户一起，探索所提供产品与实际应用的结合，确保合作项目有利于双方，并为产品组提供反馈。Maarten 已有二十多年的 工作经验，做过项目经理、产品经理和架构师 － 最初是在 Nixdorf（该公司后来并入 Siemens-Nixdorf Information Systems），之后加入 Microsoft， 从事与多种产品有关的工作。

Steve Kirk 是 MSDN Architectural Samples 组的应用程序架构师。他负责整理“.NET 体系结构中心”和“利用 .NET 构建分布式应用程序”中的内容。他参与的其他项目还包括 Duwamish Books 和其他 MSDN 应用程序示例。

转到原英文页面