SOA 最常见的技术是什么?

发布于 2024-09-19 07:56:14 字数 117 浏览 0 评论 0原文

我正在研究 SOA 概念并找到了技术(我应该这样称呼它吗?) SOAP 和 REST(仅限这些技术)。我想知道是否还有其他技术(?)在这种情况下共存以及它们代表什么。他们在某些方面做得更好吗?很多人使用它们吗?等谢谢(:

I'm studiyng the SOA concept and found out the techniques (should i call it like that?) SOAP and REST (only these ones). I want to know if there are any other techniques (?) that coexist in this context and what do they represent. are they better in something? does many people use them? etc. thanks (:

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

潜移默化 2024-09-26 07:56:15

将 SOA 架构与 SOAP、REST 和架构的其他实现分开非常重要。

您可以在任何支持通过消息进行请求和响应的技术之上实现 SOA 架构。

SOA 架构的核心特征是: -

  • 客户端发送简单的请求消息。
  • 服务器用单个回复消息进行响应。
  • 服务接口被明确定义并“通告”给客户端。即客户端可以向服务器查询支持哪些服务以及这些服务的接口是什么。
  • 没有数据复制,也没有本地存储。如果客户端想要了解某个 Widget,则它会查询 Widget 服务,客户端不会保留任何 Widget 数据。同样,如果客户端想要更新 Widget 的详细信息,它会向 Widget 服务发送更新请求。
  • 同步、异步和批处理接口都是可以接受的。

这种架构的主要优点是: -

  • 服务器与其客户端之间的唯一联系是“接口”。客户端完全不需要了解服务器的实现,同样服务器也不关心客户端是如何实现的。
  • 数据由服务且仅由服务拥有和管理。这消除了同步、复制问题,并将双重更新的可能性几乎降低到零。
  • 由此产生的架构绝对简单,具有极大的灵活性。
  • 最终架构的绝对简单性使得系统非常可靠。

然而,正如您在现实世界中得出的非常正确的结论一样,大多数情况下都使用 SOAP 和 REST。当人们说 SOAP 时,他们通常指的是 WS-* 系列标准和协议 --> WSDL(Web 服务定义语言)、WSM(Web 服务消息传递)、WS-Security 等,它们使用 SOAP 作为传输协议机制。

尽管 REST 具有简单的优点,但 WS* 非常复杂且更难实现,但我建议对于任何相当大的系统都使用 WS* 方法。 WS* 标准不仅支持简单的请求/响应,还支持除 http 之外的异步消息和传输(JMS、文件等),更重要的是,WS 安全标准经过精心设计,支持安全的企业间通信。

Its important to separate SOA the architecture from SOAP , REST and other implementations of the architecture.

You can implement a SOA architecture on top of any technoligy that supports request and response via messages.

The core characteristic of a SOA architecture are:-

  • Clients send simple request messages.
  • Server repsponds with single reply messages.
  • Service interfaces are well defined and "advertised" to clients. i.e. CLients can query the server on what services are suppoted and what the interface for these services are.
  • No replication of data and no local storage. If a client wants to know about a Widget then it queries the Widget service, the client does not retain any of the Widget data. Likewise if a client wants to update a Widget's details it sends an update request to the Widget service.
  • Synchronous, Asynchronous and Batch interfaces are all acceptable.

The key advantages of this as an architecture are:-

  • The only contact between a server and its clients is the "interface". The client has and needs absolutly no knowlege of the servers implementation, likewise the server does not care how a client is implemented.
  • The data is owned and managed by the Service and only the service. This eliminates synchroisation, replication problems, and reduces to almost zero the possibility of double updates.
  • The absolute simplicity of the resulting architecture allows for great flexibility.
  • The absolute simplicity of the resulting architecture makes for very reliable systems.

However as you quite rightly concluded in the real world mostly SOAP and REST are used. When people say SOAP they are usually refering to the WS-* series of standards and protocols -->WSDL (Web Service Definition Language), WSM (Web Service Messaging) , WS-Security etc. etc. which use SOAP as the transport mechanism.

Whereas REST has the virtue of simplicity, and, the WS* is highly complex and more difficult to implement I would recommend the WS* approach for any reasonably large system. The WS* standards support not only simple request/response but also asynchronous messages and transports other than http (JMS, files etc), and, more importantly the WS security standard is well though out and supports secure business to buisness communication.

苦妄 2024-09-26 07:56:15

首先,阅读以下内容:http://www.soaspecs.com/ws.php

然后阅读以下内容: http://en.wikipedia.org/wiki/Web_service

最终,一切完全基于 HTTP。这就是核心协议。你问的至少是两个不同的事情。 XML、JSON 或其他内容中文档(或参数)的编码。传输内容的语义:不受 HTTP 约束或约束。

XMLRPC - http://en.wikipedia.org/wiki/XML-RPC。这演变成了 SOAP。该消息采用 XML 格式。语义是函数调用。该消息包括方法和参数。

SOAP - http://en.wikipedia.org/wiki/SOAP。该消息以 XML 形式编码。它与 XMLRPC 类似,具有更多选项、更复杂的 XML 和正式的 WSDL 描述。
http://en.wikipedia.org/wiki/Web_Services_Description_Language

如果您使用 JSON 而不是 XML ,没有一个好名字。它是带有 JSON 的 WS 或 REST。如果使用 XML,那么它只是 SOAP。

有两种通用的架构。 SOAP 风格的请求可以在请求中定义任何动词,而 REST 则只有四个动词:POST、GET、UPDATE、DELETE,它们是 HTTP 请求的方法部分。

休息 - http://en.wikipedia.org/wiki/Representational_State_Transfer。您可以在 REST 中使用任何消息编码。有些人使用 XML,有些人使用 JSON 或 YAML。您可以轻松发明 XML 和 JSON/YAML 之外的其他表示形式。但是,您必须使用四个规范动词。

First, read this: http://www.soaspecs.com/ws.php.

Then read this: http://en.wikipedia.org/wiki/Web_service

Ultimately, everything sits squarely on HTTP. That's the core protocol. What you're asking about is at least two different things. The encoding of document (or arguments) in XML, JSON or something else. The semantics of what's transferred: unconstrained or constrained by HTTP.

XMLRPC - http://en.wikipedia.org/wiki/XML-RPC. This evolved into SOAP. The message is in XML. The semantics are a function call. The message includes the method and the arguments.

SOAP - http://en.wikipedia.org/wiki/SOAP. The message is encoded in XML. It is similar to XMLRPC, with more options, more complex XML and formal WSDL descriptions.
http://en.wikipedia.org/wiki/Web_Services_Description_Language

If you use JSON instead of XML, there's no good name for it. It's WS or REST with JSON. It's only SOAP if it uses XML.

There are two general kind of architectures. The SOAP-style request where any verb could be defined in the request, vs. REST where there are just four verbs: POST, GET, UPDATE, DELETE and they're the method portion of the HTTP request.

REST - http://en.wikipedia.org/wiki/Representational_State_Transfer. You can use any message encoding with REST. Some folks use XML, some folks use JSON or YAML. You can easily invent other representations beyond XML and JSON/YAML. However, you are constrained to use the four canonical verbs.

念三年u 2024-09-26 07:56:15

如果您想了解最新的 WS 标准,请使用 WS* 堆栈。

if you want to be current with WS standards use WS* stack.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文