Develop Reference

WCF with legacy clients

I have been asked to replace a legacy "service" which processes XML requests (of an arbitrary format with no schema...) from multiple clients (Excel macros, C# apps) over Tibco EMS. I have no control over the clients.
I was hoping I could use WCF for this task but I don't think I can without a service contract. I have been toying with the idea of creating a WCF service and another console app service which would intercept and parse the existing XML requests and forward to the new WCF service (which new clients would use and existing clients could eventually migrate to).
However, this is adding complexity which could become a support and development headache. As such, I am tempted to build a console app based service which feels like a shame seeing as how much you get for free with WCF.
Has anyone else developed WCF apps for legacy non-REST, non-SOAP clients?

WCF client and server

I need multiple clients that talk to a WCF service. The WCF service also must be able to connect to any one of the clients also.
So - it sounds like the server and the clients need to have both a WCF server and client built into each one.
Is this correct or is there some way to do this?
I was looking at NetPeerTcpBinding, but that is obsolete. To be fair I'm not sure if that is a valid solution either.
Background:
I plan to have a Windows service installed on hundreds of machines in our network with a WCF service and a WCF client built in.
I will have one Windows service installed on a server with a WCF service and a client built in.
I will have a Windows Forms application
I will have a database
The clients on the network will connect to the service running on the server in order to insert some information on the database.
The user will use the Windows Forms application to connect to the Windows service on the server and this Windows service will connect to the relevant client on the factory floor (to allow remote browsing of files and folders).
Hence I believe the machines on the floor and the server both require a WCF cleint and service built in.

The reason people are recommending wsHttpDualBinding is because it is in itself a secure and interoperable binding that is designed for use with duplex service contracts that allows both services and clients to send and receive messages.
The type of communication mentioned 'duplex' has several variations. Half and Full are the simplest.
Half Duplex: Works like a walkie-talkie, one person may speak at any given time.
Full Duplex: Like a phone, any person may speak at any given time.
Each will introduce a benefit and a problem, they also provide ways to build this communication more effectively based upon your needs.
I'm slightly confused, but I'll attempt to clarify.
You have an assortment of approaches that may occur here, a Windows Communication Foundation (WCF) Service requires the following:
Address
Binding
Contract
Those are essentially the "ABC's" for WCF. The creation of those depicts a picture like this:
As you can see the Service will contain:
Host
Service
Client
The host houses the service which the client will consume so those service methods perform a desired task. An example representation:
As you see Client-1 is going through the Internet (HTTP, HTTPS, etc.) then will hit the Host, which will have the service perform those tasks.
Now Client-n is consuming the service locally, so it is talking over (TCP, etc.) as an example.
The easiest way to remember: One service can be consumed by however many clients require those methods to perform a task. You can create very complex models using a service-oriented architecture (SOA).
All WCF is, is a mean to connect your application to a host or
centralized location you may not have access to.
As you can see in the above image, the Client communicates through a Service to the Host. Which performs a series of task. WCF will talk over an array of protocols. Hopefully this will provide a better understanding of how WCF is structured.
There are a lot of tutorials and even post to get you started. Some excellent books such as "WCF Step by Step".
Essentially your looking for an asynchronous full duplex connection, or a synchronous full duplex service. As mentioned above, your task in essence is the point of a Service.
The question: How does this work best?
It will boil down to your design. There are limitations and structures that you will need to adhere to to truly optimize it for your goal.
Such obstacles may be:
Server Load
Communication Path
Security
Multiple Clients Altering UI / Same Data
Etc.
The list continues and continues. I'd really look up tutorials or a few books on WCF. Here are a few:
WCF Step by Step
WCF Multi-Tier Development
WCF Service Development
They will help you work with the service structure to adhere to your desired goal.
Remember the "ABCs" for the most success with WCF.

Use wsDualHttpBinding if you want your service communicate with your clients.
Read WS Dual HTTP.

You might want to try out creating a WCF service using netTcpBinding. It will work for your requirements. You can use the article How to: Use netTcpBinding with Windows Authentication and Transport Security in WCF Calling from Windows Forms as a start:
Also, there are many examples included within the WCF Samples package which you can use.

WCF Service And Windows Service

I have a WCF service which serves as a remote file/folder browser. We also plan on having a Windows Service that will serve as 3 functions.
Windows Service will start the WCF service so it can do its job (part of the same project)
Windows Service will Upload some data to an SQL server every few minutes based on a timer + many other methods like this
WCF will Receive a request to run a method as requested by an asp.net client via WCF and then ask the windows service to run a method and return a result to WCF and pass back the result to ASP.net.
Item 3 is the problem. How is a windows service supposed to talk to a WCF Service (and Vice-Versa) service that both run on the same machine and are essentially the same application running as one. is it over WCF again?
Possibly i am going about this all wrong. Hopefully someone may be able to help
thanks
Damo

WCF Services may be hosted within Windows Services. See http://msdn.microsoft.com/en-us/library/ms750530.aspx. The specific example they give is for a console application, but the same concept applies.
When self hosting, you can eiter specifiy a type that will be instantiated when a client connects to the service , or you pass the instance that your clients will use when they hit the service. In either case, you can instantiate the same class or access the instance passed to ServiceHost to call methods on the service, though they would not go through the WCF pipeline. The WCF Service class can get a reference to the Windows Service class and access methods on that to allow for callbacks to occur without another trip through the WCF stack.
Alternatively, if you do not wish to self-host or your application uses WCF specific calls in the service, you can create a wcf client in the service in the same way as you would on a desktop application. Simply add a service reference as normal and use callbacks to hop back to the Windows Service code.

The first answer is correct.
I'll suggest also consider the following: if you don't have the windows service to host that wcf service, then go on with exposing new one in there. There are other options as well, but those are going lower level, so WCF is the easies and safest option. The same time - its quite elegant solution.

Examples of long-polling in ASP.NET combined with WCF service monitoring?

We have a number of Windows services running in our system (built in C#). We use WCF to communicate with them and control them, since WCF offers very convenient communication with these processes.
Right now in our Windows GUI for managing, monitoring and troubleshooting the services, we simply register callbacks and receive notifications when a message is available from the service. Obviously this application is stateful and WCF provides the ability for the local delegate to be called when the maintained connection to the service indicates.
In our web application which users actually use, we'd like to use long-polling to have a status area on the web page (iframe, AJAX, whatever) which shows any issues which the services are reporting. We'd like to use a long-polling or other technique which minimizes actual polling on the network.
The problem we are running up against is that we need something to make the long-polling HTTP request against which will somehow always be running in IIS and which itself can be WCF-connected to our services and which can convert the event/delegate-based WCF response into a blocking-style long-poll response. It feels like a chicken-and-egg situation that some component in our system is always going to be in a loop, polling - and that's exactly what we are trying to avoid.
Does anyone have an example of doing this?

Well, if your services present with WCF, why not simply consume the WCF services with javsacript? Then you remove your IIS servers from the equation completely. if a user wants to see what the services are doing then they can retrieve the information directly from the service.
Here's a blog with someone showing how to do this:Call wcf service from Json

Most Compatible Inter-Process Communication protocol

I am working on an media application for which I would like to provide an external API library that would allow another application to communicate with mine an query status information. My application is written in C# and the API DLL will be the same. Initially my thought was to simply use WCF and Named Pipes since it would provide an extremely easy way to code up the whole interface.
However, I realized that doing this would pretty much preclude any other languages or platforms from communicating with the application if I ever wanted to make, for example, an android or Web remote for it.
So, what protocol could I use that would allow a fast and simple interface from within my C# code, but also allow APIs to be written in other platforms.
Basic requirements are:
Local and Remote communication
Low overhead
Procedure Calls
File transfer (to send media)
Pre-Existing C#, open source library would be nice.
I've looked at a lot of the options, used XML-RPC and JSON-RPC before, but would like to know what the community thinks is the best option.

I think using WCF it's the best way to do what you want. It will be simple in maintenance, cover all your requirements and easy to extend. Just don't restrict the access to your API only by net.pipe. I think you should use net.pipe, net.tcp and maybe basic http as primary bindings. I mean several endpoints for each service. So, a client app, no matter what language it is written, will be able to choose what binding to use to access your API server.
For example:
C# client app on the same machine - use net.pipe
PHP client app in web - use basic http
Java client app on another machine - use net.tcp
As an example:
http://www.kevingao.net/wcf-java-interop/java-client-and-wcf-server.html