Session Management for Web Services with SOAPHTTP

21-6 Developers Guide for Oracle Application Integration Architecture Foundation Pack

21.2.2.4 Disadvantages of Using Web Services with SOAPHTTP

XML format of message processing is slower; therefore, messages must be smaller or must leverage compression techniques. Inherently, HTTP is stateless retains no data between invocations; therefore, it needs an explicit login for every call, leading to performance overhead. The notion of atomic transactions with state management is not supported; workarounds are session state management, where a connection can be reused for more than one request as discussed in Section 21.2.3, Session Management for Web Services with SOAPHTTP .

21.2.2.5 Important Considerations for Using Web Services with SOAPHTTP

AIA requires that the developed and deployed Web services conform to published WS-I profiles to foster interoperability. ■ Leverage WS-Security to secure message exchanges using XML Encryption and XML Signature in SOAP; alternative is using secure HTTP HTTPS. ■ Leverage WS-Addressing to insert address in the SOAP header. ■ Leverage WS-ReliableMessaging to reliably deliver messages between distributed applications in the presence of software component, system, or network failures.

21.2.3 Session Management for Web Services with SOAPHTTP

To overcome the disadvantage of HTTP being stateless and unable to support atomic transactions, session management is needed. This section includes the following topics: ■ Section 21.2.3.1, Session Types ■ Section 21.2.3.2, SessionToken ■ Section 21.2.3.3, Session Pool Manager

21.2.3.1 Session Types

The three types of sessions are: ■ None A new session is opened for each request and then closed after a response is sent out. ■ Stateless A new session is opened for an initial request, and the session remains open for subsequent requests. Re-login occurs automatically transparent to the user if the session is closed. UsernameToken and PasswordText must be included as SOAP headers in the initial request to open a stateless session. ■ Stateful A new session is opened for an initial request, and the session remains open for subsequent requests. Re-login does not occur automatically if the session is closed. UsernameToken and PasswordText must be included as SOAP headers in the initial request to open a stateful session. For Stateless or Stateful modes, Web services are expected to return a SessionToken in the SOAP: HEADER. This depends on the application implementation. Establishing Resource Connectivity 21-7

21.2.3.2 SessionToken

A SessionToken is the encryption of the Session ID, UserToken, plus PasswordText. For each Stateless or Stateful call, an updated SessionToken is returned. This is as a safety measure against replay attacks. The process of updating the SessionToken does not close the session. Therefore, for the next call with the updated session token there is no re-login. The session remains open. The Session is closed when a call is posted with a Session Type set to None or a timeout occurs. After a second call you have two Session Tokens: the one returned on first call and the updated one from the second call. At this point either of these SessionTokens can be sent for a third call which returns a third SessionToken. Posting a call with Session Type set to None terminates the Session ID, so all these Session Tokens become invalid. URL and SOAP Header for the Siebel Application Examples Example 21–1 , Example 21–2 , and Example 21–3 provide the URL and SOAP header for the Siebel application examples. Example 21–1 URL for Calling the Siebel Application and Passing Login Information in the SOAP Header http:sdcp1952i028.corp.siebel.comeai_enustart.swe?SWEExtSource= SecureWebServiceSWEExtCmd=ExecuteWSSOAP=1 The SOAP header looks like this: Example 21–2 SOAP Header soapenv:Header UsernameToken xmlns=http:siebel.comwebservicesrreddyUsernameToken PasswordText xmlns=http:siebel.comwebservicesrreddyPasswordText SessionType xmlns=http:siebel.comwebservicesStatelessSessionTypesoapenv:Header The response looks like this: Example 21–3 Response to SOAP Header SOAP-ENV:Header siebel-header:SessionToken xmlns:siebel-header=http:siebel.comwebservices0f2cnvf0Ii5qsp-zk- SEyjl2p0JD-QdYLt1LYvARXQMZfAL9YL.THekJHI1cVjZbBGQckQN. cIfOGPKWKwUd6E0D4LD.VS.CKWsXw...siebel-header:SessionToken SOAP-ENV:Header

21.2.3.3 Session Pool Manager

For business integration flows that require a high number of concurrent request-response calls to applications, AIA recommends that you send and receive session token information rather than sending user credentials on each call. ■ The Session Pool Manager is a service that manages a pool of session tokens to be reused for subsequent requests. ■ The sessions are persisted either in memory or in a database. ■ The login credentials and URLs are configured by an administrator in the Session Pool Manager. 21-8 Developers Guide for Oracle Application Integration Architecture Foundation Pack The implementation of the Session Pool Manager is application-specific, taking into consideration the Web service framework implementations.

21.2.4 Error Handling for Web Services with SOAPHTTP