分离SOA服务

Question

我希望写一些网络服务。

什么定义了一个“服务”单位。我注意到，作为一个项目的一部分，您可以拥有多个.svc服务文件。

您通常如何细分服务？例如，银行应用程序：

你有一个服务（.svc）吗？

• 客户端
  • AddClient（Client newClient）
  • DeleteClient（客户端客户端）
• 帐户
  • SetName（字符串名称）
  • SetType（帐户类型类型）
• 转移
  • SendMoney（客户端客户端等）
  • ReceiveMoney（客户端客户端等）
• HomeLoan
  • AddNewHomeLoan（）;
  • RemoveHomeLoan

是否有分组实体的方法？例如，您可以将账户服务中的发送和接收付款，而不是转账服务，因为您收到并发送了账户。

这也带来了关于方法和参数的另一个问题。如果我想添加一个编辑客户端，通常会添加一个类似EditClient（客户端客户端，客户端newClient）的方法，并用另一个客户端对象替换整个客户端吗？或者您是否会添加单独的方法来编辑客户端，例如：客户服务下的EditName（客户端客户端，字符串名称）？

我想正确布置操作合同在我的网络服务中的位置。

Answer 1

在设计Web服务时，我喜欢遵循一些粗略的规则，特别是对于暴露（服务可能由某些已定义组之外的应用/用户使用）服务。

1. 最大工作单位：Web服务（实际上是任何RPC服务）是在单独（通常）机器上运行的另一个软件，你需要花费一大笔费用来调用它（不像本地函数调用），即使它在同一台机器。记住这一点并构建可能接受尽可能多的数据的功能。不要依赖服务器之间的往返来沟通和完成业务运营单位。例如，没有进程“创建帐户”，需要调用“添加用户”，“创建帐户”，“将用户与帐户关联”，“更新用户详细信息”，“激活帐户”以完成该过程。相反，它有一个“createUserWithAccount”函数可以在一次旅行中完成它。
2. 最短的等待时间：记住这些服务是内联调用的，并且如果你的进程需要很长时间来杀死进程，可能是由不耐烦的用户，中间的服务或看门狗进程假设出现错误。您可能会考虑更喜欢返回“门票”的服务，然后调用者可以检查这些“门票”。在大多数情况下，这不是绝对必要的，但对于可能需要一分多钟才能运行的流程，您可能需要这种方法
3. 定义良好的接口：确保您的服务定义良好，最好是类型不可知的定义。此处定义的类型不可知确保您使用易于通信的常见类型，并且很少有机会对客户端实现者产生意外的副作用。很多人更喜欢使用XML作为消息传输的基础，并隐藏其中的所有细节。
4. 计划变更：服务已经存在很长时间（按设计）并同时暴露给外部实施者。这意味着他们 需要更改，但客户要求可能会阻止您轻松完成。构建接口时要考虑版本控制，或使用传输编码（如XML），它允许您修改传输的数据而无需修改调用接口。看看API（如Windows API）如何处理这个问题，以获得有关它如何成为问题的一些想法。
5. 安全性作为一流的设计目标：任何人都可以调用服务接口。您必须期望他们将被所有类型的用户调用，这些用户可能已经过身份验证，也可能未经过身份验证，并且本质上可能是也可能不是恶意的。计划安全性发生在适当的地方，并且不仅仅依靠一种机制来验证一切都是安全的。有几种方法可以实现安全性，如果您的服务在内部使用，您可以放松一些东西，但对于公共服务，您需要考虑您希望安全性如何工作，并确保它在所有服务中保持一致。

希望有所帮助。

• 这些是从福勒和其他人那里采取的一般策略。我应该如何处理它。

Answer 2

我建议阅读Pattern of Enterprise Architecture by Martin Fowler。这应该为面向服务的软件提供许多组织策略。

Answer 3

我更喜欢按功能而不是结构来分离我的服务。 Eric Evans在Domain Driven Design中深入讨论了这种技术。其背后的驱动因素之一是变化率。功能区域往往以类似的速度变化。

结构（坏）：

• 客户端
• 帐户
• 贷款

功能性（好）：

• 结算
• 供应
• LoanApproval

Answer 4

除了GrayWizardx的优秀答案之外，我还要补充一点。

尝试将所有服务定义保持在功能/业务级别。服务名称应具有良好的高级“ChangeDeliveryAddress”，“QueryOrderStatus”类型名称，并且接口定义本身应仅包含业务实体和最少数量的“技术”字段。即接口与实现的完全分离。

如果你发现自己有像“NextOrderLineWithinPage”这样的服务，那么你的设计就会出现问题。