Cross Application Communication (C #)

Question

I am working on a software solution for a group of applications running on the same server.

Applications are loosely coupled and share an event log. The problem we are facing is performance, in which each application calls the database every time they need to register an event.

What I'm trying to do is to separate the whole process by removing direct application calls to the database and routing them through a service running on the machine. The only goal is to handle events from multiple applications on the machine.

Ultimately, my goal is to implement some kind of system in the Event helper object, which will allow these objects to communicate directly with the Event service.

My first instinct was to use your typical “event”, but from the study, I realized that I cannot trigger an event in one process to process in another process.

As part of my research, I met Event Listening in another application and C # Win32 Messaging using SendMessage .

Sendmessage looks like a promising solution, but I wanted to be sure, so I talked to one of my colleagues who was close to the project (the original developer who was transferred to the new project before this was completed) and he gave additional information about the situation. They apparently tried to use WCF and create it as a web service. Perhaps this would work, except for the location and security level of the server itself.

He believes that 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 WCF used at OS level?" and "Which of the following options will be most effective in the scenario?" Bearing in mind that this MUST be untied, and applications cannot interact with the event log in the database itself.

WCF Update:

So, I started to put 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 : 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(); } } } 

But there's a problem. This line:

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

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

So, my new question ... "Is there a way that is not related to changing the configuration settings on the server itself?"

MSMQ Update:

This is indeed an option, but ... [pregnant pause] We use the message queue for other functions. My only hesitation is overhead. I would prefer it to be completely untied. I am looking for an application to solve applications. I would prefer the service to “listen” rather than get ready.

Finale

I did a lot more research, and I decided that using WCF was in my interest. As part of the Windows service, I plan to add app.config for the event logging service, and then configure the service to use named pipes on the local host.

thanks for the help

Follow-up

For anyone who may be interested. It works great. Net.pipe is active, and I can create events and send them to the service from several applications with little or no processing time.

The wcf service is enclosed in a very simple Windows service that simply opens a service pipe. on the client side, I was able to easily detect and implement the service. All I have to do is call the client class and show my events in real time in the database.

Thanks again.

Answer 1

you can do WCF without web hosting and without IIS, these WCF services will be TcpIp and will work on your local network without problems, so you do not have SOAP serialization.

One approach that you could use (and I used in a former company, where we had a multi-server multi-tiered distributed application), is to make your event auxiliary event object simply forward messages to MSMQ, which will be located on a specific server, this method works very well because it is not synchronous like SendMessage, so your application works even if the listener application is inaccessible and not working or just busy.

Then you could run the Windows Service on this computer (we used its LoggingManager), which looked in the messages from the queue and created a log in the databases with its own speed and world; -)

Answer 2

I have already come across this requirement. A solution usually involves writing an “event” to a “queue” and having a dedicated service that reads the queue and places it in the database. WCF supports MSMQ and is a good choice.

Answer 3

You describe to me what is very similar to the service bus architecture - without me, knowing the terrible situation on this issue. Or am I completely wrong? If not, look at products such as NServiceBus (http://www.nservicebus.com/). Maybe this will help you?

Regards, Morten

Answer 4

I would suggest using WCF. It can only be easily configured to accept requests from the local computer for security reasons and is more favorable for friendly .NET code, and then something like SendMessage or directly using NamedPipes or ports.

Answer 5

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

WCF can also be an option, although the MsgConnect API is probably simpler and easier to manage (since you also get the source code and support).

Answer 6

I think you want to use a self-contained WCF application. This is a great book about WCF, and the fourth chapter talks about self-care.

Answer 7

In addition to these other answers: your "Event" helper can be a custom tracking component that you register with various applications. In this case, you will not need to directly refer to the event target in your applications, but simply log your events to the configured trace output.