COM Component in WCF Service - wcf

I have a WCF service which is using a COM component. The clients of WCF service are making calls to set the properties in the COM object and then calling other methods on the object to retrieve results. I want to keep the data in the COM object safe from other clients. Client should only read the values that they have set. Can someone please advise whether this can be achieved in WCF? I tried playing around with InstanceMode and ConcurrencyMode but that doesn't help.

Related

How WCF client access nested object methods

My WCF Service has API to create 'Employee' object which needs to be send to client app. This object has set of methods and properties. Now, client need to access Methods in order to set it's fields (API has few validation logics to set it's fields). How WCF service will send an custom object where client must be able to access methods.
Here the design is, my wcf service will provide a 'template' (from api) to client where in client uses this object methods to set/update fields and will send back to service.
If the objects you send and receive have logic associated to them (not a very good idea), you will need the assembly where those objects are impemented on both sides, since the metadata exposed by wcf only shows fields, and not methods.
I'd split that in two, keep the datacontracts clean and if you need validation logic, you can either do it in the wcf service and return errors to the client, or in the client, but that will extra logic to the client that you'll need to provide.
I'd go with validation logic in the server, and clean datacotracts. It's the best way to ensure your services are interoperable.
Its not a good idea to return any objects from wcf service which contains any functions. Keep the data contract simple by having only fields (properties) , if any additional operation is needed make this available as part of operation contract.

Injecting Services In Deserialized Data Contract Proxies

I'm using Autofac with WCF integration in a project. I'm trying to figure out a way to lazy initialize data contract proxy collection properties to avoid transferring entire object graphs across the wire.
My current plan is to inject the WCF service in each deserialized data contract so they call the service, get the collection property data and initializes it.
My question is: Is there a way to tell Autofac to inject services in each data contract proxy deserialized at the client? Like some tweaking at the DataContractSerializer or something.
(No service locator, please...)
Thanks!
Unfortunately there is nothing like this available "out of the box" with Autofac. There is something similar in Autofac's MVC integration, but that's because MVC has a more specific integration point for that sort of thing (IActionInvoker).
You might be able to write a custom client-side behavior that intercepts certain known types (like collections) on the client and swaps in a lazy-initialized collection. There's a similar question here asking about how to swap the DataContractSerializer out at runtime. You could use a mechanism like that.

Using WCF Extensibility at Client Side

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.

How to write a WCF service similar to Running Object Table (ROT)?

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

How to pass Client Objects to WCF Service

I want to pass list of entitiy objects from Client to WCF Service,
but my WCF Service has no knowledge of the structure of these entity objects.
One way could be to pass them in an XML file.
What could be the other possible ways to pass such objects to WCF service?
Please guide.
Thank you!
Basically, you need to make your WCF service aware of the structure.
Remember: calling a WCF service is passing a message (WCF is serialising an object, stuffing it into an envelope, and sending it away; this is not a remote procedure call or some object remoting!) and you need to make this message so that the caller and the callee can serialize and deserialize it!
Create DataContracts for your object classes being sent back and forth - that's the easiest way.
You can also work with untyped messages in WCF - but it's a lot more manual work, and I'd strongly recommend investigating the DataContract route first!
See a blog post and the MSDN docs on how to deal with untyped messages in WCF.
Marc
I would recommend against this since WCF is contract based. I would map the entities onto DataContracts in the service and work with them from there. Let me know if I'm missing something..