我最近与我们的一位建筑师进行了对话，他总结了他对SOA的使用“我们唯一需要使用服务的时候是我们需要异步操作，否则我们将直接使用直接进入数据存储”
我考虑过这个陈述，看起来相当合理，因为服务在发布订阅模型中运行良好，但我想知道你应该在其他场景中使用SOA吗？
答案 0 :(得分：24)
我们向客户公开服务，因为他们不应该直接连接到数据源。
我们向自己公开服务，因为使用WCF将它们分散到不同的技术上更容易。
我们公开服务，因为我们为同一数据源提供了不同的用户界面。当我们使用服务时，我们节省了三分之一的工作。
这绝不仅仅是因为异步行为。
答案 1 :(得分：9)
使用服务的另一种情况是您希望集成异构技术堆栈。
换句话说，如果你的数据库是postgres，但你有Java，Perl，Python和C ++代码，你可以编写存储过程并让每种编程语言都调用它们。如果您正在使用没有存储过程的数据库，或者您希望能够将其切换出来 - 或者您只想在端口80上运行，则可以将SQL调用包装在面向服务的层中（想想现在可以被任何人调用的websphere - 而且你可以在SOA层中放置身份验证和授权逻辑（连接到LDAP，等等）。
您也可以使用该SOA层，比如建立一个逻辑例程，在管理发票或为客户创建语句的角落中使用旧的COBOL框进行“填充”。
因此，如果您想要互连多个遗留系统 - 比如将销售系统与仓储系统连接到订单预测系统 - SOA可能是实现该目标的一种方式。 （您还可以使用“服务总线”创建事件驱动系统，作为协调变更的更好方式。）
请跟我说说。
答案 2 :(得分：6)
在许多情况下，您可以从使用服务中受益。其中一些场景已被行业大师编写（例如SOA成名的Thomas Erl）。
我想说你想找：
你的同事保持谨慎是正确的。采用Web服务时引入了许多部署和支持变量。
答案 3 :(得分：3)
另一种情况可能是集成场景，您可能希望许多单独的组件或系统相互通信。
答案 4 :(得分：2)
SOA可用作隐藏子系统实现细节的方法。例如，如果您的客户需要产品信息，那么将产品数据库或库存子系统包装到通用服务中并且仅公开客户所需的功能和数据子集可能是个好主意。然后，如果您需要更换或升级该子系统，您将能够使这些更改对您的用户和面向客户的软件界面透明。
答案 5 :(得分：2)
电信（恕我直言）似乎正在抓住作为生命线的SOA的观点是，支持SOA的系统允许您采用传统和根深蒂固的技术，并将其作为一致的受控API提供给业务用户开发新的和以前没有思想的想法，而无需重新设计公司的所有内容。
通过使用统一语言（WSDL）作为您的界面，您可以准备技术孤岛以进行互操作。通过现在实施SOA，您可以自动使您的数据源被您从未考虑过的各方和业务需求所消耗，而不是直接使用数据源。
WSDL最终是Corba的作品。
答案 6 :(得分：2)
WSDL和SOAP通常会遇到与CORBA和DCOM相同的问题：合同版本控制是一场噩梦。在您完全控制所有客户端和服务器的这种情况下，这并不是一个问题，但是当您开始联合系统时它会变得很难看，当您进入企业间时更是如此。
此时，您几乎被迫使用某种事件驱动的体系结构方法，而不是典型的SOAP-as-RPC交互模型。这并不意味着使用ESB，而是将企业之间的连接视为ESB之间的连接非常有用。
即便如此，依赖SOAP作为传输也会变得难看。您不仅需要使用相反的Web服务来适应双向交互，您仍然会遇到版本控制问题。通常，SOAP方法会根据其他方式定义的“blob”（例如，单独的XML模式）而变为普通的包装器。
有答案，但它们从不简单。 Best practices for Web services versioning讨论了其中几个。
但SOA并不意味着任何异步。这只是实现SOA的智能方式。 SOA是松耦合的。 SOA的EDA子集是关于去耦的，这是更进一步的。
答案 7 :(得分：2)
还存在另一个相关思想学派，称为SOAD（面向服务的应用程序设计），系统的每个组件都是一个服务。这是为了利用它们构建的环境（EJB，WCF）提供的好处，即您可以获得大量免费管道。
上的更多资源
答案 8 :(得分：1)
整合访问相同资源的不同技术;在这些不同的技术上实现某种程度的事务隔离;保持一个业务逻辑写在一个地方（所以当改变这个逻辑时不会有nigthtmares）......
答案 9 :(得分：0)
我会在一个系统中使用SOA，该系统将在组织内部扩展，并可能扩展到其他组织。
对于可以改变的产品也很好，你可以更换它的一小部分。
最后，你会有很多乐高积木，你会加在一起。