何时使用 ESB？通过电子邮件/XMPP/SMS 发送消息
我通过支持多种通知方法为应用程序添加了更多深度。目前，如果网站上出现异常或网站上发生事件，则会向这些用户发送一封电子邮件，但我希望这种方式更加通用。我希望用户能够优先考虑他们的通知方法。如果他们想在在线时收到 XMPP 消息，那么他们将以这种方式收到通知。如果他们不在线，那么他们会收到一封电子邮件，等等。
看起来我想在这里使用 ESB，但我看到的每个 ESB 看起来都是重量级的。现在，我没有任何发送/移动文件的意图或需要集群/故障转移。
我玩过一点 Smack，它非常适合我想要的东西。它只是一个 XMPP 客户端库。我想在阅读这些回复后，我必须确定我能从 Apache Camel 或 Active MQ 等中获得多少收益。我想要的主要组件是路由引擎。我可以轻松地编写自己的一个，对不同的方法进行优先级/排序，但我想知道现在咬紧牙关是否比以后更有利，并且必须废弃我的自定义路由引擎。
I am adding some more depth to the application by supporting multiple methods for notification. Currently, if there is an exception on the site or an event occurs on the site, an email will be sent out to those users, but I want that to be more generic. I want the users to be able to prioritize their notification methods. If they want to get an XMPP message when they're online, then they will be notified that way. If they're not online, then they'll get an email, so on and so forth.
It seems like an ESB would be what I would want to use here, but every ESB I look at looks like it is heavyweight. Right now, I don't have any intentions of sending/moving files or the need yet for clustering/failover.
I have played with Smack a little bit, and it works well for what I want. It is simply an XMPP client library. I guess after reading these responses, I have to determine how much do I gain from Apache Camel or Active MQ, etc. The main component I want is the routing engine. I can easily write one of my own, that prioritizes/orders different methods, but I'm wondering if it is more beneficial to bite the bullet now as opposed to later and have to scrap my custom routing engine.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
ESB 非常重量级。除非你有埃森哲的人在你耳边窃窃私语，否则我强烈建议你选择更容易管理的东西。
像 EventBus 之类的东西似乎更符合您的要求，或者，如果您正在使用Spring，它有一个内置的同步/异步事件调度程序机制，可以在单个 JVM 上很好地完成这项工作。
ESBs are very heavyweight. Unless you have a man from Accenture whispering in your ear, I strongly suggest going with something a bit more manageable.
Something like EventBus would seem to be more in keeping with your requirements, or, if you're using Spring, it has a built-in sync/async event dispatcher mechanism that does the job nicely on a single JVM.
ESB 是重量级的。其中一个集成项目应该可以解决问题。我想到了 Apache Camel 和 Spring Integration。 Apache Camel 已经内置了对电子邮件和 XMPP 的支持。 Spring Integration 内置了电子邮件，但您目前需要构建自己的 XMPP 适配器，但它似乎正在开发中，请参阅 Spring 集成 2.0。
您需要在其中任何一个中构建一些路由逻辑，以便当您向用户发送消息时，它可以判断用户是否在线并进行适当的路由。
编辑：从技术上讲，Apache Camel 和 Spring Integration 都可以被视为 ESB，但它们绝对处于规模的轻量级，因为它们都没有强制执行容器机制。有关 Camel 是否是 ESB 的更多信息。
ESBs are heavy weight. One of the integration projects should do the trick. Apache Camel and Spring Integration come to mind. Apache Camel already has built in support for Email and XMPP. Spring Integration has Email built in but you'll need to build your own XMPP adapter at the moment but it appears to be on the way see Spring Integration 2.0.
You'll need to build some routing logic in either of these so that when you send a message to a user, it can tell whether the user is online and route appropriately.
Edit: Technically both Apache Camel and Spring Integration could be considered ESBs but they're definitely at the lightweight end of the scale as neither of them enforce a container mechanism. More information on whether Camel is an ESB.
我推荐 Apache Camel - 它非常易于使用，并且附带 XMPP 和 邮件 支持 - 以及许多其他 组件。
如果稍后您想要独立管理camel - 您可以将其部署在 OSGI 容器也是如此。
I'd recommend Apache Camel - its very easy to use and comes with XMPP and mail support - along with many other components.
If at a later point, you want to manage camel standalone - you can deploy it in an OSGI container too.
我认为现在就像我过去在其他项目中所做的那样，我将暂时推出自己的消息路由器。它的重量会更轻，我会对这些东西的工作原理有更多的欣赏/理解。
我正在使用的基础设施可以使用 JMS 后端，但目前正在使用单个 JVM 的观察者/发布者模型。我使用 Quartz 作业来处理所有请求，这样服务器就不会因太多请求而不堪重负。当我扩展到更多服务器时，如果需要，我可以使用 JMS 队列，而无需更改我的代码库。
瓦尔特
I think for now as I've done in the past with other projects, I will roll out my own message router for the time being. It will be lighter weight and I'll have greater appreciation/understanding for how that stuff works.
The infrastructure I'm using can use a JMS backend, but is currently using the Observer/Publisher model for a single JVM presently. I am using Quartz jobs to handle all requests so the server is not overwhelmed with too many requests. When I scale out to more servers, I can use a JMS queue if needed without changing my code base.
Walter