我正在开发一个基于 SOAP 的 SOA 项目。好吧,我在网上看了很多教程,但我仍然有同样的问题,所有文章和博客,甚至eclipse的官方文档都告诉你如何使用IDE助手或这样的API和框架(例如:JAX-WS, CXF)创建一个 Web 服务并为您提供一些 SOAP、WSDL 和 UDDI 的定义作为奖励,但它们都没有解释 SOA 是如何工作的、发布和部署 WS 的过程是如何完成的以及 C/S req/resp 是如何完成的调用远程 Web 服务的过程是使用所有这些实体 SOAP、WSDL 和 UDDI 以及 SOA 项目中存在的其他文件(XML 文件和 java 文件)来完成的。我读过很多电子书,但仍然不明白 SOA 是如何工作的。pliiiz 我需要你们的帮助,我真的很不安和困惑。
2 回答
不要太拘泥于面向服务的架构 ( SOA ) 这个术语,因为它实际上更像是一个营销术语,它描述了一种众所周知且实践过的软件开发方法,该方法将程序制作成可以在广泛的范围内重用的专用组件应用程序。它还可以描述将这种软件开发方法应用于业务流程建模,其中业务单元和工作流被模块化并被视为单独的服务,而不是存在于泡沫中的单一流程,有些人称之为面向服务建模概念的不同但相关的应用.
虽然 SOA 与模块化有很多共同点,但它也增加了这样的要求,即您的单独代码模块不仅可以相互操作和集成(即可以很好地协同工作),而且还可能与世界上其他所有人的代码相互协作,并且它们可以通过一些定义明确的机制获得。
SOA“纯粹主义者”可能会告诉您,要使您的软件“符合 SOA”(注意:这不是真实的,因为没有单一的规则集或服务管理机构),您需要将其编写为SOAP Web服务、发布和维护一个 WSDL,它可以充当您与任何实施方之间的合同,并遵循相关的WS-* 规范。然而,实际上REST和其他轻量级模块化/集成/可重用性方法与 SOA 的概念一样多。
如果您确实想成为 SOA 的“专家”,那么请仔细阅读以下规范的每一个字:
发现
消息传递
- 肥皂 1.1
- 肥皂 1.2
- SOAP over JMS
- MTOM (Msg Trans 优化机制)
- WS-寻址
元数据
安全
服务质量
(这些只是一些最重要的 WS-* 规范,请参阅此处的完整列表)
然后阅读以下基本 SOA 书籍的每一页:
但是,我实际上并不建议这样做,因为阅读材料太多了。不过我的建议是,当您按照 SOA 方法编写自己的程序时,将它们用作参考,并注意在特定领域,关于下一步做什么的参考手册会派上用场。熟能生巧,与阅读书籍和学习有关标准和理论的一切知识相比,您将真正从处理现实世界的例子中学到更多。正如您所提到的,从使用 NetBeans 或 Eclipse 等 IDE 开箱即用的过于简单的 JAX-WS 和 JAX-RS Web 服务示例开始,然后尝试使用流行的 SOA 框架(如CXF、Axis2 )附带的一些示例或RESTlet。
一般来说,当您编写代码时,会不断问自己您的代码是否是:
- 可在其他应用程序或域中重用
- 使其核心功能在内部可扩展并可从外部访问(尤其是通过网络连接,即HTTP)
- 以易于解析/处理(并因此集成)的格式提供输出数据或元数据,例如XML、JSON或许多相关数据语言和子语言中的一种
- 能够按需提供元数据来描述其内部工作,从而使其集成自动化成为可能
- 尽可能专业化和模块化;同时,如果已经存在其他类似的专用API或 Web 服务,最好使用它们而不是重新发明轮子
人们可能会使用许多其他问题和标准,但恕我直言,这些是最重要的。
将 SOA 视为一组这样或那样的技术是错误的。我也不同意 SOA 只是一个营销术语,尽管它确实名声不好,并且被营销和炒作弄糊涂了。
面向服务的架构是一种架构风格。就像在一个架构的蓝图中一样,它对服务应该如何以及应该是什么服务设置了约束,并定义了一组组件并定义了它们的交互。下图显示了 SOA 与 REST,您可以看到它们源自一些常见的样式(例如,它们都构建在客户端/服务器上),但也来自不同的样式,其中 SOA 构建在管道和过滤器上,而 REST 没有(您可以构建 RESTful SOA 但你必须更加努力:))
SOA 非常重视接口。因此,与 OO 不同,例如,您有 4 个不同的组件来定义一个接口。消息、捆绑消息的合同、交付合同的端点以及管理合同交付方式/时间的策略。
构建具有明确边界和良好粒度的服务(这是棘手的部分)可以让您以灵活的方式组合服务,从而让您更快地实现业务功能。请原谅我敲自己的鼓,但您可以在我的 SOA 模式一书的第 1 章和第 10 章中阅读更多关于什么是 SOA 和 REST 与 SOA 的内容