【问题标题】:Cross Application Communication (C#)跨应用程序通信 (C#)
【发布时间】:2011-02-21 20:31:47
【问题描述】:

我正在为在同一台服务器上运行的一组应用程序开发软件解决方案。

应用程序松散相关,并共享一个事件日志。我们遇到的问题是性能问题,每个应用程序在每次需要记录事件时都会调用数据库。

我正在尝试做的是通过删除应用程序对数据库的直接调用来解耦整个过程,并通过机器上运行的服务路由它们,该服务的唯一目的是处理来自机器上多个应用程序的事件。

最终我的目标是在“事件”帮助对象中实现某种系统,允许这些对象直接与“事件”服务通信。

我的第一直觉是使用典型的“事件”,但从我所做的研究来看,不可能在一个进程中调用事件以在另一个进程中处理。

作为我研究的一部分,我遇到了Listen for events in another applicationC# Win32 messaging with SendMessage

Sendmessage 看起来是一个很有前途的解决方案,但我想确定一下,所以我与一位与该项目关系密切的同事(在此项目完成之前被转移到新项目的原始开发人员)进行了交谈,并且他提供了一些有关情况的补充信息。他们显然已经尝试使用 WCF 并将其构建为 Web 服务。除了服务器本身的位置和安全级别之外,这可能会起作用。

他认为有可能在操作系统级别实现 WCF 系统,而不必在 Web 服务环境中使用它。

我的问题是......“是否可以在操作系统级别使用 WCF?”和“在这种情况下,列出的哪些选项最有效?”请记住,这必须解耦,并且应用程序不能与数据库本身的事件日志进行任何交互。

WCF 更新:

所以我开始把一些东西放在一起,这就是我想出的..

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using System.ServiceModel;
using System.ServiceModel.Description;

namespace SelfHost
{
    [ServiceContract]
    public interface ISelfHostingService
    {
        [OperationContract]
        string SelfHost(string name);
    }
    public class SelfHostingService : ISelfHostingService
    {
        public string SelfHost(string name)
        {
            return string.Format("Hello, {0}", name);
        }
    }
    class Program
    {
        static void Main(string[] args)
        {
            Uri baseAddress = new Uri("http://localhost:8080/SelfHost");
            ServiceHost host = new ServiceHost(typeof(SelfHostingService), baseAddress);
            host.AddServiceEndpoint(typeof(SelfHost.ISelfHostingService), new BasicHttpBinding(), baseAddress);
                host.Open();
                Console.WriteLine("The service is ready at {0}", baseAddress);
                Console.WriteLine("Press <Enter> to stop the service.");
                Console.ReadLine();
        }
    }
}

但是有一个问题。这一行:

Uri baseAddress = new Uri("http://localhost:8080/SelfHost");

我保证服务器不会允许服务注册该本地地址(它已经尝试过,但失败了)。

所以我的新问题是……“有没有一种不涉及更改服务器本身的配置设置的方法?”

MSMQ 更新:

这绝对是一个选项,但是... [怀孕暂停] 我们确实将消息队列用于其他功能。我唯一的犹豫是开销。我宁愿它完全解耦我正在寻找一个应用程序到应用程序的解决方案。我宁愿服务是“倾听”而不是去获取。

结局

我进行了更多研究,并确定使用 WCF 符合我的最大利益。 作为 Windows 服务的一部分,我计划为事件日志服务添加一个 app.config,然后将服务配置为在 localhost 上使用命名管道。

感谢大家的帮助

跟进

对于任何可能感兴趣的人。这很好用。 net.pipe 处于活动状态,我能够创建事件并将它们从多个应用程序发送到服务,而处理时间很少或根本没有。

wcf 服务被封装在一个非常简单的 windows 服务中,它只是打开了服务管道。在客户端,我能够轻松地发现和实施服务。我所要做的就是调用客户端类,它会在数据库中实时显示我的事件。

再次感谢。

【问题讨论】:

    标签: c# wcf ipc msmq


    【解决方案1】:

    您可以在没有 Web 托管和 IIS 的情况下执行 WCF,这些 WCF 服务将是 TcpIp 并且可以在您的本地网络中正常工作,这样您就没有 SOAP 序列化。

    您也可以使用的一种方法(我曾在一家以前的公司中使用过,我们有一个多服务器多层分布式应用程序),就是让您的事件助手对象简单地将消息排队到 MSMQ,该 MSMQ 将驻留在某些服务器,此方法效果很好,因为它不像 SendMessage 那样同步,因此即使侦听器应用程序不可用且未运行或只是忙,您的应用程序也能正常工作。

    然后,您可以在该机器上运行一个 Windows 服务(我们以前称之为 LoggingManager),它可以从队列中查看消息并以自己的速度和和平在数据库中创建日志;-)

    【讨论】:

    • 如果可以的话,看看我的 WCF 更新。从您的评论中几乎可以看出,还有另一种解决基址问题的方法,但我无法找到任何不包括规范“localhost:8080/myservice”的内容
    • 我在youtube.com/watch?v=FPrQPA9QmUw 观看视频,看起来在配置中您可以使用 tcpip 和命名管道这就是您不使用 IIS 的意思吗?
    • 是的,但请记住,您应该使用 TcpIp,命名管道不适用于机器间通信。
    • 此时确实没有机器间通信......我的理解是,如果它需要机器间通信,我只需要添加一个额外的端点。我主要关心的是 wcf 需要在机器上使用本地端口。我没有办法解决这个问题,也没有办法在这台机器上配置本地端口。
    【解决方案2】:

    我以前遇到过这个要求。该解决方案通常涉及将“事件”写入“队列”并让专用服务读取队列并发布到数据库。 WCF 支持 MSMQ,是一个不错的选择。

    【讨论】:

      【解决方案3】:

      您正在向我描述,这听起来很像服务总线架构 - 我对这个主题知之甚少。还是我完全错了?如果没有,请查看 NServiceBus (http://www.nservicebus.com/) 等产品。也许这会对你有所帮助?

      问候, 莫腾

      【讨论】:

        【解决方案4】:

        我建议使用 WCF。出于安全目的,它可以很容易地配置为仅接受来自本地计算机的请求,并且比 SendMessage 或直接使用 NamedPipes 或 Ports 更有利于友好的 .NET 代码。

        【讨论】:

          【解决方案5】:

          如果您喜欢 SendMessage 概念,请查看我们的MsgConnect 产品,它为在相同或不同系统上运行的进程之间的通信提供了相同的方法。 MsgConnect 是跨平台的,不限于 .NET。

          WCF 也可以是一个选项,尽管 MsgConnect 的 API 可能更简单且更易于管理(因为您还可以获得源代码和支持)。

          【讨论】:

            【解决方案6】:

            我认为您想要一个自托管的 WCF 应用程序。 This 是一本关于 WCF 的好书,第四章讨论了自托管。

            【讨论】:

              【解决方案7】:

              除了这些其他答案:您的“事件”助手可能是您在各种应用程序中注册的custom tracing component。这样做您不必在应用程序中直接引用“事件”帮助程序目标,只需将事件记录到配置的跟踪输出。

              【讨论】:

                猜你喜欢
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 1970-01-01
                • 2014-10-01
                • 1970-01-01
                • 2011-04-30
                相关资源
                最近更新 更多