Programming WCF Services

4.4
All Stack Overflow 20
This Year Stack Overflow 3
This Month Stack Overflow 3

Comments

by anonymous   2017-08-20

Firstly get yourself a copy of Programming WCF Services, if you don't already have one.

If the client is WinForm or WPF, you need to use [CallbackBehavior(UseSynchronizationContext = false)] as otherwise the client will not process the incoming message until the UI thread enters the message loop.

Firstly a “Duplex” channel in WCF is not truly Duplex! A message from

  • Client to server
  • Can block a message the server is waiting for from the client
  • (or the other way round)

As messages are only dispatched in order on a single WCF channel. A Duplex WCF channel does NOT give you two incoming message queues. The results coming back from a “TwoWay” call are just the same as the “call” as this level of the WCF stack. Once you get your head round this a lot of the problems become clearer to understand.

If the client is WinForm or WPF, you may need to use [CallbackBehavior(UseSynchronizationContext = false)] as otherwise the client will not process the incoming message until the UI thread enters the message loop.

Some rules I found to help avoid deadlocks. (Look at my WCF questions to see the pain I had!)

The sever must never call out to a client on the same connection as a call from the same client is in process on.

And/or

The client must never call back to the server on the same connection as is used for the “callbacks” while processing a call-back.

The next time I think I will just use two contracts (and hence TCP connections) one for the callback and other for all client->server requests. Or use my own polling system, as this gave me so much pain.

Sorry I don’t have time today to write an example. Anyway most examples work for what the example is trying to do, but break down in real life for some reason to do with your application.

The best web site I know for WCF examples is Juval Lowy’s web site.

Your may also find the questions I asked about WCF on Stack Overflow useful, as I was having the same kind of problems as you.

Also spending a day or two reading all the WCF questions and answers on Stack Overflow will give a good idea of the problems to avoid.

by anonymous   2017-08-20

If you are going to be developing with .NET, use WCF for your interprocess communication. WCF greatly simplifies development because the intricacies associated with a specific communication mechanism (e.g., sockets, pipes, etc.) are abstracted behind a unified programming model. Thus, it doesn't matter if you choose to use http, tcp, or named pipes for your transport mechanism, the programming model is the same.

I would highly recommend Juval Lowy's book Programming WCF Services for all things WCF. You can also visit his website, IDesign.net, for free WCF code samples.

For an overview of WCF, watch this free video at dnrTV. It covers the purpose of WCF and demonstrates WCF programming through some easy-to-follow examples.

If you have not already created your Windows service but plan to do so in C#, you can follow the step-by-step here.

by anonymous   2017-08-20

Edit: Reflecting More comments

A primer on WCF (such as What Is Windows Communication Foundation?) is a good place to start. WCF can use SOAP to implement the contracts way down deep. WCF also uses a variety of communication facilities within windows (and any custom ones you want to create) so talking across machines is built in.

The very essence of contract (IMO) implies that this is present on both sides of the communication. In a pure .net cases I've usually put the contract definitions in separate assemblies and share them. In other places I've used WSDL to be the main contract definition so that the client and service share definitions.

Edit: Answering comments

You can knock up simple examples of communication in WCF easilyy (provided you know the basics of comms on windows including firewalls etc). However doing something custom is not easy but there are many many resources on the web and books to help you get there.

The books i used:

Another question on SO with a set of resources is "WCF for the Totally Clueless"

by olle   2017-08-20

I don't know all answers but here are the ones I do know

  1. transport security means the communication is encrypted while the message is transported so it can't be read and or tampered with. Message security means the contents of the message itself is encrypted the transport however isn't necessarily. Message security can for instance be used with HTTP while transport security would require the use of HTTPS (or other bindings).
  2. IPrincipal principal = Thread.CurrentPrincipal;
  3. no answer
  4. Yes, although SSL itself uses certificates it's not the same. You can have the client send a certificate which is known to the service or which is signed by a trusted authority to that the service knows who the client is and whether to allow them to make the call or not. Using SSL will only ensure that third parties can't read the communication between the client and the services by intercepting the network packages.
  5. IPrincipal principal = Thread.CurrentPrincipal; principal.Identity.Name;
  6. No.
    • You have None, Transport, Message and Mixed security as your options however Transport security will require calling the endpoint using HTTPS since thats the secured version of the protocol
    • EDIT: Check out the discussion at this forum.

And the questions certainly aren't stupid.

P.S. I can recommend the book programming WCF services by Juval Lowy it's really in depth and comes with a really useful framework extending WCF/Simplifying certain things.

by anonymous   2017-08-20

Yes, scopes are the way to go. I'd like to recommend to you a great article Discover a New WCF with Discovery by Juval Lowy (the author of the Programming WCF services book). Here's the direct quote on using scopes:

Scopes are immensely useful in customizing discovery and in adding sophisticated behavior to your application, especially when writing a framework or administration tools. The classic use for scopes is to enable the client to distinguish among polymorphic services from different applications. However, this is somewhat of a rare occurrence. I find scopes handy when it comes to distinguishing among endpoint types in the same application.

For example, suppose for a given contract you have multiple implementations. You have the operational mode used in production and the simulation mode used in testing or diagnostics. Using scopes, the client can pick and choose the correct implementation type needed, and different clients never conflict with one another by consuming one another’s services. You can also have the same client pick up a different endpoint based on the context of the invocation. You could have endpoints for profiling, debugging, diagnostics, testing, instrumentation and so on.

This fits very well with the kind of problems you want to solve.

The article also contains good samples on declaring scopes both in configuration and in code. From service consumer's point of view I see two options: you can stuff all your desired scopes in FindCriteria instance that you pass to the DiscoveryClient.Find method if you want to filter your services on the discovery stage or you can get all services and check their scopes by hand.

Scope itself is an Uri object so it can put a lot of different information there using "key=value" notation. That should take care of "extending" the scope filtering and it doesn't limit you in terms of forward compability.