Date: 01/05/08 (C Sharp)    Keywords: xml, web, microsoft, google

All,

Hi again. I posted the message two down from this one (unless someone posts while I'm typing this) about the frustrations of .NET WebServices and an OO structure with logical boundaries. I received a bunch of hearty recommendations for WCF, all ensuring me that it would provide all of the great stuff I love from .NET Remoting, but it would let me do it over HTTP(S).

I guess I should have been more specific.

I attempted a WCF implementation of a few of the methods in one of my services. While it certainly behaved better than a WebService implementation (e.g. passing/returning an Interface didn't crash it! *sigh*), I'm still not getting the behavior I want. So I'm going to be a little more specific.

My application's architecture necessitates a large number of application modules, most of which are communicating with most of each other, while what each of them has to say to any given module is fairly narrow in breadth (say, 1-3 possible remote transactions per module pair in the network -- that is, if there were three modules (and there are actually more than double that), let's call them A, B, and C, module A would host 1-3 types of requests from B and C; module B would host 1-3 types of requests from A and C; module C would host 1-3 types of requests from A and B. You get the picture.

Because of this property of my application's communication schema, I was (perhaps stupidly -- I am certainly willing to eschew this particular practice, but read on for what I want to still be able to do) using two generic structs to do the gruntwork for all communication methods: TCPResponse CallRemotingService(TCPAction thisAction)

Where TCPAction is simply:
public string Command;
public string ComputerName;
public object Data;
public Type DataType;

and TCPResponse is simply:
public bool Success;
public string ErrorMessage;
public Exception ErrorException;
public object Data;
public Type DataType;

By switching on TCPAction.Command and verifying TCPAction.DataType, I could cast TCPAction.Data into what I expected (TCPAction.DataType) and execute some private method on it that would return a TCPREsponse which I would return to the caller.

WCF complained that it didn't know anything about the classes (which contained other interfaces or still other classes as members) I was shoving into TCPACtion/Response.Data.

I understand that this approach has a number of unreasonable properties, so after seeing that it did not work with my attempt at WCF (which I suppose is my first question -- could it?), I moved on to the following.

As long as I can use the business objects I created for the purpose of shoving into TCPAction/Response.Data as parameters/returns for operation-specific methods of the WCF service, I am still happy, so I tried setting up a WCF service with a single method to see if my business objects would work in a more explicit form:

public string TestWCF(WSDataObject thisData) { }

Now, WSDataObject is a custom business class that has the following members (with appropriate get/set properties):

private ITransactionObject myITransactionObject;
private WSAuthenticationObject myWSAuthenticationObject;

While ITransactionObject contains native framework value types, WSAuthenticationObject goes even further with:

private IWSPreAuthentication myIWSPreAuthentication;
private string myServerAuthenticationKey;

Again, all of these classes have get/set properties for all of their members, which I've listed -- property names simply chop off "my."

The problem with this implementation was that WCF didn't know anything about some subset of the classes/interfaces "underneath" WSDataObject (ITransactionObject, WSAuthenticationObject, IWSPreAuthentication). The result was some kind of custom exception relating to type conversion.

FYI, I was using the Microsoft WCF "Getting Started" tutorial (modifying it to my needs) at this link.

I have to say I was disappointed that, just like WebServices, WCF requires a proxy class to mangle the public-facing portion of the object. However, I was too disheartened (and found far too little information from Google about "nested" classes like this) to "get my hands dirty" and see if I couldn't use the KnownTypeAttribute, or some other magic entirely, to make my business classes behave. Also, I was disappointed that WCF didn't (or I didn't make it) pass an entire object, private members and all. Is it possible to pass even methods?

That said, it looked like I was going to be pigeonholed into (some of) the same activities that WebServices would have forced me into -- basically writing a kind of serialization/deserialization layer in which I transmit and return only .NET native value types across the wire, but to and from which my applications can pass my real business objects. Which seems like a lot of unnecessary work.

I'm sure I didn't learn 10% about WCF in MS' tutorial -- does anyone have any better WCF resources that might be able to help with my problem? And/or has had experience with this particular problem in the past?

Any information/help is appreciated, as always. .NET Remoting works so well, but I just don't think it will fly in an application being marketed to customers, one component of which must be running from within their firewall. I wish there was some way to use .NET Remoting to make a request, grab the bytes, serialize them with XML, pass them to a really generic WebService with WCF, deserialize them, execute the transaction, and perform the reverse.

Source: http://community.livejournal.com/csharp/90948.html