在应用程序 B 中实时使用、发送消息并保存应用程序 A 中的审核数据的最佳方法
我最初的方法是在应用程序 A 的数据库中使用存储过程，在插入时触发以收集其他数据并调用由应用程序 B 托管的 Web 服务，以在其中执行必要的映射和持久性。应用程序 A 和应用程序 B 可能不在同一台计算机上。最初的要求是支持应用程序 A 端的 SQL Server 数据库。我想到了一个 CLR 存储过程。然而，人们认为调用 Web 服务不仅会对 SQL Server 引擎产生严重的性能影响，而且还需要提升 DBA 不喜欢授予的过程的权限。
我现在正在考虑在数据库 A 上创建某种形式的引用表的过程，以及使用该数据的轮询应用程序，并在应用程序 B 处理后进行清理。但是，我不得不认为除了轮询数据。
应用程序 A 仅适用于 Windows。应用程序 B 可以是 Windows、UNIX 或 LINUX，因此 Java 将是这方面的明显选择。
My initial approach to this was to use a stored procedure in database of Application A, triggered on an insert to gather additional data and call a web-service, hosted by Application B to do the necessary mapping and persistence there. Application A and Application B may not be on the same machine. The initial requirement is to support a SQL Server database on Application A's side. A CLR stored procedure came to mind. However, it was felt that calling out to a web-service would have both severe performance implications in the SQL Server engine and also require elevation of permissions for the procedure that DBA's do not like to give.
I am now thinking in terms of the procedure creating some form of reference table on database A and a polling application consuming this data and cleaning up once processed at Application B. However, I cannot but think that there is a better way of doing this beside polling for the data.
Application A is Windows only. Application B could be Windows, UNIX, or LINUX, so Java would be the obvious choice on this side.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
您给了我们一份您考虑过的方法列表，但除了这个问题的一句话标题之外，您还没有真正准确地概述您想要实现的目标是什么、您的目标是什么等等。您能具体说明一下您的要求是什么吗？
应用程序之间异步消息传递的标准答案是使用 JMS。每当应用程序 A 中发生应审核的事件时，应用程序 A 都会将消息放入队列中，并且应用程序 B 被编写为以一定的速率消耗队列中的消息（如果您想要“实时”，那么您可以经常轮询队列）。然后，应用程序 B 可以对这些消息执行任何需要的操作 - 将它们写入数据库、将它们发送到另一个 Web 服务等。
这样，应用程序 A 中的操作 - 您想要审核的内容 - 以及应用程序 B 的行为 - 如何您想要审核消息 - 彼此完全解耦。这允许您更改任一侧的内容 - 审核新类型的事件、更改消息的有效负载、将消息输出到其他位置等 - 而不更改另一侧。
它还允许您独立地扩展两个应用程序 - 您可以添加更多 A 实例而不影响 B，A 可以以比 B 消耗消息更高的速率生成消息，并且 A 不会等待 B 完成消息的消耗在它能够响应用户的操作之前。
You've given us a list of approaches you've considered but you haven't really outlined exactly what it is you are trying to accomplish, what your goals are, etc., other than the one-sentence title of this question. Can you clarify exactly what your requirements are?
The standard answer for asynchronous messaging between applications is to use JMS. Application A places messages onto a queue whenever events that should be audited occur within it, and Application B is written to consume messages from the queue at a certain rate (if you want "realtime", then you can poll the queue very often). Application B can then do whatever it needs to with these messages - write them to a database, sent them to another web service etc.
This way, the actions in Application A - what you want to audit - and the behavior of Application B - how you want to audit the messages - are completely de-coupled from one another. This allows you to change things on either side - audit new types of events, change the payload of the message, output the messages to somewhere else, etc. - without changing the other side.
It also allows you to scale both applications independently of the other - you can add more instances of A without affecting B, A can produce messages at a much higher rate than B consumes them, and A does not wait for B to finish consuming a message before it is able to respond to the user's actions.