As described in the Transport Binding Framework, the specifications for Features and Bindings MUST include descriptions of the distributed state necessary to utilize the functionality of the given Feature/Binding. The remainder of this document uses the conventions described here to represent this state as properties with formally typed values.
Properties are named with XML qualified names (QNames). An example might be "myNS:RetryCount", where the "myNS" prefix is mapped to a well-known namespace.
Property values are determined by the Schema type of the property, as defined in the specification which introduces the property. The property above might have a Schema type of "xsi:int", for example.
The following model is a logical architecture which describes how the properties we refer to in this section may propagate through the SOAP system and make themselves available for use in providing the various features which might be specified. It is intended purely as an informative model, and is not meant to imply any constraints on the actual structure or layering of any particular SOAP implementation. In particular, although the model talks about properties moving through Transport Message Exchange Contexts (TMECs), there is no requirement that an actual programming language concept of a TMEC must exist in a given implementation.
This model is used in describing the HTTP binding and the Single-Request-Response message exchange pattern later in this document.
Properties, Features and Property Containers
We have had some discussion of what constitutes a message and what is its relationship to properties and features. The view advanced here is that a message is an abstraction of the information that one SOAP Node wishes to exchange with another SOAP Node according to some message exchange pattern and with some specified set of features engaged for the message exchange. In this regard there is information that is essential to enable the exchange of the message that is not part of the message itself, sometime called message meta-data. The message itself and the various information items (that enable features) are abstracted as properties. Some properties are scoped per message exchange (for example the message itself) while others have more global significance within the SOAP Node. The value of some properties arise directly from the operation of the SOAP Node and the operation of message exchanges and features. Others arise in implementation specific ways from the local environment. In the diagram, Environment is some partition of the property space intended as a container for those properties that are NOT scoped on a per-message or per-message-exchange basis. It provides a view onto relevant properties that may be useful in the provision of various features eg,. userIds, passwords, key and certificates for authentication and privacy features. The view provided by the Environment may depend on a variety of local circumstances in system dependent ways - eg the visible UserID, password, key and certificate stores could be influenced by the OS user Id on whose behalf a message exchange is being executed. Such local matters are well outside the scope of the binding framework - however the nature of the abstract projection of such information as properties is not.
Similarly, Transport Message Exchange Context denotes a property container that carries all the properties that are particular to a specific instance of a message exchange, a message exchange being the thing that a message exchange pattern is a template for. Both Environment and Transport Exchange Message Context are property containers. The definition of the semantics of a given named property will describe its intended use and (abstract) value range (which may be open). The value of a property may also be named (by URI) or simply be a literal whose semantics are determined by the value of other properties - eg. the name of a state on a state transition table or graph may be scoped by the name of a message exchange pattern in use and the role that a given node is playing with respect to that message exchange pattern. Likewise the value that a role property may take is potentially scoped by the message exchange pattern in force.
Having abstracted messages that are the subject of a message exchange as parameters it should be noted that the value of such parameters abstracts an XML Infoset representing a SOAP Envelope and its contents and an abstraction of any other information structures (sometimes called Attachments) that are transferred along with the SOAP Envelope by the action of the message exchange.
There is a important point here in that we are dealing with properties that have both names and values. In many cases the property name is expected to be defined as part of the binding framework, whereas the semantics of the property value may be the subject of the definition of a particular message exchange pattern. Likewise, with features, some properties eg. MsgID, may be of utility to more than one feature (eg transaction support, message correlation). In some cases the definition of a TMEP or some other feature may introduce properties whose sole utility is with respect to that TMEP or feature such that the value space and semantics of the property are in some sense closed. However, in other cases the purpose of a property (it's coarse semantics) is defined, but its value space is open, and there may be more fine grained semantics associated with particular values - eg. the state of a particular message exchange.
We leave it open (at least for now) whether a property may appear multiple times within a given container and also within both a transport message exchange context and within the Environment container. The definition of a given property should indicate the significance of any multiple assertions and any precedence rules associated with simultaneous assertions in multiple containers.