企业级排队/消息系统何时取代更简单的工作流程管理系统？
大家好：我有“简单”的工作流管理技巧（如旋转文件队列、控制器线程等），可以在各种生产者/消费者上下文中工作...文件只需重命名、删除和创建系统化的方式；或者“主”线程调用并协调工作人员。
相比之下，我还在一些玩具应用程序中“玩过”JMS，并且我可以看到如何使用它来协调复杂的应用程序工作流程。
我想知道：像 JMS 这样的消息传递服务通过标准生产者/消费者工作流程提供什么（当然，如果我在这里遗漏了某些内容，或者对何时/为何使用 JMS 有错误的想法，请随时纠正我）？
特别是，什么类型的应用程序需要企业级消息传递框架？
Hi guys: I've "simplistic" workflow management tricks (like rotating file queues, controller threads, etc...) work in a wide variety of producer/consumer contexts... Where files are simply renamed, deleted, and created in a systematic manner; or where a "main" thread is calls and coordinates workers.
In contrast, I've also "played" with JMS in some toy applications, and I can see how it might be used to coordinate a complex application workflow.
I was wondering: What do messaging services like JMS offer over standard producer/consumer workflows (of course, if I'm missing something here, or have the wrong idea of when/why JMS is used, feel free to correct me)?
In particular, what type of applications require enterprise-grade messaging frameworks?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
可扩展性、可用性、透明度、可管理性。在点对点通信中，发送方与接收方绑定，反之亦然。作为应用程序开发人员，您有责任考虑流量增加时该怎么做，并实施必要的更改。您的应用程序必须了解其工作环境，并且每次环境发生变化时都必须进行更改。您被迫重新发明轮子，同时解决典型的消息传递问题，例如临时拥塞（当消费者暂时无法跟上生产者的步伐时该怎么办？）。如果某些事情没有按预期进行，您必须提供自己的监控当前情况的方法。这样的例子不胜枚举……
现在想象一下您必须以这种方式连接 10 个不同的系统。显然，您需要提出一个相当通用的解决方案，这样您就不会从头开始实现每个连接逻辑 - 这将导致生产成本非常昂贵，更不用说维护它了。 JMS 消息代理就是此类可能的通用解决方案之一。
简而言之，很复杂。我工作的公司拥有大约 70 个系统的网络，其中一些已有 30 年的历史。随着时间的推移，新系统会添加到网络中，而旧系统不需要更改，新系统也不必了解古老的数据交换协议——集中的消息代理集群可以将 JMS 消息转换为某种大型机消息格式我不知道，并以同样的方式返回答案。
Scalability, availability, transparency, manageability. In point-to-point communication sender is bound to the receiver and vice versa. You, as the application developer, are responsible for thinking what to do when traffic increases and implement the necessary changes. Your application must be aware of the environment in which it works and must be changed every time the environment changes. You are forced to reinvent the wheel while solving typical messaging problems, for example, temporary congestion (what to do when the consumer can't keep the pace with the producer for a while?). You have to provide your own means of monitoring the current situation, if something does not work as expected. The list goes on...
Now imagine you have to wire 10 different systems this way. Obviously, you'll need to come up with a fairly universal solution so that you don't implement each connection logic from scratch — that would be terribly expensive to produce, not to mention maintaining it. A JMS message broker is one of such possible general solutions.
Complicated, in short. I work for a company that has a network of about 70 systems, some of them 30 years old. New systems are added to the network as time passes and the old systems don't need to be changed, neither must new systems be aware of ancient data exchange protocols — a centralized cluster of message brokers can translate a JMS message into some mainframe message format I have no idea about, and same way back with the answer.