Since we are going to be developing intranet applications, I think it is essential that we understand how an intranet works. An intranet basically works like the Internet, except that it cannot be accessed from outside the organization for which it is deployed. It is usually a network of computers serviced by a central computer (called a server) located within the same building. The server automates interdepartmental communication activities by making applications available to each department or person.

We will be developing a messaging system that will show just how much an intranet facilitates this interdepartmental communication. When you think of a typical large company, it has a hierarchy that is departmentalized. There will usually be a number of teams and team leaders. Each department will have a set of computers that will be linked to the central server(s):

fig1 Typical intranet layout

In the layout above, there are four departments and each of them have PCs that are all linked to the intranet server. The intranet server is where all the applications will be located. You might be asking "if all I have to do is create an application and place it in the intranet server so everyone can access and use it, what is all this fuss about application frameworks?" The short answer to that is "centralized control and security." Just because the intranet cannot be accessed and abused from outside the organization does not mean that it cannot be abused from within. Creating an application framework enables better control over the activities of the users and the applications themselves.

So, in short, we need an application framework for two reasons. First, we need it to control access to the intranet and indirectly to the applications that it hosts. Second, we need it to set application parameters that will in turn set the application's operating scope.

So based on the above conclusions, let's look at the practical requirements for our application framework. Since most of the functions of an application framework boil down to access control, I've come up with the following requirements:

Application level authorization - An application must be able to distinguish between different types of users and grant access in an appropriate fashion. For example, a secretary in the marketing department of a publishing company does not need access to the publishing application of the publishing department, but he or she will need access to the shared client or contacts database. Each application will have a different purpose, and should therefore be able to authorize users accordingly.

Central Authorization - For any user in a company to access the network or intranet, he or she needs to log in and go through the process of authentication. The user will then have access to the intranet applications. So in effect, the user will only have to log in once to access all applications. A user will then be authorized by each application separately. So how will the application be able to identify a user? To enable applications to identify a user, the login application will create sessions to keep track of who logged in; the sessions will be created during the process of authentication referred to earlier. These sessions will then be used to identify a user at the application level. In the same fashion, a user will be provided with a logout facility to end a session.

Database support - Almost all applications will at some stage need database support. Arguably, an application is most useful when it is able to extract and insert information from a database. In an intranet situation, this is even more important, since automating daily tasks means that access to information should be readily available. For example, if the team leader of a particular construction project wants to find out the progress of a project he will go to where that information is stored and then read the info there. This gives the team leader the ability to make effective business- or project-related decisions. So database access and support to applications is essential.

Now that we have the requirements worked out, let's take a look at the framework. Here's a diagram showing what the application frame work looks like: