Note
Access to this page requires authorization. You can try signing in or changing directories.
Access to this page requires authorization. You can try changing directories.
This section describes a conceptual model of possible data organization that an implementation maintains to participate in this protocol. The described organization is provided to facilitate the explanation of how the protocol behaves. This document does not mandate that implementations adhere to this model as long as their external behavior is consistent with that described in this document.
The abstract data model defines OOB Connector objects, Session Factory objects, and Session objects. When the underlying transport is triggered, an exchange is performed by peers that can result in new instances of these objects: each peer can create an OOB Connector object, one in the listener role and one in the connector role. If both sides have active Session Factory objects that are compatible, then each peer creates a Session object, one in the client role and one in the server role.
Each Session object references one OOB Connector object in order to provide connectivity options to higher-level protocols.
If there is only one peer with an active Session Factory object, but it specifies the L (Launch) flag in the Session Factory Service Activation message (section 2.2.12), then the other peer can create a Session Factory object on behalf of a soon-to-be-launched application. This provides for the ability to establish OOB connections at the same time as launching an application.
Note that the abstract interface notation (Public) indicates that the abstract data model element can be directly read or written from outside this protocol by higher-level protocols. For example, the Near Field Proximity: Sharing Protocol [MS-NFPS] uses members of the Session and OOB Connector objects to construct a socket for the purposes of sharing file(s).