理解SOA架构

Question

我正在开发一个基于SOAP的SOA项目。好吧，我在互联网上读了很多教程，但我仍然有同样的问题，所有的文章和博客，甚至eclipse的官方文档都告诉你如何使用IDE助手或这样的API和框架(例如: JAX- WS，CXF)来创建web服务，并给你一些SOAP，WSDL和UDDI的定义作为奖励，但它们都没有解释SOA是如何工作的，发布和部署WS的过程是如何完成的，以及调用远程web服务的C/S请求/响应过程是如何使用所有这些实体SOAP完成的。WSDL & UDDI和SOA项目中存在的其他文件(XML文件和java文件)。我读了很多电子书，但仍然不明白SOA是如何工作的。伙计们，我需要你们的帮助，我真的很困扰和困惑。在此之前，非常感谢您。

Answer 1

虽然SOA与模块化有许多共同之处，但它也增加了这样的要求:您的独立代码模块不仅要相互互操作和集成(即很好地协同工作)，而且可能与世界上其他所有人的代码一起使用，而且还要求它们可以通过某种定义良好的机制使用。

SOA“纯粹主义者”可能会告诉您，要使您的软件“符合SOA”(注意:这不是一个真实的东西，因为没有关于服务的单一规则集或管理机构)，您需要将其编写为WSDL服务，发布和维护可作为您与任何实现方之间的契约的SOAP，并遵循相关的WS-* specs。然而，在现实中，REST和其他轻量级模块化/集成/可重用性方法同样符合面向服务的体系结构的概念。

如果您确实想成为SOA方面的“专家”，那么请通读以下规范的每一个字：

发现

• UDDI
• RDDL
• XRI
  • XRDS

​

消息传递

• SOAP 1.1
• SOAP 1.2
  • SOAP over JMS
  • MTOM (消息传递优化机制)

​

• WS-Addressing

元数据

• WSBPEL
• WSDL 1.1
• WSDL 2.0
• WADL
• WSFL
• WS-Policy
• WS-PolicyAssertions
• WS-PolicyAttachment
• WS-MetadataExchange (WS-MEX)

安全

• WS-SecurityPolicy
  • WS-Security

​

• WS-Trust
  • WS-SecureConversation

​

服务质量

• WS-ReliableMessaging (WS-RM)
  • WS-Coordination
  • WS-AtomicTransactions
  • WS-TX

​

(这些只是一些最重要的WS-*规范，see full list here)

然后阅读以下SOA必备书籍的每一页：

• Service-Oriented Architecture - Concepts, Technology and Design
• Enterprise Integration Patterns
• RESTful Web Services

然而，我并不建议这样做，因为有太多的阅读材料。不过，我建议您在按照SOA方法编写自己的程序时将它们用作参考，并注意到在特定领域，关于下一步要做什么的参考手册将派上用场。熟能生巧，与阅读书籍和学习有关标准和理论的一切相比，您将从使用真实世界的示例中学到更多。

通常，当您编写代码时，经常问自己您的代码是否：

在其他应用程序或domains

• Makes中可重用的HTTP)

• Provides

• 可在内部扩展并可从外部访问其核心功能(特别是通过网络连接，即，以易于解析/处理(并因此集成)格式的integration

• As输出数据或元数据，如HTTP)

• Provides、

• 或许多相关数据语言和XML中的一种)，以按需提供元数据以描述其内部工作，使得尽可能地使其JSON专业化和模块化自动化成为可能；同时，如果已经存在其他类似的专门化API或Web服务，使用它们会比重新发明轮子

更好吗

人们可能会使用很多其他的问题和标准，但我认为这些是最重要的。

Answer 2

将SOA视为一组这样或那样的技术是错误的。我也不同意SOA只是一个营销术语，尽管它确实得到了坏名声，并被营销和炒作搞糊涂了。

面向服务的架构是一种架构风格。就像在架构蓝图中一样，possets约束了服务应该如何以及应该是什么，以及定义了一组组件和定义了它们的交互。下图显示了面向服务的体系结构与REST，您可以看到它们都是从一些常见的样式派生出来的(例如，它们都构建在客户端/服务器上)，但也来自不同的样式，其中面向服务的架构构建在pipe and filters 之上，而REST则不是(您可以构建RESTful SOA，但您必须更加努力：)

​

SOA将很多重点放在接口上。例如，与OO不同的是，你有4个不同的组件来定义一个接口。消息，捆绑消息的合同，交付合同的端点，以及控制合同交付方式/时间的策略。

​

​

使用定义良好的边界和良好的粒度构建服务(这是棘手的部分)使您能够以灵活的方式组合服务，从而更快地实现业务功能。请原谅我自找麻烦，但您可以在我的关于SOAand模式的书的chapter 1和chapter 10中阅读更多关于什么是SOA REST与SOA的信息