tags:

views:

53

answers:

2

Coming from a Java background, this is the way I'm thinking:

The server provides an object to the client. This object should be able to execute on the server.

Server:

private string _S = "A";

public interface IFoo { void Bar(); }

private class Foo : IFoo {
    void Bar() { _S = "B";}
}

public IFoo GetFoo() { return new Foo(); }

Client:

IFoo foo = serverChannel.GetFoo();
foo.Bar();

Is this possible? Or is my understanding wrong and this is not how it works in WCF? What would be a better design?

+3  A: 

No, I don't think that'll work. You see: WCF is not some kind of a remoting, remote-object, or remote-procedure call mechamism.

WCF at its core is a messaging infrastructure. Your client make a call to a method on a client-side proxy; the WCF runtime on the client captures the input parameters and the method name and a few more bits and pieces, serializes them into a message (either text or binary), and send that message across the wire (using whatever transport you like). The server does the same thing in reverse, deserializes the message, instantiantes a service class, executes a method on that class, and packages the return values back into a serialized message.

But there's really no connection or remoting link between client. Anything that goes between the two has to be serializable - into XML text at its core. You can pass around concrete classes and so on - but you cannot pass around interface, object references etc.

marc_s
Thought so. Is there a way to still create the behavior I mentioned? I know it works in Java, so maybe it is possible in .NET as well...
mafutrct
Sort of. You can fiddle with instance management on the server side so that messages all go to a single instance of a service object.
Cheeso
I would think it might be possible to have the object returned back to the client contain methods that make calls back to a server (asynchronously or not). The server in this case would then behave as a factory or sorts. I haven't tried this, but it sounds plausible? What do you think marc_s?
j0rd4n
@j0rd4n: no, you can't do that. WCF specifically enforces a "data only, no behavior" policy. All you can return back is data - string, ints, etc. - which might be used to somehow make a decision as to what method to call next - but you cannot pass back an executable object, or something like that, and call a method on it. It just doesn't work that way.
marc_s
@marc_s: Yeah, that makes sense. Thanks.
j0rd4n
A: 

No - you cannot send objects around. As marc_s pointed out, WCF is a message-oriented communications framework.

But, you do have different instancing options.

By default, Windows Communication Foundation instantiates services on a per-call basis: a service instance, a common language runtime (CLR) object, exists only while a client call is in progress. Every client request gets a new dedicated service instance. This is something like Stateless Session Beans in J2EE.

Another option is session-based activation, which is something like Stateful Session Beans in J2EE. Using this approach, when the client creates a new proxy to a service configured as session-aware, WCF activates a new service instance and attaches it to the session. Every message sent by the client over that proxy will go to the same instance on the server side.

This activation behavior is selectable with the ServiceContract attribute.

Juval Lowy has written a good article on instantiation options in WCF.

Within these instancing options, you may find something that works for you.

Cheeso
Yes, but I don't understand how this helps to solve the issue I explained?
mafutrct