Session Management

Session management is a concept that has been studied and commented upon by technology researchers for a very long time. Think about the first computers that people used. They used a time sharing system to access a large computer (the host) and allow each person to run their computation jobs independent of each other, and yet share the computing system so that an organization only needed a single computer (costing millions of dollars in many cases) to attempt to meet the computing needs of everyone in that organization. Session management is especially critical in a time sharing situation. If you are using a time share system, you don't want your work to be confused with someone else's. You want the system to recognize you and keep a managed dialog open from the moment you start sending data to the computer to the moment computation results are sent back to you. Well... that is called a session in many computer use situations.

You may have heard of Linux which is a popular operating system you can obtain for free and run your own personal computer which often you do not need to time share with other people. But, you might want to perform mulitple tasks at once (I sure do all the time on my computer). Linux is an open source modification of UNIX which runs many large host computers shared by many people in many organizations. UNIX and Linux created a popular session management system called X Windows. A full description of Session Management under X Window-based systems is available on the Wikipedia X session manager page.

Well, session management is a particularly useful concept with Web browser use. Web browsers keep a session manager locally so that you, the browser user, can save all open pages and settings and restore them at a later date. To help recover from a system or application crash, pages and settings can also be restored upon the next launch of the Web browser software. All modern Web browsers support advanced session management either as part of their core software or, as is the case with Firefox and Safari, support session management through third-party plugins or extensions (which lets everyone compete for creating the best session management services for their browser. Much of Web browser session management is managed through the application of cookies which you may already know about from other RISD Web design and development courses. To review the methods used to accomplish cookies, please see Wikipedia's document entitled HTTP cookie.

The point here is that session management is a concept that relates to many computing scenarios, not just the primary concern of our focus: maintaining a session between Web-enabling and Web-enabled devices. Keep the bigger picture in mind as you take a look at Web session management.

Web server session management

The Hypertext Transfer Protocol (HTTP) is stateless (meaning the state of the system is not stored nor maintained after use): a client computer running a Web browser must establish a new Transmission Control Protocol (TCP) network connection to the Web server with each new HTTP GET or POST request (and each image shown on the page, since an external file to that page, is a separate HTTP session!). The Web server, therefore, cannot rely on an established TCP network connection for longer than a single HTTP GET or POST operation. Session management is the technique used by a Web developer to make the stateless HTTP protocol support a session so that it appears as if you are on the Web using your session the whole time you perform a transaction. We want an established and reliable session for many reasons: For example, once a user has authenticated herself to the Web server, her next HTTP request (GET or POST) should not cause the Web server to ask her for her account and password again.

The session information is stored on a Web server using a session identifier (session ID) generated as a result of the first (or in some cases, the first authenticated) request from the end user running a Web browser. The "storage" of session IDs and the associated session data (user name, account number, etc.) on the Web server is accomplished using a variety of techniques. It can be maintained in the server's computer memory, stored as a file in the file system, or maintained in a more sophisticated database (which makes it available more readily to quick evaluation of session processing metrics - to see if sessions are being maintained well enough to keep the users happy).

In situations where multiple Web servers must share knowledge of session state (as is typical in a cluster environment — see computer cluster if you are interested) session information must be shared between the cluster nodes that are running Web server software. Methods for sharing session state between nodes in a cluster include: multicasting session information to member nodes (see JGroups for one example of this technique), sharing session information with a partner node (using any of a variety of methods of shared memory), sharing session information between nodes using network sockets, storing session information on a shared file system such as the network file system or the global file system, or storing the session information outside the cluster in a database.

If session information is considered transient (contains volatile data that is not required for non-repudiation of transactions) and doesn't contain data that is subject to compliance auditing (for example, personal customer information or health records - see the Health Insurance Portability and Accountability Act and the Sarbanes-Oxley Act for examples of two laws that necessitate compliance auditing) then any method of storing session information can be used. However, if session information is subject to audit compliance, consideration should be given to the method used for session storage, replication, and clustering.

I often code my own session management into important applications I write on the Web. I use many popular service oriented architectures such as the Simple Object Access Protocol (SOAP) which lets me construct messages with Extensible Markup Language (XML) that can be used by consumer applications to force Web servers to create and maintain sessions until I release them myself in code. I also write a lot of Remote Procedure Calls in many different languages (also using XML to carry the messages between servers). But, I admit that there are many new session management coding services available for me to use. I am just a creature of habit using what I use - you should do a good review of emerging session management platforms if you are going to compete on the Web with Web services. A Web service is a process on a Web server that you can access to do one specific task (and thus can be strung together elegantly to do some very amazing tasks - or so that is the vision). By providing session services to Web services, you can keep your session open while you do hundreds of Web services within one session (and yet, each software developer can break their services into simple pieces that others can use - think of a simple service that provides you the zip code of a town based on its name as a good representative example). You often can take advantage of a Web service from within your own Web transactions. You just need to know how to find them (for example, by using a Web services directory).

Bottom line is that session management provides an application the opportunity to remember everything that has been done for as long as a transaction needs to know about previous activities. If I am purchasing stuff on the Web (and I note most of you wrote me that you do that often), I want the session to remember all items I have put into my shopping cart as a single session and then take me through the check out process reliably so I just pay with one credit card transaction and know my session is secure as a single event on the Web. Computer scientists refer to the word atomic often as a term to describe something that needs to be reliably treated as a single unit (like the most basic of database transactions that are so often described as atomic) but can be used to build bigger things - just like atoms build molecules which build cool things like DNA, oxygen, water, etc.

The Presentation Layer

The presentation layer is the sixth level of the seven layer OSI model. It responds to service requests from the application layer (next week's focus) and issues service requests to the session layer (the layer that is responsible for session management that we discuss above).

The Presentation Layer is responsible for the delivery and formatting of information to the application layer for further processing or display. It relieves the application layer of concern regarding syntactical differences in data representation within the end-usersystems. Examples of data presentation services within Web architecture are often very specific in the tasks they perform (and thus laden with acronyms). For example, one example of a presentation service would be the conversion of an EBCDIC-coded text file to an ASCII-coded file. We must give our respect to the ASCII standard - it was created in a time years ago when making standards was not the known cultural process that it is today. So many government, industrial, and educational organizations had to come together to work on it for the benefit of the masses. Then again, the necessities of communications during World War II provided the urgency that got people listening to each other (and the government that demanded standardization across the Navy, Army, Coast Guard, etc.).

The Presentation Layer is the first one where people start to care about what they are sending at a more advanced level than just a bunch of ones and zeros. This layer deals with issues like how strings are represented - whether they use the so-called Pascal method (an integer count length field followed by the specified amount of bytes desired for the string of text characters) or the C/C++ method (which uses a null-terminated String standard, e.g. thisisastring\0, whereby a true byte of all 0s - defined as null by the ASCII and other data presentation standards - end every string (a lot of extra 0s for a text document, for sure). The idea is that the application layer should be able to point at the data to be moved from point A to point B on the Web, and the Presentation Layer deals with the rest of the details to make it go there in the format expected.

Encryption (the intelligent garbling of data so that it can be transmitted and ungarbled on the other end of a communications channel securely) is typically done at the presentation layer too, although it can be done at the Application, Session, Transport, or Network Layer as well - each having its own advantages and disadvantages. Another presentation layer responsibility is in managing the data's representative structure, which is normally standardized at this level, often by using the eXtensible Markup Language (XML) - a simple thing to say here, but with huge ramifications in terms of the productivity gains given to the Web and Web users everywhere - if you don't know XML, you should but not so much in the scope of this course. As well as simple pieces of data, like strings, more complicated data organizations are standardized in this layer. Two common examples are the objects referred to in object-oriented programming methods, and the way that streaming video is transmitted in a standard fashion.

The JavaScript Object Notation (JSON) specification has risen to top prominence in terms of protocols used for encoding data at the presentation layer. JSON files are compact compared to other markup approaches that attempt to convey the significance of a data component with its value. Notice the clear, simple, flowchart provided in the link above.

The syntax, and rules associated with JSON, are straight-forward and many web services are available that will take any JavaScript object being used in scripting code and codify it as a JSON file (so imagine storing the current state of a video game as a JSON file so that, when you return to play later, the game continues for your player persona in exactly the same state where your player persona left off). The popularity of JSON, which grew out of the syntax for the Real Simple Syndication protocol, has taken a but of the lustre out of my enthusiasm for XML — and yet XML includes some very sophisticated services that critical communications take advantage of (those that might have life threatening ramifications, for example).

XML has been a grand slam home run for humanity (my opinion). XML lets us take data and then structure it so that sending and storing applications can know a bit (or with a brilliant job of implementation, a lot) about the structure of the data. Much data has important structure - for example, chemical information passed in some manufacturing process (like concrete production) or a medical application (pharmaceutical drug production). Video games have data with critially important structure - game data needs to understand the concept of a player and a score as specific game-relevant standards. With XML, a committee can create a schema that standardizes how data is structured (and thus organized during transmission). Then, a receiving application can retrieve a validation document based on the schema and make sure the data conforms to its intended use before processing the data. Think about how critical that service is for medical treatments or fair game play. Then realize how tedious and non-creative working with data presentation standards is - those hard workers (please call them knowledge engineers to try and give them their due status) are not paid enough nor respected enough in my opinion. By using Web architecture to incorporate great data presentation services, we only have to write those boring and incredibly tedious services once and then ship them all over the Web for use. Back in the day, each organization had some poor, near blind employee working in a cubicle trying to transform data from one format to another based on the needs of the software that organization needed to use. Sure, it provided employment for so many people who got laid-off in the 90s thanks (or no thanks) to the Web. But, there has to be better jobs out there for human expression and creativity like you artists get to experience! Not that you necessarily prefer the competition, but imagination and creation is the way to go for quality of life, no?

I get a feeling that the presentation layer was quite the battle to get represented in the OSI model - someone had great foresight to see something like XML coming. But, in many widely used applications and protocols, no distinction is made between the presentation and application layers (they are totally co-mingled like a bad accountant who co-mingles funds from the pension fund to executive bonuses). As a good example, consider that HTTP is generally regarded as an application layer protocol, but has important presentation layer aspects such as the ability to identify character encoding (ASCII v. UTF-8 v. UTF-16 v. Unicode, etc.) for conversion, which is then done in the application layer (whereas it would be done in a separately crafted presentation layer if the OSI model was adhered to properly).

This is an exciting time in our course, no? You've climbed the layers one by one and are ready to linger at the application layer for years to come (unless I've enticed you into some kind of career change by some small miracle - it is a good life working on Web Architecture innovation though, for sure). Wish everyone in class could have made it this far (pat yourself on the back) - but not everyone had the patience nor enthusiasm to take them through to this point (which, sadly, means our forums are a little short of content - and yet, I have lots of friends who will participate after the course is over for you to investigate at your leisure).

I know I am excited for you - we'll end the course on a high note. But, for now, one more week thinking about what is under the surface when you run your favorite Web-enabled application (would that be YouTube? Facebook? Scrabble Players Network? Scooby Doo Channel? Or just Web-surfing in general? Whatever it is, keep looking as there is a lot more interesting stuff coming down the pipeline if the huge gang of people who are educated in the possibilities like you continue to go at it creatively and compassionately).