In my previous post I outlined a way of providing server-side user session state to a DHTML UI using native Java or .NET sessions. In this post I want to show another option: a web service-based solution.

As part of the WebDaptive AJAX framework, QAT offers a web service for both Java and .NET that mimics the main aspects of user sessions, including the generation of unique, hard-to-predict ids and customizable timeout of idle sessions. You can create and discard session objects, store, retrieve and delete key-value pairs via web service calls. The session id can be passed to other application components so they can access the session too.

The web service session offers some unique advantages that are hard to duplicate with a traditional session object: If you pass the session id in requests or use a well-known id, any webservice-enabled technology can use that session. Your UI could tell a .NET application to store data in the session and later call a CICS web service or maybe another .NET application running with a different context, which then could read that data straight from the same session. If you think this requirement sounds far-fetched, consider this: You have a CA Gen web application with an UI that meets 90% of your users’ needs. For the remaining 10% of functionality, you would really like to offer a richer and more dynamic UI like a spread-sheet-like grid, something that can only be offered by non-Gen code. Depending on the complexity of the task, you may easily end up with code that uses several separate Java or .NET session objects that cannot be shared. A web service-based session can bridge this gap.

Using the WebDaptive Communication client, calling the session service (or any other web service) is as simple as this:

Step 1 – Retrieve a new session id:
This is useful if you want the security of unique, hard-to-guess identifiers. Alternatively, you can skip this step and use a session id of your choice.

var url = "http://localhost/WDSessService/WDSessionService.asmx";
// create new WebDaptive Communication client
var wdc = new WDClient();
// whether the calls are asynchronous
var async = true;
// will hold the session id
var sessionId;

// retrieve new session id
wdc.invokeSOAP(url, "GetNewSessionID", "GetNewSessionIDResult",
  new WDRequestParameters(), async, function(result1, xml1, resultStatus1){
  	// callback functionality
  	sessionId = result1;
 });

Step 2 – Store data in the session:

// use the session id
// create a parameter object and add all call parameters
var pl = new WDRequestParameters();
pl.add("sID", sessionId);
pl.add("sKey", "KEY");
pl.add("sValue", "SAMPLE DATA");
wdc.invokeSOAP(url, "SetSessionString", "SetSessionStringResult",
  pl, async, function(result, xml, resultStatus){
    // callback handler functionality here
    sessionId = result;
});

Step 3 – Retrieve data from the session:

// use the session id
// create a parameter object and add all call parameters
var pl = new WDRequestParameters();
pl.add("sID", sessionId);
pl.add("sKey", "KEY");
wdc.invokeSOAP(url, "SetSessionString", "SetSessionStringResult",
  pl, async, function(result, xml, resultStatus){
    // callback handler functionality here
    alert("The value of 'KEY' is '" + result + "'");
});

In .NET or Java, you will need to use the mechanisms of your web service stack to call the session service. QAT also provides custom functions that enable access from within Gen applications. Of course, there is additional overhead involved if you use the session service from within Java or .NET compared to using their native session objects but this overhead may be well worth it if you need to share data across context boundaries.

Bottom line – the WebDaptive Session service offers a web service-based session solution that is very flexible and can even benefit server-side technologies with native session handling because of its ability to share data with other technologies.

- Anke

In my previous post I mentioned that there is no built-in mechanism for associating calls from a pure DHTML UI with user and session-specific state at the server. In this post I want to detail how to integrate with a .NET or Java session. Of course, the same principles can be applied to other web technologies like PHP etc.

If your session ids are sent as cookies, the integration is easy because the browser will automatically send those cookies back with every request to the same domain, even those for static content and the server calls the UI executes in the background. So attaching to the ASP.NET or Java Session can be as simple as calling a server page that uses a session. Important: Ajax calls via the XMLHttpRequest API will NOT set or remove cookies, so such a page would have to be loaded into the main window or at least an iframe. Also, it is good practice to mark session cookies as http-only which means they cannot be accessed directly from JavaScript.

If you don’t use cookies but encode session and authentication information in the URL, the problem becomes trickier – you will have to extract that information from the server page and add it manually to all request URL that require that context.

One thing to keep in mind is that the session will eventually time out (the details depend on your configuration). If your application does not regularly call server components that will use or at least automatically “touch” the session but needs to keep it alive in the background, you may have to add functionality that will periodically call the server to do just this.

Also, typically, web services do not have access to user sessions and will therefore not “touch” them nor be able to access the session data – they need to be made session-aware. In a .NET asmx web service, you can enable session access for a method by decorating it with [WebMethod(EnableSession=true)]:

using System.Web;
....
// decorate the method to indicate it should enable session handling
[WebMethod(EnableSession=true)]
public string AccessSession()
{
    // access the user session via System.Web.HttpContext.Current.Session
    if (HttpContext.Current.Session != null)
    {
        return HttpContext.Current.Session["SomeKey"] as string;
    }
    return "Session not found";
}

A Java example can be found here: http://www.ibm.com/developerworks/webservices/library/ws-tip-stateful.html.

If you are using session-enabled web services, the web service client is responsible for attaching the correct session id to the request – only if you use a JavaScript client and use cookies, this will probably happen automatically.

Overall, this is a fairly simple approach to enable user-specific session state at the server with a pure DHTML UI and works well if your UI communicates with a single server application.

In my next post, I will offer an alternative approach that doesn’t require the use of traditional server-side sessions.

-Anke