Связь между приложениями (C #) - PullRequest
4 голосов
/ 21 февраля 2011

Я работаю над программным решением для группы приложений, работающих на одном сервере.

Приложения слабо связаны и делятся журналом событий. Проблема, с которой мы сталкиваемся, заключается в производительности: каждое приложение выполняет вызовы базы данных каждый раз, когда им нужно зарегистрировать событие.

Я пытаюсь отделить весь процесс, удалив прямые обращения приложений к базе данных и направив их через службу, работающую на машине, единственной целью которой является обработка событий от нескольких приложений на машине.

Event Helper Service - Image

В конечном итоге моя цель - внедрить в объект-помощник «Событие» какую-то систему, которая позволяла бы этим объектам напрямую взаимодействовать со службой «Событие».

Моим первым инстинктом было использование вашего типичного «события», но из проведенного мною исследования стало очевидно, что невозможно вызвать событие в одном процессе для обработки в другом процессе.

В рамках моего исследования я наткнулся на Прослушивание событий в другом приложении и C # Win32 обмен сообщениями с SendMessage .

Sendmessage выглядит как многообещающее решение, но я хотел быть уверенным, поэтому я поговорил с одним из моих коллег, который был близок к проекту (первоначальный разработчик, перешедший в новый проект до его завершения) и он передал некоторую дополнительную информацию относительно ситуации. Очевидно, они решили использовать WCF и построить его как веб-сервис. Это, вероятно, сработало бы, если бы не местоположение и уровень безопасности самого сервера.

Он считает, что МОЖЕТ быть возможно внедрить систему WCF на уровне ОС без необходимости использовать ее в среде веб-служб.

Мой вопрос ... "Возможно ли использование 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 Обновление:

Это определенно вариант, но ... [беременная пауза] Мы используем очередь сообщений для других функций. Мое единственное сомнение - накладные расходы. Я предпочел бы, чтобы это было полностью отделено, я ищу приложение к решению для приложения. Я бы предпочел, чтобы служба «слушала», а не собиралась получить.

Finale

Я провел гораздо больше исследований и решил, что использование WCF в моих интересах. Как часть службы Windows, я планирую добавить app.config для службы регистрации событий, а затем настроить службу для использования именованных каналов через localhost.

спасибо за помощь

Follow-Up

Для тех, кому это может быть интересно. Это работает красиво. Net.pipe активен, и я могу создавать события и отправлять их в службу из нескольких приложений с минимальным временем обработки или без него.

Служба wcf заключена в очень простую службу Windows, которая просто открывает канал службы. на стороне клиента я смог легко найти и внедрить услугу. Все, что мне нужно сделать, это позвонить клиентскому классу, и он покажет мои события в режиме реального времени в базе данных.

Еще раз спасибо.

Ответы [ 7 ]

3 голосов
/ 21 февраля 2011

вы могли бы делать WCF без веб-хостинга и без IIS, эти службы WCF будут TcpIp и будут работать в вашей локальной сети без проблем, таким образом, у вас не будет сериализации SOAP.

Один подходВы также можете использовать (и я использовал в бывшей компании, где у нас было многосерверное многоуровневое распределенное приложение), чтобы ваш объект Event Helper просто помещал сообщения в MSMQ, который будет находиться на определенном сервере, этот методработает очень хорошо, потому что не является синхронным, как SendMessage, поэтому ваше приложение работает, даже если приложение слушателя недоступно, не запущено или просто занято.

Тогда на этом компьютере может быть запущена служба Windows (мы использовали для вызоваэто LoggingManager), который просматривает сообщения из очереди и создает журнал в базах данных со своей скоростью и скоростью; -)

2 голосов
/ 21 февраля 2011

Вы описываете мне, что звучит очень похоже на архитектуру служебной шины - я не знаю ужасно много об этом предмете.Или я совершенно не прав?Если нет, взгляните на такие продукты, как NServiceBus (http://www.nservicebus.com/). Может быть, это поможет вам?

С уважением, Мортен

2 голосов
/ 21 февраля 2011

Я уже сталкивался с этим требованием раньше. Решение обычно включает в себя запись «события» в «очередь» и наличие выделенного сервиса, читающего очередь и проводящего в базу данных. WCF поддерживает MSMQ и является хорошим выбором.

0 голосов
/ 22 февраля 2011

Просто в дополнение к этим другим ответам: Ваш помощник по «событию» может быть настраиваемым компонентом трассировки , который вы регистрируете в своих различных приложениях.При этом вам не нужно будет напрямую ссылаться на цель «Event» Helper в ваших приложениях, а просто записывать события в настроенный вывод трассировки.

0 голосов
/ 21 февраля 2011

Я думаю, что вы хотите самостоятельное приложение WCF. Эта - отличная книга о WCF, а в четвертой главе рассказывается о самостоятельном размещении.

0 голосов
/ 21 февраля 2011

Если вам нравится концепция SendMessage, взгляните на наш продукт MsgConnect , который предлагает тот же подход для обмена данными между процессами, работающими в одной и той же или в разных системах. MsgConnect является кросс-платформенным и не ограничивается .NET.

WCF также может быть опцией, хотя API MsgConnect, вероятно, проще и проще в управлении (так как вы также получаете исходный код и поддержку).

0 голосов
/ 21 февраля 2011

Я бы предложил использовать WCF.Он может быть легко настроен на прием запросов только от локального компьютера в целях безопасности и более благоприятен для дружественного кода .NET, чем что-то вроде SendMessage или непосредственного использования NamedPipes или Ports.

...