43

最近，我的公司对面向服务的架构(SOA)产生了浓厚的兴趣。每当我试图看看我们如何使用它时，我总是遇到一个心理障碍。粗略地说：

  • 面向对象说：“将数据和操纵数据（业务流程）的方法保持在一起”；

  • 面向服务说：“将业务流程保留在服务中，并将数据传递给它”。

以前开发 SOA 的尝试最终将面向对象的代码转换为数据结构和操作它们的单独过程（服务），这似乎是倒退了一步。

我的问题是：什么模式、架构、策略等允许 SOA 和 OO 一起工作？

编辑： “面向内部的 OO，面向系统边界的 SOA”的答案非常有用，但这并不是我想要的。

假设您有一个Account对象，它有一个名为的业务操作Merge，它将它与另一个帐户结合起来。典型的 OO 方法如下所示：

Account mainAccount = database.loadAccount(mainId);
Account lesserAccount = database.loadAccount(lesserId);

mainAccount.mergeWith(lesserAccount);

mainAccount.save();
lesserAccount.delete();

而我见过的 SOA 等价物看起来像这样：

Account mainAccount = accountService.loadAccount(mainId);
Account lesserAccount = accountService.loadAccount(lesserId);

accountService.merge(mainAccount, lesserAccount);
// save and delete handled by the service

在 OO 案例中，业务逻辑（以及由于 ActiveRecord 模式的实体意识）被嵌入到Account类中。在 SOA 案例中，Account对象实际上只是一个结构，因为所有业务规则都隐藏在服务中。

我可以同时拥有丰富的功能类和可重用的服务吗？

4

6 回答 6

10

我的观点是 SOA 在宏观层面上是有用的，但每个服务可能仍然大到需要几个内部组件。内部组件可能会受益于 OO 架构。

SOA API 应该比内部 API 更仔细地定义，因为它是一个外部 API。在这一层传递的数据类型应该尽可能简单，没有内部逻辑。如果有一些属于数据类型的逻辑（例如验证），最好应该有一个服务负责在数据类型上运行逻辑。

于 2009-01-14T13:08:04.427 回答
10

SOA 是用于在系统或应用程序之间进行通信的良好架构。

每个应用程序都定义了一个“服务”接口，该接口由它将处理的请求和预期的响应组成。

这里的关键点是定义良好的服务，具有良好定义的界面。就 SOA 而言，您的服务如何实际实现是无关紧要的。

因此，您可以使用所有最新最好的 OO 技术或任何其他适合您的方法自由地实施您的服务。（我见过一些极端情况，即“服务”是由实际的人在屏幕上输入数据来实现的——但一切仍然是 SOA 教科书！）。

于 2009-01-14T13:14:23.600 回答
9

我真的认为 SOA 只对外部接口有用（一般来说，对您公司外部的接口），即使那样，只有在性能并不重要的情况下，您才不需要有序传递消息。

鉴于此，我认为它们可以共存。使用 OO 理念保持您的应用程序工作和通信，并且仅当需要外部接口（对第三方）时，才通过 SOA 公开它们（这不是必需的，但它是一种方式）。

我真的觉得 SOA 被过度使用了，或者至少 SOA 架构被提出得太频繁了。我真的不知道有任何内部使用 SOA 的大型系统，我怀疑他们可以。它看起来更像是你可能只是用来做混搭或简单的天气预报类型请求的东西，而不是在上面构建严肃的系统。

于 2009-01-14T12:55:07.617 回答
4

我认为这是对面向对象的误解。即使在 Java 中，方法通常也不是对象的一部分，而是它们的类的一部分（甚至这种“成员资格”对于面向对象来说也不是必需的，但这是一个不同的主题）。一个类只是一个类型的描述，所以这实际上是程序的一部分，而不是数据。

SOA 和 OO 并不矛盾。服务可以接受数据，在内部将它们组织成对象，对它们进行处理，最后以所需的任何格式返回它们。

于 2009-01-14T13:32:44.407 回答
4

我听说 James Gosling 说可以在 COBOL 中实现 SOA。

如果您阅读 Alan Kay 自己对 OOP 起源的描述，它描述了一堆小型计算机进行交互以执行一些有用的事情。

考虑这个描述：

你的 X 应该由 Ys 组成。每个 Y 应该负责一个单一的概念，并且应该根据其接口完全可描述。一个 Y 可以通过消息交换（根据他们指定的接口）要求另一个 Y 做某事。

在某些情况下，一个 X 可能由一个 Z 实现，它根据其接口进行管理。不允许 X 直接访问另一个 X 的 Z。

我认为以下替换是可能的：

Term      Programing       Architecture
----    ---------------    ------------
  X         Program           System
  Y         Objects          Services
  Z      Data structure      Database
----    ---------------    ------------
result        OOP              SOA

如果您主要从封装、信息隐藏、松散耦合和黑盒接口方面考虑，则有相当多的相似之处。如果您陷入多态性、继承等问题，那么您正在考虑编程/实现而不是架构，恕我直言。

于 2009-01-14T13:35:26.913 回答
3

如果您允许您的服务记住状态，那么它们可以被认为是调用时间可能很慢的大对象。

如果不允许它们保留状态，那么它们就像您所说的那样-数据运算符。

听起来您可能将系统划分为太多服务。你有书面的、共同商定的划分标准吗？

采用 SOA 并不意味着丢弃所有对象，而是将系统划分为可重用的大块。

于 2009-01-14T14:01:10.557 回答