We Keep Coding

Designing a cross platform communication interface

I have a C# program running on a local system that needs to be able to do two things.
Asynchronously spin off remote jobs on remote systems running Windows, Linux, or Android.
Provide a way for those systems to send back the output(StdOut/StdErr) of those jobs back to the local system.
Previously I have used WCF when communicating with a remote windows system. I created a WCF server on the remote windows system and then my local machine can send commands and messages via that WCF channel. Things get more complicated when I try to do the same thing with Linux and Android.
I figure I could setup a local WCF service using REST, that way all 3 platforms can send messages to it using whatever convenient language (Most likely c++) via JSON REST. But what then is the best way to accomplish requirement #1?
Should I bother creating a REST server in C++ that runs on Linux and Android?
Can WCF even consume a C++ REST server that isn't written in .Net?
Would I be better off doing something simple with just TCP sockets?
Security is not an issue since this is used on a secure private network. I'm just looking for the easiest way to run remote commands/processes and receive response messages from those remote systems.

I use ZMQ and JSON for exactly this purpose: creating a custom private network topology that communicates using JSON messages over TCP (via ZMQ). Of course you could use any serialization format (I list some alternatives below).
I can't give you a definitive "this is what you should do" answer, because the question is fairly open-ended.
ZMQ: http://www.zeromq.org/
Really nice cross-platform abstracted socket library
Can use various transport protocols, including TCP
Sends messages as just plain byte arrays, leaving choice of serialization format up to you
Some serialization formats (in order of my personal preference):
JSON: http://www.json.org/
MessagePack: http://msgpack.org/
Exactly like JSON, but much more compact
No schemas
Cross-platform
Google Protocol Buffers: https://code.google.com/p/protobuf/
Uses schemas
Has bindings for C++, C#, Java, Python (at least)

This can really depend on your infrastructure and services you are using. If you are in the Amazon Web Services world you could use a Simple Queue Service (SQS) to receive messages. The remote systems could then poll the queue and run the jobs based on the messages pulled off the SQS queue.

.Net UI and Java Middle Ware

Hi We are in process of building new application which will have .Net UI and Java Middle Ware (Services) what. As I am fairly new to Java i would like to explore my options in terms of what are good practices so that .net uis can talk to java middle tiers. Java middle tier will eventually call to database...
Thanks

In addition to designing something that WCF understands, you might consider designing a ReSTful service using standard HTTP semantics.
For the Java side, you can use:
Jersey or
RESTlet
On the consumer side in .NET, you can use:
RestSharp or
HttpClient

Build your java middle ware with some sort of service that WCF can communicate with and you should be good to go
Here is a simple example
http://blogs.msdn.com/b/bursteg/archive/2008/07/19/how-to-call-a-java-ee-web-service-from-a-net-client.aspx

Any client that can send an HTTP request, REST or SOAP, can communicate with an HTTP listener or service, regardless of which language each one is implemented in. That's why HTTP based services have been such a winner, beating out Corba, RMI, COM, etc.
Simple and open win.

Interfacing with a localhost Windows service

I have a server I've written in C#. I need to interface with it so I can reconfigure things, purge caches, disconnect users, view a run console, etc. I can't shut the server down to do any of these things.
The two available options, interface with the server via a Tcp connection or use the Windows conventions (some WCF?).
Which is one more reliable or a "best practice":
Tcp connection and issue requests (only let admin/maintenance requests come from localhost of course) OR
use WCF to somehow access admin/maintenance methods inside the assembly?
Thanks in advance for the nearly always useful feedback.
EDIT: Can anyone offer any alternatives to WCF? The server itself is literally 65kb. It's tiny. And all I'm trying to do now is issue a few admin/maintenance commands to the server. I'm not trying to be the server, it's already done. I just want to interact with from a local host userland application.
EDIT 2: Problem solve: I'm just using a very very small Tcp client to issue requests to my already built out protocol. It's only a couple hundred lines and no bulky overkillish WCF had to be used. WCF just seems like...too too much. That said I need to learn it anyway (and am right now), thanks for the feedback!

I would definitely recommend using WCF. You define your endpoints and the contract, then using binding you configure how the communication is done (TCP, XML SOAP, Named pipes, message queues...).
This technology is pretty convenient: if you want to move for instance from TCP to HTTP SOAP, then you just update your configuration files and it's done; no code to update. Also it's totally interoperable as you can configure WCF to use HTTP (SOAP messages) and consume your services from any language/platform. You'll also find plenty of tutorials and examples on the web.
Here's a nice article about how to host WCF (TCP communication in the example, but you can use something else by modifying the configuration) within a Windows service

You can host a web service inside windows service. It would be TCP of course but without socket level programming on the client.
You can have then a restful interface on top of it. WCF always seemed too heavy to my liking

Two way communicating server/client architecture?

I'm trying to figure out which client/server technology (i.e. which part of the .NET Framework) to use for our new application. We will be writing the app in C# using .NET 3.5 SP1.
It is going to consist of a central Service that will be running as a "server", and several client applications spread out on several machines. The client application is a trayapp application that is going to receive notifications from the server, and will also send some information back to the server. The communication will therefore be two-way, and it needs to be fast. The server will need to know which client to send the notifications to.
I've been thinking that I could use Sockets. I've also come across the TcpListener and TcpClient classes. Another alternative is to do something with WCF, but I'm not sure how to do fast two-way communication with it.

WCF with NetTcp binding.
You should write a duplex service.

Without knowing how much data you're planning to exchange, it's difficult to make a precise recommendation. I use both WCF and TCP sockets to exchange data between my UI and my Windows service. Here are the considerations I made.
I use WCF for what I refer to as aperiodic data exchange. For example, when an event occurs in my Windows service, I communicate the event to the UI using WCF. Specifically for this event-based mechanism, I would highly recommend Juval Lowy's Publish-Subscribe Framework, which is available for free here. I also use WCF to communicate configuration changes from the UI to the Windows service. WCF is a perfect solution for this kind of data exchange for me.
When the user tells my Windows service to perform some action, a lot of data is sent from the Windows service to the UI. For this, I use TCP sockets. I know WCF has a streaming capability, and I strongly considered using it. I just did not have time to get comfortable with it before I had to make a decision, so I went with what I knew.
While I wish I was using WCF across the board for symmetry, i.e., for aperiodic and streaming data, this hybrid approach has served me well.
Hope this helps.

I would avoid sockets if I were you since there is a lot to know about them. Just look at all socket questions here at SO. It can be a nightmare if you do not know how to use them properly.
WCF will take care of all lower levels for you.

Communication (interprocess) between applications

I'm about to write a "server" application that is responsible to talk with external hardware. The application shall handle requests from clients. The clients send a message to the server, and if the server is busy with doing stuff with the hardware the new messages shall be stored in a queue that will be processed later.
The client shall also be able to cancel a request (if it is in the server's queue.). When the server application is finished with the hardware it shall be able to send the result back to the client that requested the job.
The server and client applications may or may not be on the same PC. All development is done in .NET (C#) 2005.
What is the best way to solve this communication problem?
MSMQ? SOAP? WCF? Remoting? Other?

Assuming you can use .NET 3.0 or greater then you probably want to WCF as the communications channel - the interface is consistent but it will allow you to use an appropriate transport mechanism depending on where the client and server are in relation to each other - so you can choose to use SOAP or MSMQ or a binary format or others as appropriate (and can roll your own if needed). It also covers the need for two way communication.
Queuing the messages at the server should probably be regarded as a separate problem - especially given the need to remove queued messages.

If clients and server processes are on the same machine, I think named pipes will give you the fastest raw byte transfer rate.
If the processes are across different machines, you'd need to use sockets-based approach.
Remoting is reportedly very slow. Based on the target OSes that you're planning to deploy the solution on, you could have options like WCF et al. However, the overhead of these protocols is something you may want to look at while deciding.

Remoting
If all development is done in .NET 2005, Remoting is the best way to go.

MSMQ would make some sense, though there are then security and deployment considerations. You could look at a service bus (such s NServiceBus or MassTransit) and there's also SQL Server Service Broker that could help (and can also be used by a service bus as the transport).
WCF would be another thing to look at, however that's really the across-network transport, so you'd probably still want the WCF calls to put a message on the server queue.
I don't recommend remoting, because it's hard to maintain a separation of concerns, and before you know it you're developing a really chatty interface without realising it. Remote calls are expensive in relative terms, so you should be trying to keep the messages fairly coarse-grained. WCF would be my recommendation. Not least because you can set it up to use a HTTP transport and avoid a lot of deployment and security headache.

The .NET Framework provides several ways to communicate with objects in different application domains, each designed with a particular level of expertise and flexibility in mind. For example, the growth of the Internet has made XML Web services an attractive method of communication, because XML Web services are built on the common infrastructure of the HTTP protocol and SOAP formatting, which uses XML. These are public standards, and can be used immediately with current Web infrastructures without worrying about additional proxy or firewall issues.
Not all applications should be built using some form of XML Web service, however, if only because of the performance issues related to using SOAP serialization over an HTTP connection.
Choosing Communication Options in .NET helps you decide which form of interobject communication you want for your application.