Windows Communication Foundation Glossary for .NET Framework 4.5
The following terms are defined for Windows Communication Foundation documentation.
Terms
| Term | Definition |
|---|---|
| address | Specifies the location where messages are received. It is specified as a Uniform Resource Identifier (URI). The URI schema part names the transport mechanism to use to reach the address, such as HTTP and TCP. The hierarchical part of the URI contains a unique location whose format is dependent on the transport mechanism. |
| application endpoint | An endpoint exposed by the application and that corresponds to a service contract implemented by the application. |
| behavior | A behavior is a component that controls various run-time aspects of a service, an endpoint, a particular operation, or a client. Behaviors are grouped according to scope: common behaviors affect all endpoints globally, service behaviors affect only service-related aspects, endpoint behaviors affect only endpoint-related properties, and operation-level behaviors affect particular operations. |
| binding | Defines which communication protocols are used to communicate with WCF services. It is constructed of a set of components called binding elements that stack one on top of the other to create the communication infrastructure. See endpoint. |
| channel | A concrete implementation of a binding element. The binding represents the configuration, and the channel is the implementation associated with that configuration. Therefore, there is a channel associated with each binding element. Channels stack on top of each other to create the concrete implementation of the binding: the channel stack. |
| claims-based security | Allows authorized access to protected resources based on claims. |
| client application | A client application is a program that exchanges messages with one or more endpoints. The client application begins by creating an instance of a WCF client and calling methods of the WCF client. It is important to note that a single application can be both a client and a service. |
| coding | Allows the developer to retain strict control over all components of the service or client, and any settings done through the configuration can be inspected and if needed overridden by the code. Control of an application can be done either through coding, through configuration, or through a combination of both. |
| configuration | Configuration has the advantage of allowing someone other than the developer (for example, a network administrator) to set client and service parameters after the code is written and without having to recompile. Configuration not only enables you to set values like endpoint addresses, but also allows further control by enabling you to add endpoints, bindings, and behaviors. Control of an application can be done either through configuration, through coding, or through a combination of both. |
| contract | A contract is a specification of support for the particular type of contract that it is. A service contract, for example, is a specification for a group of operations. In WCF, contracts have a hierarchy that is mirrored in the description objects located in the System.ServiceModel.Description namespace. A service contract is the largest contract scope in WCF. Each service operation in a service contract has an operation contract, which specifies the messages -- including fault messages -- the operation can exchange, and in which direction. Each message in an operation has a message contract, a specification for the structure of the SOAP message envelope, and each message contract has a data contract, which specifies the data structures contained in the messages. |
| data contract | The data types a service uses must be described in metadata to enable others to interoperate with the service. The descriptions of the data types are known as the data contract, and the types can be used in any part of a message, for example, as parameters or return types. If the service is using only simple types, there is no need to explicitly use data contracts. |
| declarative application | An application that is described sufficiently to be created at run time without running imperative instructions. |
| endpoint | Consists of an address, a binding, and a contract used for communicating with a WCF service. |
| endpoint address | Enables you to create unique endpoint addresses for each endpoint in a service, or under certain conditions share an address across endpoints. |
| fault contract | A fault contract can be associated with a service operation to denote errors that can be returned to the caller. An operation can have zero or more faults associated with it. These errors are SOAP faults that are modeled as exceptions in the programming model. The exception is converted into a SOAP fault that can then be sent to the client. |
| hosting | A service must be hosted in some process. A host is an application that controls the lifetime of the service. Services can be self-hosted or managed by an existing hosting process. |
| hosting process | A hosting process is an application that is designed to host services. These include Internet Information Services (IIS), Windows Activation Services (WAS), and Windows Services. In these hosted scenarios, the host controls the lifetime of the service. For example, using IIS you can set up a virtual directory that contains the service assembly and configuration file. When a message is received, IIS starts the service and controls its lifetime. |
| initiating operation | An operation that is called as the first operation of a new session. Non-initiating operations can be called only after at least one initiating operation has been called. |
| instancing model | A service has an instancing model. There are three instancing models: "single," in which a single CLR object services all the clients; "per call," in which a new CLR object is created to handle each client call; and "per session," in which a set of CLR objects are created, one for each separate session. The choice of an instancing model depends on the application requirements and the expected usage pattern of the service. |
| message | A message is a self-contained unit of data that may consist of several parts, including a body and headers. |
| message contract | A message contract describes the format of a message. For example, it declares whether message elements should go in headers versus the body, what level of security should be applied to what elements of the message, and so on. |
| message security mode | Message security mode specifies that security is provided by implementing one or more of the security specifications. Each message contains the necessary mechanisms to provide security during its transit, and to enable the receivers to detect tampering and to decrypt the messages. In this sense, the security is encapsulated within every message, providing end-to-end security across multiple hops. Because security information becomes part of the message, it is also possible to include multiple kinds of credentials with the message (these are referred to as claims). This approach also has the advantage of enabling the message to travel securely over any transport, including multiple transports between its origin and destination. The disadvantage of this approach is the complexity of the cryptographic mechanisms employed, resulting in performance implications. |
| metadata | The metadata of a service describes the characteristics of the service that an external entity needs to understand to communicate with the service. Metadata can be consumed by the ServiceModel Metadata Utility Tool (Svcutil.exe) to generate a WCF client and accompanying configuration that a client application can use to interact with the service. The metadata exposed by the service includes XML schema documents, which define the data contract of the service, and WSDL documents, which describe the methods of the service. When enabled, metadata for the service is automatically generated by WCF by inspecting the service and its endpoints. To publish metadata from a service, you must explicitly enable the metadata behavior. |
| operation contract | An operation contract defines the parameters and return type of an operation. When creating an interface that defines the service contract, you signify an operation contract by applying the T:System.ServiceModel.OperationContractAttribute attribute to each method definition that is part of the contract. The operations can be modeled as taking a single message and returning a single message, or as taking a set of types and returning a type. In the latter case, the system determines the format for the messages that are exchanged for that operation. |
| projection | The representation of data on the wire. For example, a SOAP projection sends messages as SOAP envelopes and a Web projection sends messages in JSON format. |
| security | Security in WCF includes confidentiality (encryption of messages to prevent eavesdropping), integrity (the means for detection of tampering with the message), authentication (the means for validation of servers and clients), and authorization (the control of access to resources). These functions are provided by either leveraging existing security mechanisms, such as TLS over HTTP (also known as HTTPS), or by implementing one or more of the various WS-* security specifications. |
| self-hosted service | A self-hosted service is one that runs within a process application that the developer created. The developer controls its lifetime, sets the properties of the service, opens the service (which sets it into a listening mode), and closes the service. |
| service | A program or process that exposes one or more endpoints, with each endpoint exposing one or more operations. |
| service contract | The service contract ties together multiple related operations into a single functional unit. The contract can define service-level settings, such as the namespace of the service, a corresponding callback contract, and other such settings. In most cases, the contract is defined by creating an interface in the programming language of your choice and applying the T:System.ServiceModel.ServiceContractAttribute attribute to the interface. The actual service code results by implementing the interface. |
| service operation | A service operation is a procedure defined in a service's code that implements the functionality for an operation. This operation is exposed to clients as methods on a WCF client. The method may return a value, and may take an optional number of arguments, or take no arguments, and return no response. For example, an operation that functions as a "Hello" can be used as a notification of a client's presence and to begin a series of operations. |
| system-provided bindings | WCF includes a number of system-provided bindings. These are collections of binding elements that are optimized for specific scenarios. For example, the T:System.ServiceModel.WSHttpBinding is designed for interoperability with services that implement various WS-* specifications. These bindings save time by presenting only those options that can be correctly applied to the specific scenario. If one of these bindings does not meet your requirements, you can create your own custom binding. |
| terminating operation | An operation that is called as the last message in an existing session. In the default case, WCF recycles the service object and its context after the session with which the service was associated is closed. |
| transport security mode | Security can be provided by one of three modes: transport mode, message security mode, and transport with message credential mode. The transport security mode specifies that confidentiality, integrity, and authentication are provided by the transport layer mechanisms (such as HTTPS). When using a transport like HTTPS, this mode has the advantage of being efficient in its performance, and well understood because of its prevalence on the Internet. The disadvantage is that this kind of security is applied separately on each hop in the communication path, making the communication susceptible to a "man in the middle" attack. |
| transport with message credential security mode | This mode uses the transport layer to provide confidentiality, authentication, and integrity of the messages, while each of the messages can contain multiple credentials (claims) required by the receivers of the message. |
| type converter | A CLR type can be associated with one or more System.ComponentModel.TypeConverter derived types that enable converting instances of the CLR type to and from instances of other types. A type converter is associated with a CLR type using the System.ComponentModel.TypeConverterAttribute attribute. A TypeConverterAttribute can be specified directly on the CLR type or on a property. A type converter specified on a property always takes precedence over a type converter specified on the CLR type of the property. |
| WCF client | A WCF client is a client-application construct that exposes the service operations as methods (in the .NET Framework programming language of your choice, such as Visual Basic or Visual C#). Any application can host a WCF client, including an application that hosts a service. Therefore, it is possible to create a service that includes WCF clients of other services. A WCF client can be automatically generated by using the ServiceModel Metadata Utility Tool (Svcutil.exe) and pointing it at a running service that publishes metadata. |
| workflow services | A workflow service is a WCF service that is implemented as a workflow. The workflow contains messaging activities that send and/or receive WCF messages. |
| WS-* | Shorthand for the growing set of Web Service (WS) specifications, such as WS-Security, WS-ReliableMessaging, and so on, that are implemented in WCF. |
| XAML | eXtensible Application Markup Language |
| XAML schema | A markup schema used to define custom types in XAML. |