A main concern in any application using a distributed architecture is the management of Sessions. A Session is an instance of use. The Session represents the user and the state of his operations during a use case scenario. In an Application Layer using Controllers, the Session identifies the user and some persistent values or state of the View in the MVC pattern. But a Session isn’t the View. A View represents a visual user interface that could be also represent a complete use-case scenario or a part of a more extended one. The Session could have View values or properties, but more than that identifies the user and possibly, by doing that, profiles the permissions set of that user. In complex use cases that must be executed over several Views (imagine a wizard, e.g.). The Session unifies the work, indicating who is doing that and which steps are being completed by the presence or absence of data. For example in a questionnaire wizard the Session must remember the previous question and possibly the answer and which question go next. Also the Session has to remember which questionnaire is running, and who is answering.

A security issue appears by mixing Views and sessions. The View could capture the execution process and impersonate a user by taking its identity. That concern obliges to move Session management to a controlled environment which as you may suppose is: the Controller. The Controller is a kind of director. It manage all sub-systems to accomplish application tasks in a coherent manner to fulfill a use case scenario. With this in mind and knowing that Session management needs to be securely address, it’s a better solution to use a Session manager component or sub-system.

A Session manager then will be a component (or a complex sub-system if the need arrive) which its only task is to «remember» the Session and provides to the Controller the appropriate state of it. Also in the Session instantiation and definition we could encapsulate all the security code that assure us not to mix sessions or violate permissions rules.

Session management could be very complex and difficult to define in the application architecture. Principles as Separation of Concerns, Low Coupling and High Cohesion discourage the mingled of View (user-interface) and Session (user workflow representation). Then, how the View knows about its session data? User interface doesn’t know about the sessions but about visual elements (text boxes, tables, drop-down boxes, etc.), the data they contains and events around them. The Session manager is the architectural element that must known about the user that runs a scenario, providing to the Controller the data it needs to unifies task under proper user and security environment. As said before, the Session manager isn’t a View.