SOA：为什么不使用 Erlang/OTP Web 服务器作为服务？

Question

看了Service Oriented Architecture Principles网站和各自的维基百科article之后，我有个想法：Erlang/OTP平台可以看成是一个SOA平台，可以在上面构建SOA应用程序。

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

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

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

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

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

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

Answer 1

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

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

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

试一试，好主意

Answer 2

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

现在，回答您的实际问题：

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

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

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

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

Answer 3

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

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