In this case "proxy" is a reference to the software design pattern. From Wikipedia:
A proxy, in its most general form, is a class functioning as an
interface to something else. The proxy could interface to anything: a
network connection, a large object in memory, a file, or some other
resource that is expensive or impossible to duplicate.
In the case of WCF the ChannelFactory<>.CreateChannel is creating a channel stack based on the configuration. Each channel provides an abstraction to the channel below it. For example a simplified channel stack might be:
- channel 1 serialize the .NET object into a SOAP message
- channel 2 Adds security information to the message
- channel 3 encode the message to be sent over TCP.
I think you understand all that.
Back to the use of “proxy”: Any channel in the stack is a proxy for the channel below it. That is to say no channel is the final destination. All channels are “an interface to something else”. However as you move down the channel stack the different channels are providing a different interface/abstraction (.NET object, SOAP Message, etc.) to the caller.
Again this discussion is meant to answer the question and intentionally simplified.
When you are writing client code, the interface that is most useful is the one that understands .NET objects. Knowing this the ChannelFactory returns the channel that’s at the top of the stack that has a .NET interface that matches your service contract. It would be valid to create a SOAP message as a string, walk down the channel stack (or create a custom stack), find the channel that accepts a raw SOAP message, label that a “proxy”, and call it directly.
The author used method called CreateChannel and named the identifier
proxy. So in WCF architecture Proxy is just a special high level
channel, it is not a stand alone architecture element?
Channel is an architectural element which implements the proxy software design pattern. All channels are proxies. When you are writing client code, the top level channel happens to be the most useful because it accepts .NET operation contracts.