The Session Service allows an application to make contact with a potential service provider. The interface has two methods: Connect and Disconnect. Connect allows a client (usually in a mobile device) to make an initial connection to a service provider, establishing identity and authority to consume specific services. Many aspects of the client-server interaction may be negotiated via the Connect_Request_t type message structure. The response of the server is returned as a Connect_Response_t structure. On a successful request, a SessionID_t identifier is returned as an attribute to be used later as a shortcut to identify a client session.
The request schema allows for specification of a number of service parameters, including:
Contract Name - the name of the company, person, or other entity contracting for services.
Authority - the specific contractual details authorizing use of services under specific conditions.
Authentication - the information allowing the server to establish the identity of the requester. A password or X.509 certificate are examples.
Respond-to IP Address - when delivering to a MSP this is a list of IP addresses that may make requests.
User ID - when delivering through an MSP this is a unique identifier for the end user that has a private association with the mobile terminal or its owner.
Timeout - the requested length of a session in minutes. The server may respond with a smaller value.
QoS (Quality of Service) - an integer between 0 and 5 indicating the maximum MAGIC Services level of service requested. This may be changed to another value by the server. The level of service is roughly connected with the level of detail available in the services. Level 0 implies global services with most populated places, major roads, and other geographic features larger than a few hundred meters.
Priority - an integer between 0 and 7 indicating the maximum MAGIC Services priority of service requested. The lowest value is 0 and the highest value (most important) is 7. This may be changed to another value by the server. The server will attempt to order priority according to the priority value but this is not guaranteed.
Compression Method - a sequence of keys indicating requested compression methods in order of decreasing preference. Compression happens ahead of encryption.
Encryption Method - a sequence of keys indicating requested encryption methods in order of decreasing preference.
Private - information exchanged with service provider as a string in a format subject only to agreement between client and server.
Server Capabilities - this describes requested capabilities. If the list is empty then the response gives the full capabilities of the service provider. If this element is not present then the response also has no Server Capabilities element. The capabilities are described by giving the name of a service and function with the URI for each of the schemas accepted by the functions. For example:
Session.Connect(http://www.magicservicesforum.org/Registry/Schemas/Connect_Request_t/Base.xsd/ , http://www.magicservicesforum.org/Registry/Schemas/Connect_Response_t/Base.xsd/)
indicates that the service provider supports the standard session connect functionality.
The application developer would create the XML request document and call a function of the form:
Result_Code_t Connect (Connect_Request_t Request, Connect_Response_t Response)
where the Connect_Request_t and Connect_Response_t types are some kind of string or memory reference in most computing environments. The structure of these types is defined by the corresponding XML schemas.
The function call delivers the request to the service provider. If it is a synchronous function, the client blocks until the response document has been returned and unpacked by the proxy code. Asynchronous requests return immediately.
The result of computation returns in the response document, which follows the same general form as the request schema. All schemas can be found in the MAGIC Services Registry at http://www.MAGICServicesForum.org/Registry.
In the .NET proxy code generated by Visual Studio .NET, the connection would be through a pre-established web reference or a dynamic connection mechanism based on discovery of service providers through UDDI and examination of published WSDL files. The services for all MSP 2.0 providers are identical, using the document-style SOAP binding.