9

在阅读了面向服务的架构原则站点和相应的 Wikipedia文章后，我有一个想法：Erlang/OTP 平台可以被视为一个 SOA 平台，并且可以在其上构建 SOA 应用程序。

唯一的问题是这样一个系统中每个服务的服务契约是非常具体的：为了调用 Erlang/OTP 中的服务，编排层必须通过 Erlang 消息或调用 gen_server 进行调用（取决于实现） .

这不会让对 Erlang/OTP 平台范围之外的服务进行任何调用。

但是，如果我们尝试通过将所有各自的 Service 功能移动到基于 Erlang 的 Web 服务器（如 Mochiweb）中来构建每个 Service，并从本质上将每个 Service 的接口从 gen_server:call 更改为 XML，那会怎样？

这将允许使用基于WSDL的通用服务合同从标准化的“砖块”组合各种应用程序。

此外，这种方法将让我们继续使用 OTP 管理器和其他 OTP 功能，因为这样的服务仍然是 OTP 应用程序。

所以，问题是：您认为通过使用 OTP 网络服务器 (Mochiweb) 作为服务来使用面向服务的架构方法构建软件应用程序是一个好主意吗？额外的 XML 处理层会破坏这种方法的所有优点吗？

带有 Erlang/OTP 的 SOA

4

3 回答 3

8

没有这样做的主要原因是您将自己限制在 SOA 协议中。Erlang 通过一些附加点（监视器）实现了 IP 协议。虽然你可以做到，但我想知道它是否值得。

原则上，Erlang 已经拥有SOA理念的所有工具，但没有SOAP和WSDL的所有臃肿:)

于 2012-06-24T12:53:12.890 回答
6

这是我们 Erlang 的主要应用：Web 服务。我们通常使用Yaws Appmods，这里的一篇文章可以向您展示它是如何完成的。Erlang 一直是 SOA 的一个很好的平台，原因如下：

1. 无副作用的代码非常容易编写和测试。
2. 隔离：Erlang 中的进程有助于以干净的方式隔离每个服务请求。
3. 大多数 Erlang 库都喜欢mochiweb，misultin并且Chicago Boss已经从头开始构建以支持用 Erlang 编写的 SOA 系统。

在这些框架中的任何一个之后应用您自己的 OTP 应用程序是一个好主意。erlang 适合 SOA 的另一个重要原因是冗余。SOA 系统需要启动。如果服务请求失败，它会沿着不同的路径重试（当然，在物理层，它由分发 OTP 应用程序的不同机器处理）。

试试看，好主意

于 2012-06-25T08:00:47.847 回答
3

SOA 可以应用于许多实现技术，而不仅仅是 SOAPy Web 服务，而且我发现它总是有益的。例如，您可以将数据库视图和存储过程建模为服务。您可以将您的 java API 建模为服务。等等

现在，解决您的实际问题：

所以，问题是：您认为通过使用 OTP 网络服务器 (Mochiweb) 作为服务来使用面向服务的架构方法构建软件应用程序是一个好主意吗？

不。每个人都在从 SOAP 转向 REST。但是，使用 OTP 网络服务器 (Mochiweb) 作为 RESTful 服务，使用面向服务的架构方法构建软件应用程序可能是个好主意。

额外的 XML 处理层会破坏这种方法的所有优点吗？

这取决于你的目标是什么。如果您只是添加一个 XML 层，因为您认为它是“The Right Thing to Do™”，那么您将始终遇到 XML 层的问题，因为它是一个寻找要解决的问题的解决方案。如果您的目标是通过为您的实体创建普遍理解的表示来将服务器实现技术与客户端实现分离，那么额外的 XML（或 JSON 或任何最合适的）处理层是值得的。

于 2012-06-24T14:44:38.037 回答