Learning Inter-application communication using WCF

[EagleKeeper]

Simplistic example

I have a tic-tac-toe game.
User in a console application enters the tile number (1-9)

Separate application gets the tile number, analyze options; makes a move and sends the move back to the user.

My intention is to have a method in the game side that the user can call with the use move.

The return from the the call is the game move and the game status.

I do not want to utilize shared memory - intent is to learn how to run code across systems.

--------------------------------------------

Issue

Without C#; I would have opened a socket connection between systems and pumped data across via a simple read/write socket.

Apparently, I now need to setup a WCF Contract/library that each application links to that allows a call/response to a method called.


Does the contract interface mirror the game application interface or does it have additional code.

Or are there simple linked in modules available that one can just add the interface handler the way you do between classes.

Using a textbook now; has 100+ lines of code that have to be added in support of a DLL. This is without figuring out how to interface to my little 10 line applications

 

[Markbnj]

Without C#; I would have opened a socket connection between systems and pumped data across via a simple read/write socket.

Well you can still do that - C# has pretty complete support for sockets, and you can always link C++ code. If your communication is 2-way you're going to end up working at this level anyway if you allow for the possibility of firewalls and NAT. But if the relationship is client-server then having the server implement a web service can make it much more robust and general purpose, since a client can almost always get through a firewall to an http endpoint on a standard port.

Apparently, I now need to setup a WCF Contract/library that each application links to that allows a call/response to a method called.

You don't _have_ to use data contracts to implement a WCF interface. It just makes serialization of objects both ways a lot easier (i.e. trivial). If all you're doing is passing simple parameters you can send them in a querystring or form post and get at them that way. Google for WCF Rest techniques and you'll see what I mean.

Does the contract interface mirror the game application interface or does it have additional code.

Usually the data contracts are interfaces that describe the properties of the objects you're exchanging. I'm not sure what you mean by "game application interface," but in general I would say that data contracts should be interfaces and contain only the properties being exchanged. That way you can create classes that implement the interfaces and add the appropriate behavior on the client and server side.

Or are there simple linked in modules available that one can just add the interface handler the way you do between classes. Using a textbook now; has 100+ lines of code that have to be added in support of a DLL. This is without figuring out how to interface to my little 10 line applications

WCF is a framework with a lot of rich functionality, so it might be overkill for what you're trying to do unless learning it is a goal. You can always use System.Web.HttpRequest and just roll your own.

 

[EagleKeeper]

The goal is learning how to work with WCF using a baseline that I am familiar with.

Reading over last couple of days have allowed me to figure out how to build the interface. VS did not give me s good host project ( that I could figure out). A System file was not being included even when asked for in source code. Manipulations allowed the host to be built.. Now I need to change over the client and add operational code to the interface. Slowly figuring it out. Never did find a good primer on this.

Your theories do help.