Please help me ... Windows Services or Remoting

I have created three windows services in which two services listening two different logical ports continously and one service capture COM ports. These windows services informs the Main Window Application which is also running in different Application Domain or Window Process space. These services and windows application is created in C# .NET

My Question is that which is the best way to communicate between these Windows Services running on the same machine (locally).

1. DOT NET Remoting Services
2. Message Queues
3. Through Socket
4. Through Database

Reliability and scalibility is the main requirement because this machine act as a server and traffic is very high.

Your co-operation would be highly appreciated.
Thanks

[776 byte] By [ZeeshanGulzar] at [2008-2-10]
# 1

Hi,

.NET Remoting is the best way to communicate between the processes that you have mentioned. Use the TCP Channel with binary formatting for the Remoting and you will get a good performance.

In case, you are using .NET Framework v2.0, then it includes a new Channel called the IPCChannel which is the faster than a TCPChannel for communication on a local machine and you can use that.

Regards,
Vikram

Vikram at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...
# 2
I really thaks for your urgent reply. Really thaks a lot.

Is .NET Framework v2.0 is ready for commercial use ?

What about Windows Message Queuing (MSMQ). I use windows 2000 server without any directry service (WORKGROUP INSTALLATION). How i can use MSMQ in workgroup computer using .NET Framework ?

Best regards

ZeeshanGulzar at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...
# 3

Hi,

The .NET Framework is currently in Beta 2 and the release date has been fixed to 07 November 2005. However, the Beta 2 comes with a Go Live! License which means you run the applications that you build in Beta in production and later move to the final version when its released. Although changes from Beta 2 to Release version, Microsoft has promised that it would be minimal.
Take a look at the Go Live License here: http://lab.msdn.microsoft.com/vs2005/golive/

In Workgroup mode, you cant have public queues. For accessing MSMQ from .NET Framework, you would use the System.Messaging namespace. Here are some good links with code samples:

MSMQ For .NET Developers - Part 1
http://www.devx.com/dotnet/Article/27560
MSMQ For .NET Developers - Part 2
http://www.devx.com/dotnet/Article/27922

Programming MSMQ in .NET - Part 1
http://www.codeproject.com/dotnet/mgrmsmq.asp
Programming MSMQ in .NET - Part 2: Transactional Messaging
http://www.codeproject.com/dotnet/msmqpart2.asp
MSMQ Best Practices
http://download.microsoft.com/download/0/b/7/0b724828-5571-4278-8a81-ddde9c806a87/MSMQBestPractice.doc
Reliable Messaging with MSMQ and .NET
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdadotnetasync2.asp

Regards,
Vikram

Vikram at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...
# 4
Note that our guidance that Enterprise Services is often the best mechanism for x-process communication. Remoting is really the best (and only) solution for x-appdomain. Also note that ES is built on Remoting.
douglasp at 2007-9-9 > top of Msdn Tech,.NET Development,.NET Remoting and Runtime Serialization...

.NET Development

Site Classified