ATG’s implementation of sessions and session sharing provides considerable flexibility to Java clients. To understand how, you need to know a little about ATG Web services.
There are two limitations that affect the ATG implementation:
Each ATG Web service can expose only one method.
The JAX-RPC specification restricts a session to one or more calls per Web service endpoint. The Axis implementation obeys this restriction.
This means that each session is comprised of calls made to just one method on one Web service. Had ATG not extended the JAX-RPC concept of sessions to include session sharing, Web services would need to be entirely self-reliant: related Web services could not execute in succession.
Consider Web service security. Currently, the loginUser Web service determines the security role of the client and allows that to govern the content that the other Web services within that session are able to access. If there were no session sharing, there could be no way to provide security, given that each Web service can have only one method.
ATG provides the ability for Web services to share sessions by extending the Axis offering to include a org.apache.axis.cookies.CookieContainer class. A CookieContainer enables HTTP cookies to be shared across different Web service calls.
How Session Sharing Works
Here’s a high level explanation of how it works: You configure your Web service call to create, set, and use a CookieContainer. The resource you configure depends on the process, dynamic (client stub) or static (generated version of the call), you use to create a Web service call.
Once you instantiate the resource that refers to the CookieContainer, you assign the CookieContainer to it. When you execute a call, you create a CookieContainer instance that records cookies, such as the session cookie, coming from the server.
The first Web service called returns a response with a set-cookie header holding a new session ID because no active session IDs exist in the CookieContainer. That new session ID is then saved to the CookieContainer. For each subsequent call, the resource is again analyzed and when it’s determined that maintain sessions is true, the CookieContainer provides the active session ID to the cookie in the request.
In short, to make Web services able to share sessions, two things need to happen:
The Web service call must be configured to instantiate the
CookieContainerand permit session sharing. For instructions, see the sections for creating Web service calls.The Web service itself must support sessions. When you create custom Web services, you are given the option to allow sessions.
