c# - Different forms of the WCF service contract interface -

it appears can freely switch between following 3 different versions of same wcf contract interface api, without breaking clients:

[servicecontract] interface iservice {     // either synchronous     // [operationcontract]     // int somemethod(int arg);      // or tap     [operationcontract]     task<int> somemethodasync(int arg);      // or apm     // [operationcontract(asyncpattern = true)]     // iasyncresult beginsomemethod(int arg, asynccallback callback, object state);     // int endsomemethod(iasyncresult ar); } 

the existing test client app keeps working without recompiling or touching. if recompile service , re-import reference client app, wsdl definition remains same, 1:1.

my questions:

• is legit behavior can rely on? documented anywhere?

the idea convert set of synchronous somemethod-style methods tap somemethodasync-style methods, use async/await in implementation , improve wcf service scalability, without breaking existing clients.

also, there have been known woes wcf service scaling under .net 3.5 , .net 4.0. documented in mskb article "wcf service may scale under load" , codeproject article "tweaking wcf build highly scalable async rest api". basically, wasn't enough implement service contract apis naturally asynchronous, wcf runtime still blocking request thread.

• does know if problem has been fixed .net 4.5.x, out-of-the-box? or additional tweaks still required?

wcf operations can defined using either synchronous, eap or (as of .net 4.5) tap. msdn:

clients can offer developer programming model choose, long underlying message exchange pattern observed. so, too, can services implement operations in manner, long specified message pattern observed.

you can have 3 patterns in single contract interface, , relate same message.

on wire, there's no difference how execute operations. wsdl (which wcf builds each endpoint's abc - address, binding , contract) doesn't contain information. generated operation descriptions.

if @ operationdescription class, used in contractdescription, you'll see each operation has these properties: syncmethod, beginmethod, endmethod , taskmethod. when creating description, wcf combine methods according operation's name single operation. if there's mismatch between operations same name in different patterns (e.g. different parameters) wcf throw exception detailing what's wrong. wcf automatically assumes (optional) "async" suffix task-based methods, , begin/end prefix apm.

the client , server side unrelated in sense. utility generates proxy classes wsdl (svcutil), can build proxies execution pattern. doesn't have wcf service.

on server side, if more 1 pattern implemented, wcf use one in following order of precedence: task, sync , apm. documented somewhere in msdn, can't find right now. can @ reference source here.

in conclusion, can safely change server implementation long don't modify message operation represents.

regarding scaling (should different question imo)

• wcf's throttling default values have been updated in .net 4.5 more reasonable values , processor-dependent (see here).
• there's no change in regards thread-pool issue. problem stems initial size of completion port thread-pool, set 4 times amount of logical processors. can use threadpool.setminthreads increase amount factor (see this post). setting beneficial on client side.

if use async on server side (when calling other services, database, etc.), threading situation improve dramatically because won't wasting thread-pool threads waiting io complete.

the best thing in these situations lot of benchmarking.