Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus

Category: Programming
Author: Juval Lowy
All Stack Overflow 19
This Month Stack Overflow 3


by anonymous   2019-07-21

a) For the "if": sure, why not? For the "how": Write different modules that deploy your services to IIS or Windows Services or Console Hosts and let the user choose which one to run.

b) One Service per host but multiple endpoints with different bindings are possible.

c) In process means that they start when you start your application? Then I would go for the bootstrapper.

d) There is nothing simple about configuring WCF via app.config. The tooling in Visual Studio is puny and the number of knobs and dials is legion. Using code for configuration at least gives you Intellisense support.

e) I don't think that this is a very common combination so I would not bet that there is any literature out there. But for any questions regarding WCF I would recommend reading Programming WCF Services by Juval Lowy. I think the code samples also contain a WinFormsHost for WCF service which might be another option for your "where do I host services" problem.

by anonymous   2019-07-21

Programming WCF Services: Mastering WCF and the Azure AppFabric Service Bus

Or you can read the MCTS Self-Paced Training Kit (Exam 70-503), it is pretty much the same

by anonymous   2019-07-21

You need to understand SynchronizationContext concept, especially in the context of the WCF. I strongly recommend to read an excellent Programming WCF Services book, where it is described in details. But generally speaking, you can create your own custom SynchronizationContext that creates thread affinity for service calls. There is an example of it in the above mentioned book, but you can read about it also from the same author on MSDN, section Thread Affinity Synchronization Context, which is an example of exactly what you need.

by anonymous   2018-08-01
That brings up an interesting point - you `shouldn't be using NetTcpBinding with non-Windows platforms`. NetTcpBinding should only be used on a Windows LAN with Windows clients on both ends.
by anonymous   2017-12-18
That's very odd. I just checked with what is essentially the _[WCF Bible]( and your snippet matches Mr Lowy's. _"If you like to use username and password credentials, simply configure the binding accordingly: (snippet matching yours)"_ Unless they changed something post .NET 4? The only thing of course is that you must set `proxy.ClientCredentials.UserName = ....`. Are you doing that?
by anonymous   2017-08-20

First off, finding the "sweet spot" in the number of services is difficult for sure. Too many services, and your integration costs suffer, too few, and your implementation costs suffer. You have to find a good balance.

My advice to you is to follow Juval Lowy's methodology in that you should break down your services by areas of volatility, or areas of change. This will give you your granularity level. You should also read his WCF book if you can.

As for the performance, WCF will inherently support many thousands of calls per second depending on your use cases and hardware. Services calling services is not a problem. The platform will support it if you do your part. For example, use the right binding for the right scenario (named pipes to call services on the same machine and TCP to call services across machine where possible). You should also implement a vertical slice of the application and do performance testing before building the rest of the application. This will verify your architecture.

by anonymous   2017-08-20

That's a very very broad question.

WCF provides a lot more security by providing a lot more capabilities and options out of the box: it supports not only transport security (using SSL and https to secure your link, like ASMX) but also supports message encryption, and messages are by default encrypted and digitally signed.

This topic Bindings and Security on MSDN might be a good starting point - it explains the various security-related features of each binding. The topic Programming WCF Security goes into more details, and the ultimate "one-stop site" for WCF security is the WCF Security Guidance site on Codeplex created and maintained by the Patterns & Practices group at Microsoft.

As for choosing the right binding - I would recommend the decision flowchart that Juval Lowy presents in his excellent book Programming WCF Services (for intermediate to advanced developers).

by anonymous   2017-08-20

My WCF service instance context is PerSession, but ideally speaking we have both the client and service running in the same desktop (for now) so I am planning to inject the same service instance for each new session using autofac container

Generally you want to avoid sharing a WCF client proxy because if it faults it becomes difficult to push (or in your case reinject) a new WCF to those parts of the code sharing the proxy. It is better to create a proxy per actor.

Now am not changing the InstanceContext attribute on the service implementation because in future I might deploy the same service in a different hosting environment where I would like to have a new service object instance for each session

I think there may be some confusion here. The InstanceContext.PerSession means that a server instance is created per WCF client proxy. That means one service instance each time you new MyClientProxy() even if you share it with 10 other objects being injected with the proxy singleton. This is irrespective of how you host it.

Like mentioned earlier the client is a long running desktop application and I have read that it is a good practise to Open and Close the proxy for each call

Incorrect. For a PerSession service that is very expensive. There is measurable cost in establishing the link to the service not to mention the overhead of creating the factories. PerSession services are per-session for a reason, it implies that the service is to maintain state between calls. For example in my PerSession services, I like to establish an expensive DB connection in the constructor that can then be utilised very quickly in later service calls. Opening/closing in this example essentially means that a new service instance is created together with a new DB connection. Slow!

Plus sharing a client proxy that is injected elsewhere sort of defeats the purpose of an injected proxy anyway. Not to mention closing it in one thread will cause a potential fault in another thread. Again note that I dislike the idea of shared proxies.

Another argument is that I am planning to inject the same instance for each session in this environment, so Open & Close for each service call shouldn't matter ?

Yes, like I said if you are going to inject then you should not call open/close. Then again you should not share in a multi-threaded environment.

So which approach should I take

Follow these guidelines

  1. Singleton? PerCall? PerSession? That entirely depends on the nature of your service. Does it share state between method calls? Make it PerSession otherwise you could use PerCall. Don't want to create a new service instance more than once and you want to optionally share globals/singletons between method calls? Make it a Singleton

  2. Rather than inject a shared concrete instance of the WCF client proxy, instead inject a mechanism (a factory) that when called allows each recipient to create their own WCF client proxy when required.

  3. Do not call open/close after each call, that will hurt performance regardless of service instance mode. Even if your service is essentially compute only, repeated open/close for each method call on a Singleton service is still slow due to the start-up costs of the client proxy

  4. Dispose the client proxy ASAP when no longer required. PerSession service instances remain on the server eating up valuable resources throughout the lifetime of the client proxy or until timeout (whichever occurs sooner).

  5. If your service is localmachine, then you consider the NetNamedPipeBinding for it runs in Kernel mode; does not use the Network Redirector and is faster than TCP. Later when you deploy a remote service, add the TCP binding

I recommend this awesome WCF tome

enter image description here