我要做一个小型的贸易管理系统。我想创建一个独立的数据库服务，所有其他客户端都连接到该服务。数据库将是 MYSQL，我将使用 Java 来制作服务。客户端可以是 Web 应用程序，也可以是使用 Java Swing 的桌面应用程序（尚未确定）。在客户端和数据库服务之间会有另一层来处理业务逻辑（我称之为交易服务）。
架构类似于：客户端 -> 交易服务 -> 数据库服务。
我的问题是，哪种客户端/服务通信技术最适合客户->贸易服务，最适合贸易服务->数据库。
我应该让它成为 RESTful 服务吗？肥皂？使用 RPC？还是其他什么技术？
非常感谢您的帮助。欢迎任何想法或建议。
看看 RabbitMQ，一个池消息服务
http://www.rabbitmq.com/ 它强大、灵活、快速且可扩展，您可以使用它在 Java、PHP 或任何您想要的技术中进行通信。
我应该让它成为 RESTful 服务吗？肥皂？使用 RPC？
这些都是非常相似的方法，因为它们都是通过 HTTP 实现的——假设这就是你想要的；我会推荐使用 RESTful。您将有很多示例可以使用，并且它可以让您在未来灵活地执行诸如为智能手机应用程序或桌面应用程序切换 UI 层之类的事情。
无论您选择哪种模型，您都应该首先了解它的工作原理，并尽早构建安全性和指南等内容。现在做你的功课。尝试像这样更改设计的中间层是一种痛苦。
您的问题没有笼统的答案，而是根据您的技能组合提供选项。您是否在概念上完全理解 HTTP 规范并能够将其扩展到 REST，它与 HTTP（共同创建祖先）非常紧密地工作。您是否更好地理解了 SOAP 的传统方法调用？您是否将生态系统与特定语言联系在一起，因为这会影响您选择的工具。
如果您付钱让我根据您给出的简单要求编写服务（这几乎是不可能的），我会创建一个域驱动的设计服务（您的业务层），它具有 RESTful 接口和用于数据访问的 Spring JDBC。这就是我，也是我最常从事的工作。我在工作中的犯罪伙伴可能会选择 SOAP 和 Hibernate。
我认为你正在考虑的是队列，我猜你需要一个托管服务。队列可以成为微服务之间的粘合剂。我认识的一些拥有队列即服务的供应商是：
CloudBoost.io：https://www.cloudboost.io _
查看https://tutorials.cloudboost.io/en/queues/basicqueues以获取文档。
Iron.io：https://www.iron.io _
PS：我在 CloudBoost 工作