3.1.4.1 BeginSession

Note Abstract data model objects that are referenced in this section are defined in section 3.1.1. SOAP fault processing is specified in section 3.1.4.4.

The server performs a BeginSession operation when it receives a DSML SOAP request message that contains a <BeginSession> header (section 2.2.2.1).

If the server is not capable of performing a BeginSession operation, and if the header contains a soap:mustUnderstand attribute equal to 1, then the server MUST generate a SOAP fault and MUST NOT process any DSML operations that are contained in the SOAP body of the message. Otherwise, if the header does not contain a soap:mustUnderstand attribute equal to 1, or if that attribute is not present, then the server MUST process the DSML operations as if the <BeginSession> header were not specified.

If the total number of SessionTableEntry objects in the SessionTable already equals MaxSessionsAllowed, the server MUST not perform the BeginSession operation and MUST generate a SOAP fault.

If the number of SessionTableEntry objects, which have the same value for SessionIp as the IP address of the client, already equals MaxSessionsAllowedPerIp, the server MUST not perform the <BeginSession> operation, and it MUST generate a SOAP fault.

To perform the BeginSession operation, the server MUST allocate a new SessionTableEntry, assigning a value to the SessionID object that is not used by any other SessionTableEntry in the SessionTable, record the IP address of the client in the <SessionIp> element, and record the time the DSML SOAP request is received in the <SessionLastAccessTime> element. A server MAY<7> try to minimize the chance of duplicating a SessionID value.

The server initializes the state of the Session object of the SessionTableEntry. The server MUST allocate a new idle session timer, assign it to the <SessionIdleTimer> element of the SessionTableEntry, and initialize the timer to 0. The timer MUST be set to expire after a duration specified by MaxSessionIdleTimeAllowed. The SessionTableEntry is then added to the SessionTable. If the server is unable to allocate or initialize a new entry in the SessionTable, then it MUST generate a SOAP fault, and it MUST NOT process any DSML operations that are contained in the SOAP body of the message.

After the SessionTableEntry has been initialized, the server MUST perform any DSML operations that are contained in the SOAP body of the request message by using the state stored in the SessionTableEntry. DSML operations have the form of a <dsml:batchRequest> element with zero or more child elements. The server SHOULD save any state changes in the Session object of the SessionTableEntry to correlate these operations with future operations.

Once the operations have successfully completed, or if there were no operations to perform, the server MUST generate a DSML response message [DSML2], with a <Session> header (section 2.2.2.2). The SessionID attribute of the <Session> header MUST be assigned the value of the SessionID object of the allocated SessionTableEntry.