Cross Application Communication (C#)

I'm working on a software solution to for a group of applications running on the same server.

The applications are loosely related, and share an event log. The problem that we are running into is performance, with each application making calls to the database every time they need to log an event.

What I'm trying to do is decouple the entire process by removing the applications direct calls to the database, and routing them through a service running on the machine whos sole purpose is processing events from the multiple applications on the machine.

Ultimately my goal is to implement some sort of system in the "Event" Helper Object that would allow those objects to communicate directly with the "Event" Service.

My first instinct was to use your typical "event", but it would appear from the research that I've done that it is not possible to invoke an event in one process to be handled in another process.

As a part of my research I came across Listen for events in another application and C# Win32 messaging with SendMessage.

Sendmessage looks like a promising solution, but I wanted to be sure so I spoke with one of my colleagues who was close to the project (the original developer who was moved on to a new project before the completion of this one) and he imparted some additional information as to the situation. They had apparently attmped to use WCF and build it as a web service. This probably would have worked except for the location and security level of the server itself.

He believes it MAY be possible to implement a WCF system at the OS level without having to use it in a web service environment.

My question is... "Is using WCF possible at the OS level?" and "Which of the options listed would be the most efficent under the scenario?" Keeping in mind that this MUST be decoupled and the applications cannot have any interaction with the event log in the database itself.

WCF Update:

So I started putting something together and this is what I came up with..

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 : ISelfHo开发者_运维百科stingService
    {
        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();
        }
    }
}

But there is a problem. This line:

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

I guarantee that the server will not allow the service to register that local address (its been tried already and it was a flop).

So my new question is... "Is there a way around that that does not involve changing configuration settings on the server itself?"

MSMQ Update:

This is deffinately an option but... [pregnant pause] We do use the message queue for other pieces of functionality. My only hesitation is the overhead. I'd rather that it was completely decoupled I'm looking for an application to application solution. I'd rather that the service was "listening" instead of going to get.

Finale

I did a lot more research and I've decided that using WCF is in my best interest. As a part of the windows service I plan on adding an app.config for the event logging service and then configuring the service to use named pipes over localhost.

thanks for all the help

Follow-Up

For anyone who might be interested. This works beautifuly. The net.pipe is active and I am able to create events and send them to the service from multiple apps with little or no processing time.

The wcf service is encased in a very simple windows service that simply opens the service pipe. on the client side i was able to discover and implement the service easily. All i have to do is make a call to the client class and it shows my events in real time in the database.

Thanks again.

---

you could do WCF without web hosting and without IIS, those WCF services will be TcpIp and will work in your local network with no problems, in this way you don't have SOAP Serialization.

One approach you could also use ( and I did use in a former company where we had a multi server multi-tier distributed application ), is to make your Event Helper Object to simply queue messages to a MSMQ which will reside on a certain server, this method works very well because is not synchronous like SendMessage so your application works even if the listener application is not available and not running or simply busy.

Then you could have a windows Service running on that machine ( we used to call it LoggingManager ) which peeks the messages from the queue and created the log in the databases at his own speed and peace ;-)

---

I've come across this requirement before. The solution usually involves writing the "event" to a "queue" and having a dedicated service reading the queue and posting to the database. WCF supports MSMQ and is a good choice.

---

You are describing to me, what sounds a lot like a service bus architecture - without me knowing a terrible great deal about the subject. Or am I completely wrong? If not, take a look at producks such as NServiceBus (http://www.nservicebus.com/). Maybe that will help you?

Regards, Morten

---

I'd suggest using WCF. It can be easily configured to only accept requests from the local machine for security purposes, and is more conducive to friendly .NET code then something like SendMessage or using NamedPipes or Ports directly.

---

If you like SendMessage concept, take a look at our MsgConnect product, which offers the same approach for communications between processes running on the same or on different systems. MsgConnect is cross-platofrm and is not limited to .NET.

WCF can be an option as well, though MsgConnect's API is probably simpler and easier to manage (as you also get the source code and support).

---

I think you want a self-hosted WCF application. This is a great book on WCF and chapter four talks about self-hosting.

---

Just in addition to those other answers: Your "Event" Helper could be a custom tracing component you register in your various applications. Doing so you wouldn't have to directly reference a "Event" Helper target in your applications but just log your events to the configured trace output.