基本上在我的研究中，SOA（面向服务的体系结构）是一个广泛的主题，它有许多定义，有些人认为它只用于业务应用程序，有些只是提供IT相关定义，如“是计算机软件中的架构模式”设计，其中应用程序组件通过通信协议向其他组件提供服务，通常通过网络“ .
我目前正处于最后一年的项目中，我基本上想要开发一个基于Web服务的推荐引擎，任何类型的Web应用程序都可以使用推荐引擎 .
所以我的问题是，如何将其视为SOA解决方案，并且因为它是一个没有特定于企业的项目（它是一般软件），我应该将其视为SOA吗？
我的问题的第二部分是，例如，如果它可以被视为一个SOA项目，我计划特别为这类项目使用软件开发方法，它的名字是SOUP（面向服务的统一过程） . 问题是这种方法需要洞察概念，例如SOA策略（我找不到任何有关它的信息，所以我希望有人可以解释），以及SOA治理（基本上我认为这对于a没有企业特定客户的最后一年项目） .
1 回答
我不认为该软件不是特定于企业的事实意味着您不能将其视为SOA . 换句话说，SOA不依赖于业务环境 .
我认为SOA是那些有问题的术语之一，因为除非你真的这样做，否则它基本上没有意义 . 那么做SOA意味着什么呢？
那么，一种方法是考虑第一个和第二个tenets of SOA，边界是显式的，服务是自治的 .
那么在这种情况下我们的意思是什么呢？好吧，我们可以用简单的技术术语来解释这一点，例如服务的内部和外部之间的界限是明确的，因为有一个明确定义的界面 . 但是，我认为这种解释很浅薄 .
当我们谈论边界时，我们应该谈论的是能力边界 . 服务应该包含单个（或相关的多个）功能，并且一个功能与另一个功能之间的边界应该是明确的 . 有能力X和Y以及它们之间的绝对线 .
所以这给了我们关于如何做SOA的第一个线索 . 显然，我们需要了解系统将支持哪些功能，然后为每个功能规划服务 .
这将我们带入了第二个原则 . Autonomy可能是SOA中最重要的考虑因素 . 那么自治究竟意味着什么呢？您如何使您的服务自主？从某种意义上说，它意味着在有自然能力边界的地方，如第一部分所述，自治要求跨越该边界没有能力，或者更简单地说，服务应该彼此分离 .
因此，这为我们提供了如何进行SOA的第二条线索 . 如果我们想要充分尊重自主权，那么我们应该完全孤立于其他功能来构建每个功能 . 因此，这意味着将每个服务构建为单独的应用程序，与任何其他服务共享很少 .
这种方法有许多实际后果 .
其中一个更重要的后果是我们在服务之间进行了cannot share a database . 每项服务都负责自己的数据模型 . 重要的是，这将意味着多个服务或功能共有的某些类型的数据库实体可能在许多不同的服务中被复制，并且允许同一实体的这些不同表示被允许become inconsistent .
另一个结果是服务应该使用HTTP与业务能力之外的其他服务交换数据是有争议的 . 使用基于资源的URL可能意味着对其他服务的功能的依赖性太直接，无法实现真正的自治 . 相反，真正的自治只能通过使用eventing来实现 .
正如您所看到的，只要您可以构建应用程序，牢记SOA的前两个原则，您就不会这样做要求企业了解设计 . 没有它，设计是有意义的，只要您可以建模系统的功能，然后使您的服务自主 .