Is it possible to pass a delegate to a WCF remote object from the client and have the remote object execute the delegate?
I would guess not since a delgate is a function pointer for the client process.
My goal is to have an interface structure that I can "subscribe" to events from a client to the interface. I would pass a delgate from the client to the interface and I want the interface to be able to execute the event.
The idea is to have the ability for the interface to be loaded either the assembly or remotly and have the code work the same.
If I can't pass the delegate how can I implement an event structure?
not a "delegate" in C# per se, but in WCF you have duplex bindings to enable call back from the service side to the client side
http://msdn.microsoft.com/en-us/library/system.servicemodel.wsdualhttpbinding.aspx
I doubt you could come up with a cohesive way to pass a delegate from a C# client to a Java service implementation and have it properly executed......
WCF is not a strict .NET implementation and thus has to deal with interop issues. It cannot rely on the assumption that both ends of the conversation are in .NET - that's why you shouldn't throw around custom exceptions between server and client either (exceptions are a .NET construct) - you need to use SOAP faults instead (which are interoperable).
So I don't think what you want to do can be done with a delegate - you'll have to come up with another way to achieve your goal.
Marc
Related
I am using a web application as a client to invoke WCF methods using proxy.
For each request being made by client object, I need to populate few properties (declared inside request class)
Is it possible to hook a method, just before making the actual web service call.
I can't modify service code right now, Can WCF extensibility points could be leveraged in this case?
Thanks for your help.
If you want to change the properties of the method parameters, you can use an IParameterInspector to do that, since at that point you'll get an array with all parameters to be sent to the server.
If you need to change other parts of the request (such as transport or SOAP headers), an IClientMessageInspector may be the best way to go.
For more information on many extensibility points at the client side, you can check the blog series at http://blogs.msdn.com/b/carlosfigueira/archive/2011/03/14/wcf-extensibility.aspx.
I have a WCF service application (actually, it uses WCF Web API preview 5) that intercepts each request and extracts several header values passed from the client. The idea is that the 'interceptor' will extract these values and setup a ClientContext object that is then globally available within the application for the duration of the request. The server is stateless, so the context is per-call.
My problem is that the application uses IoC (Unity) for dependency injection so there is no use of singleton's, etc. Any class that needs to use the context receives it via DI.
So, how do I 'dynamically' create a new context object for each request and make sure that it is used by the container for the duration of that request? I also need to be sure that it is completely thread-safe in that each request is truly using the correct instance.
UPDATE
So I realize as I look into the suggestions below that part of my problem is encapsulation. The idea is that the interface used for the context (IClientContext) contains only read-only properties so that the rest of the application code doesn't have the ability to make changes. (And in a team development environment, if the code allows it, someone will inevitably do it.)
As a result, in my message handler that intercepts the request, I can get an instance of the type implementing the interface from the container but I can't make use of it. I still want to only expose a read-only interface to all other code but need a way to set the property values. Any ideas?
I'm considering implementing two interfaces, one that provides read-only access and one that allows me to initialize the instance. Or casting the resolved object to a type that allows me to set the values. Unfortunately, this isn't fool-proof either but unless someone has a better idea, it might be the best I can do.
Read Andrew Oakley's Blog on WCF specific lifetime managers. He creates a UnityOperationContextLifetimeManager:
we came up with the idea to build a Unity lifetime manager tied to
WCF's OperationContext. That way, our container objects would live
only for the lifetime of the request...
Configure your context class with that lifetime manager and then just resolve it. It should give you an "operation singleton".
Sounds like you need a Unity LifetimeManager. See this SO question or this MSDN article.
I am trying to write a running object table like WCF service (.NET 4.0) for providing access to some COM controls across processes. This service is accessed by both COM and .NET clients.
I chose WCF since it is recommended for inter-process communication and I also thought it would be good if I don't have to depend on ROT where I don't have much control over.
After solving several hiccups, I reached a road block. I don't know how to pass the COM control through the service and give it back to a client. The object never reaches the service. Though WCF is recommended for IPC, it does not provide out of the box support to pass COM objects. I also haven't found any solutions so far. May be WCF service is not the right approach to replace running object table. But I don't see a better way to do IPC.
Any suggestions on this?
A COM objref can't be passed around in a WCF message (well I guess you could create a MEOW interpreter on the receiver size and use CoMarshalInterThreadInterfaceInStream to pass the objref)
However, you could put the objects in the GIT and pass the GIT cookies around
But we can directly place COM object into the ROT by implementing IUNKNOWn interface
I'm wondering if there's any way to force a client to call a specific method on a duplex WCF service. My situation is this, my service implementation is going to keep a collection of subscribers. The problem with this approach is, what if the client doesn't call Subscribe()? I was thinking that in my client interface, I'd have a method called Subscribe, but that doesn't get me anywhere since the code to actually call the service can still be left out of the implementation. Is this possible?
Thanks!
Duplex WCF service uses WCF session so you can mark your Subscribe method with:
[OperationContract(IsInitiating=true)]
void Subscribe();
All other methods will have IsInitiating=false and because of that Subscribe method will have to be the first method called to start a new session. You can also have special method with IsTerminating=true to close the session.
Are DataContracts in WCF nothing more than DTOs? I was reading up about WCF and just had a couple of thoughts. It would be nice if some of the DataContract objects could have methods on them so that the client could do basic things with them before or after sending or retrieving back to the service.
To me this just doesn't seem possible or logical. I could be wrong, I learn new things everyday. So would the next best thing be to treat DataContracts as DTOs and provide libraries for the clients that would create real objects from the DTOs. Objects that would contain methods.
Any guidance would be really appreciated.
Not sure if I correctly understood your answer, so correct me if I'm wrong.
You can create a class library with your DataContracts classes and share the library between the client and server. In this way class marked [DataContract] will have methods (behavior) and [DataMember] fields/properties (state).
When you will pass such objects between client and server via WCF state will be persisted, but since class library is shared you will have methods on both sides.
DTOs that are decorated as DataContract classes are real objects. They can have methods in them, but the methods are not part of the serialization process.
The main time this will cause you issues is when:
you are relying on the generated proxy version of the DataContract objects (like when you have a Silverlight client calling a WCF service, or you are calling a third party service that you have no access to the code or its libraries). The generated proxy versions will not have the methods in them, just the DataMember properties. The way to get round that is to use objects from a shared library (as already mentioned by #Insomniac).
your properties in the DataContract objects are more than just a simple get/set operation, i.e. you may have included some logic to do other operations when a property value is set. In this case even the proxy generated version will not have that logic included. The ways to get round this is to either have the shared library, or have a partial class on the client side that extends the proxy generated class.
Sharing your classes between client and server projects is the way to go. Do not forget to check in your service reference that it tries to reuse types in referenced assemblies. That way, the service reference will not generate proxy classes for the shared objects.
WCF at its core is a message-based system: your client proxy catches the call to a method, wraps up the method and all its parameters into a serialized message, and send that across the network to the service to be processed.
So yes - in the end, all that goes from client to server in WCF is a serialized message - typically in XML format. You cannot serialize behavior or methods with this approach.