Inter-component communication

The reason I call this post as inter-component communication is to differentiate with inter-process or inter-thread ones. ICC offers more flexibility and saves us from lots of implementation details (this does NOT mean not important! esp. if you want performance.). I am currently playing .Net 3.5 thus the pre-condition.

I have tried three ways of providing inter-component communication mechanisms last night as a catchup excercise on moving to .Net 3.5.

• Remoting, using FCL under System.Runtime.Remoting, via setup communication channels to allow communication cross AppDomains. Service provider and consumer could be located in same Processes or different ones over separated networkable machines. I have not had quantative measurement done but this approach gives me the fastest response. You could write all objects with functionalities you would like share in individual assembly as long as the class inheriting MarshalByRefObject. In the host app.config, you just need to set up the wellknown services in section and channels information. You could always set these up in the code - create channels and services (exposing the marshalled objects). On the client side, as long as you register the communication channels (either via .config or code), with the correct URL and type, you could GetObject from service provider side and use objects as they are local. In the latest implementation of this model, you don't need to worry about the implementation as proxy, formatter (binary or SOAP), dispatcher. You might want to use messaging to define your own version of message to contain the data passing between service provider and consumers.


• WCF, communication fundation has generate a lot of noise since the release. I wouldn't say that I am totally impressed when it comes down to performance but it certainly holds some water in the neat structure. Host WCF service provider could be either Web service host such as IIS or standard apps. WCF is to define a public available service interface, known as ServiceContract, and expose the implementation of the service via public service name (.svc file) and designated service endpoint address in section of web.config file. You can compile .svc file into two files manually using svcutil.exe as output.config (to be renamed into app.config in client apps) and client side proxy class, which offers the same OperationContract and DataContract defined in the server side. As long as the endpoint you specify in your code has been properly defined in your client app.config pointing to the correct host info and contract name, you can use the proxy just like service interface implementation on server side. To make life easier, you can add service reference in visual studio, which will achieve the similar effect, the only thing is you would not necessary what is the heck going on in the background. I guess that is the price we have to pay to be treated as dummies anyway. A WCF service transport protocols as TCP, UDP, MSMQ or SOAP. It could also use security protocol in the service bindings which is a real bonus, see here is a good article describing security issue in WCF! And if you are really interested, go write your own binding, channel and everything else. There are tons of references available. Service Configuration Editor is a good tool supplied by MS to configure the service.


• Webservice, using clases under System.Web.Services, we could expose the service via standard web service provider hosting in web servers such as IIS. Officially the bandwidth and all other performance will be bottlenecked by IIS but this is another topic out of the scope of this post. You can implement any services (inheriting System.Web.Services.WebService class) to be exposed, with [WebMethod] attribute tagging operations you want other people to access. .asmx has the similar markup content as .svc mentioned in WCF. Although this approach a lot of work will need to be done during deployment the web service part, there is not much for you to configure other than focus on implementing the service itself. However, the price you paid here is this is the slowest method, because you have given up many of your controls to web service host Scheduling. To use this service in client side, again you could either go with manual route using wsdl.exe to compile wsdl (.asmx file). This will give you the proxy class with exact the same name to be used in client side. Or you can go the lasy route adding service reference which will give you soap(ed)client as proxy.

One thing needs a bit clarification is that there are many ways to host the service provider in all of the amentioned three different approaches. Web service host such as IIS (do not confuse with name Webservice, if you could ;)), standard console or application host, Windows service host. Effectively, any application models which are capable of listening to client service request could become host. All these approaches could be used to implement P&S and multi-casting patterns one way or another by specifying either the contract attributes or hooking up to the same endpoint/url.