我想实现一个分布式销售点系统，有点像销售点应用程序架构建议中描述的那个。
它是一个具有以下特点的分布式系统：
我正在使用 JavaDB 作为数据库在 Java Swing 中实现客户端。
我的应用程序应该如何与消息代理和数据库通信？
我以前从未使用过消息队列和消息代理。我的想法是应用程序从数据库读取，但写入消息代理，消息代理写入数据库并与服务器通信。或者这是一个坏主意？我应该如何解决这个问题？
因此，除了我的嵌入式数据库之外，我还需要找到一个消息代理，最好是用 Java 编写的可以嵌入到我的应用程序中的消息代理，以便于安装。
在纯技术层面上，这可能是一个很好的起点：http: //java.sun.com/products/jms/tutorial/
您还绝对应该得到一本“企业集成模式”一书，它解释了可以使用排队系统的所有各种方式。
根据您的描述，我认为以下模式很有用（对不起，不知道书中使用的术语，因为我现在没有。自己编）：
发布订阅：服务器将发布消息（例如，价格信息的更新），这些消息将传递给订阅该信息的所有客户端。您必须涵盖的一个重要案例是一个问题，即当您的客户端在此类广播期间断开连接时会发生什么。您必须确保它不会错过任何消息，或者有办法再次赶上。
即发即弃：一个通信伙伴（例如客户端）将发送一条消息，而不期望任何类型的响应。排队系统将负责最终的交付。这可以用于提交订单等。
回调：这就像两个或多个相反方向的火灾和遗忘消息。后续调用将有一个 id，以便将消息标记为对之前收到的某个消息的响应。这在您提交订单但需要某种答案时很有用。当然，答案可能会在一天后到达，因此您需要一份未完成订单的列表，该列表可能也应该对用户可见，或者在列表中支持个人。发送多个回复时，必须处理消息乱序到达的情况。如果可能，处理此问题的一个好方法是在每个后续消息中包含先前消息的所有信息。这样您就可以简单地丢弃旧消息。
所以通信可以像这样工作： - 服务器偶尔会向所有客户端发送更新。该消息可能应该包含某种版本信息，因此客户端可以确保他们拥有所有消息。- 定期（或在一段时间内没有收到来自服务器的更新或......）客户端请求来自服务器的特殊更新，以确保它具有所有当前信息。上面提到的版本信息可用于识别缺失的信息 - 客户端接收消息并将内容存储在本地数据库中 - 客户端从数据库中读取以向用户呈现信息 - 客户端向服务器提交订单或任何内容，可能收到不同步的答案
一些一般性建议：
使用排队，您正处于并发地狱的中间。因此，对所有可能“出错”的事情要有创意。示例是 - 消息无序到达 - 接收者在发送时不可用（这就是首先使用消息传递的原因） - 接收者不可用并且永远不会重新上线。消息传递服务器具有保证传递的选项。这意味着他们必须存储消息，直到实际传递它。如果客户端永远不会重新上线，消息将永远保留，填满存储空间
确保所有消息处理都与应用程序的其余部分完全分离，以便于测试。
考虑升级服务器和客户端的过程，尤其是在消息格式发生变化时。您要么必须在同一时间点进行所有升级，中间有一些停机时间，要么您的服务器必须能够在一段时间内处理新旧消息格式。