Learn Software Development » Architecture

Some details related to session management

ashish — Thu, 22 Mar 2012 20:06:45 +0000

Session management is a concept related to the interaction between human and computer. The term “session management” is self justifying. We can make out from the term itself, that it deals with keeping a track of the activities of the users across various sessions in which there is an interaction between the human and the computer. A session management in a desktop environment is said to be a typical one if it involves keeping track of the close and open applications as well as the documents. Session management is needed so that the active session of the user can be stored up on hibernation and the same session can be restored when the user logs in next time. The concept of session management is somewhat different from that of the usual session management in web applications or web sites.
A certain time period is specified for a session on some web sites and applications. After that time period ends, the user is required to login again. A session usually expires when there is no user activity during that period of time. Apart from just managing the user sessions, the session management serves another purpose i.e., it stores the information on the server side for the generation of the HTTP requests. Session management is divided in to two categories depending on the area in which they are employed i.e., whether it is employed in desktop management or web server management:
1. Desk top session management: Desktop sessions are managed by a program commonly known as desktop session manager. This program serves the purpose of saving and restoring the desktop sessions. A desktop session includes all the currently running windows and the data they are processing. Some examples of session managers are:
(a) X session manager: This session manager is employed in the systems operating on the Linux operating system.
(b) Twins play: This is a third party application that serves the purpose of a session manager in systems like Microsoft Windows in which a session manager is absent.
Desktop session management consists of the browser session management also. Now you may ask what is the need for session management in browsers? It is required to save open pages and restore them altogether later whenever required by the user. This also helps in restroing the session of the browser later on the next run if it crashed in the middle of some session. Today there are many web browsers that support session management like:
(a) Google chrome
(b) Opera
(c) Omni web etc
There are some web browsers that make use of third party applications for session management like Mozilla Firefox. It uses either extensions or plug- ins. Session management process in the web browsers depends largely up on the availability of the session cookies.
2. Web server session management: HTTP or hyper text transfer protocol does not have any state. So it is required that a new TCP or transmission control protocol is established between the web browser and the web server according to every HTTP POST or GET request. This makes the established TCP network connection highly unreliable. Here the session management proves to be a great help. It provides a state to the stateless HTTP. The information regarding every web session is stored in the web server by using the session ID. This session ID is generated up on a request by the end user. The sessions are stored using a variety of techniques such as:
(a) Flat files
(b) Data bases
(c) Local memory
In some cases the same session information is required to be shared by multiple sessions. In such a case the session information is shared via the cluster nodes.

Content Management for Dynamic Web Delivery	Web Project Management	Real Web Project Management

Computer networks: What is meant by two tier architecture?

ashish — Wed, 22 Feb 2012 17:10:51 +0000

You might have come across the terms “1 tier architecture, 2 tier architecture and 3 tier architecture or application”. But what does these terms actually mean? A lot of people mention these terms, but don’t really know too much about these. In this article, we have discussed in detail about the two tier architecture. However, to understand the 2 tier architecture you first need to understand the concept of client-server model. So let us start on it. A client-server model as the term itself suggests can be thought of as a type of computing model. This computing model works as a distributed application making a data link between the clients and servers.
A server is a typical resource and service provider whereas the client is the one makes a request for a service or a resource to the server. The location of the client and servers or the distance from each other does not matter, since they are said to be present over the same system, once they are connected via the client server model. The communication between the servers and the clients takes place through the computer network established through the internet and on different hardware (but in most cases, this connection can be made securely if required). A computer serving the requests of the clients is called a host or more commonly called a server. These resources are shared among the several clients that may be located worldwide.
In contrast to the server, no data or file is shared by the clients. The communication thus is said to be initiated by the clients. There are several functions that are built on this model of client and server like:
1. Web access
2. Email exchange
3. Data base access etc.
The client server model presides at the heart of this whole computer networking system. Most of the web applications being built today are based on this model.
However, this is not the same as a two-tier architecture. Now let us discuss about the two tier architecture of the applications. The two tier architecture was developed as an attempt to improve the model of the file server application programming. The benefits that the two tier architectures includes scalability, flexibility and usability. As the term “2 tier architecture” itself suggests, it constitutes of two layers or tiers (“tiers” is more appropriate word):
1. Server and
2. Client
The applications built with the 2 tier architecture system usually have a user friendly graphical user interface as compared to the applications employing other types of architectures. But there are also some limitations of this architecture. It does not permit a large number of users to use the application and also the sharing of data can be done only within the homogenous environment and not outside that environment. The two tiers of this architecture have physical separations which are mainly process boundaries, machine boundaries or corporate boundaries. The two tier architecture application is a combination of the client application and server application. Since there is no intermediate application between the two sides, the communication takes place directly. Particular business logic is often incorporated at either side resulting in fat client or fat server accordingly.
The application programming interface or API forms the link between the data base and the client. 2-tier architecture is very cost effective since it requires less deployment cost. If any change is made to the data base of the application, accordingly the modifications should be done in the client side application. If n numbers of clients are connecting to the data base there will be n number of individual data base connections. The two tier architecture is usually used in the development of the localized applications, where the users are all located in a geographic location, and the server processing their requests can be placed in the same location.

Computer Architecture, Fifth Edition	Computer Organization and Design	Digital Design and Computer Architecture

Problem in Scrum: Looking at technical debt, which will cause more problems as you move ahead ..

ashish — Tue, 04 Oct 2011 14:24:11 +0000

What is technical debt ? Well, I will not try and give a definition for technical debt. Instead, consider that you have 2 approaches to build some great new features. You can do something in a quick way without trying to build a great design, or you can build it the proper way through the required design. Now, if you need to get features done quickly, then trying to build in the proper design and architecture can stretch the possibility of getting the features done in time for the need (say, if the team is under pressure due to market requirements, or due to external stakeholder pressure). In such cases, it is a business need to build the feature done quickly enough, but one of the problems of taking such an approach is that you need to build a structure in order to build more and more features, and as you neglect the design work, building features becomes even more difficult. To put it in another way, in order to save some time in the beginning, you spend more time later. This is what is called technical debt.
In the case of the Scrum process, what I have seen in practice in many teams is the concept that because of the pressures, because of the way that the team seems to work from a Sprint to Sprint, the tendency to think about architectural change can slip by. The whole team is driven through a process whereby the Product Owner defines a set of features, prioritizes them, these are broken down into discrete tasks and estimated and then implemented by the team. There can be a lot of pressure to ensure that the teams are delivering a set of features on a regular basis; further, people are occupied on ensuring that all the features are delivered on time. It can get pretty difficult to insist that architectural tasks are delivered, since there can be a lot of resistance to putting these tasks into the Product Backlog. It would typically need somebody of the stature of an engineering manager to have those discussions with the Product Owner, to explain the need to put in the engineering time for putting in design for building for more features. It can be difficult at times, and in our case, it took us a few months and one round of feature failure to explain the engineering design process in detail to the Product Owner, and now we are in such a condition that the Product Owner totally understands when we push for some architecture work. However, it can take time for the Product Owner to be comfortable with these details.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 2

ashish — Mon, 03 Oct 2011 14:21:32 +0000

In the previous post (Not putting design priority), I had talked about how a Scrum team can face challenges in terms of prioritizing the architecture and design tasks. In this post, I will continue my previous discussions and talk about how teams do actually place a lot of emphasis on the design part, and how this has to be driven by somebody.
I was recently talking to an engineering manager who was part of a team that was working on a product (or rather, the people in the Scrum team reported into the engineering manager). When I asked the same question, about how the team managed to ensure that they did not get into a situation where the design work was not planned for, the engineering manager was quite emphatic on this subject, that the team ensured that all the required architecture and design work was planned and the team ensured that in discussions with the Product Owner, these were incorporated into the Product Backlog and actually implemented as part of ongoing Sprints.
Sometimes, such an approach can be problematic. Part of the philosophy about Agile that I have heard often enough is the need to avoid doing unnecessary work. Sometimes, it does happen that the architecture work that is planned for the cycle is actually an overkill, and when the work is done, you realize later that the feature for which this architecture was planned and executed was not required. This can be painful, and when such a scenario occurs, there can be disagreements with the Product Owner. We had a case once before where we were supposed to be building a great new feature that dealt with the interaction between the client server application and an internet based client chat and forum system. This system was not in place earlier, and hence the entire application layer that dealt with integration of the API’s of the web application was integrated, so that in later cycles, the user interface would be built and tested. However, in a change of plan (caused due to new features integrated by an opponent), we dropped the internet based system integration and built in a new feature that was a core feature.
As a result, all the architecture work that we built in had to be dropped, and all the time that was spent in this work was also wasted. Also, there was no certainty that the work that was done would be used sometime in the future, since the feature may or may not be needed in the future. On the other hand, if we needed to put in the feature, it was necessary to make the architecture change in earlier Sprints, so that the software had the base built for the user interface feature. This was a ‘necessary evil’, and in the end, if the feature was needed to be done, the necessary architecture was required to be in place in advance. For most features that are big and require such architecture work, such planning is required.

Problem in Scrum: Inability to prioritize the architectural and design tasks – Part 1

ashish — Fri, 30 Sep 2011 19:18:34 +0000

Over a period of time, some of the discussions that I have had with fellow managers, and more specifically with managers who play the role of Scrum Masters come to a conclusion revealing a weakness in Scrum implementation. Projects where there is initial time spent on planning the architecture and design for the end project tend to have a good design that is scalable, where the individual components (and the flow between them) and the overall design has been well thought out. Sometimes, the amount of time spent in design and architecture seems like an overkill, but in most cases, the amount of time spent is the amount of time required for such activities.
However, one of the biggest problems that has been seen in the implementations of Scrum that I have observed relates to the planning for design tasks. In a typical waterfall methodology, the schedule is split into properly defined and demarcated times for the implementation of all the design work, and the product seems all the better for that. However, when you get into the game of having a Sprint where all the User Stories for that Sprint should be implemented by the end of the Sprint, where the Product Manager defines all the User Stories (and is lead to believe that the Product Owner controls a large chunk of what the engineering team is actually doing). As a result, when you have design tasks that could take multiple Sprints to complete, many times the engineering team cribs about the limited amount of time that they get for doing such a task and believe that the design work is not really complete and can cause problems as the project schedule moves ahead.
Consider the case where the User Stories are defined and added to the Product Backlog. Ideally, these should include the tasks related to design and architecture so that they can be properly prioritized and planned for completion in the required Sprint cycles. But, when the overall requirements are not constant, or are broken down into small parts, it does get more difficult to come up with a proper and structured design document which covers the need. In addition, for many teams, it can be hard to convince the Product Owner about the need to do large architectural tasks, especially when they do not relate to features, or may be needed for features that may or may not be required.
Overcoming such challenges requires a lot of planning, and some work outside the regular Sprint planning cycle, but teams need to do this in order to ensure that they have a good design.