Login

An Introduction to Intranet Application Frameworks

You can use software in a number of ways to improve the efficiency of employees in a company. If there is an intranet set up, you may want to create applications that take advantage of it to help your workers keep track of various projects. To make this work, you’ll want to start with an application framework.

So what do we mean by application framework? In our case, an application framework is a set of rules in which a given application will function. Even though an application is driven by an application or business logic, the rules contained in the application framework will dictate to some extend how an application should behave.

The most common environment in which an application framework is put to use is in an intranet. This is also the environment for which we will design our application framework, effectively turning our applications into what are known as "intranet applications." An intranet application’s primary function is to automate a company’s daily functions. It makes the employees of a company more efficient, not to mention more productive.

For example, a project management application in a big construction company will save a great deal of time and resources as it will make it easy for a manager to track the progress of a particular project. This article will focus both on the integration of the intranet application in the intranet environment and the development of the intranet application. Because the intranet will be central to this discussion, we will take a closer look at how it operates and what it is used for.

{mospagebreak title=The Intranet}

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:

{mospagebreak title=Presentation Layer}

The presentation layer will consist of an HTML template. This template will collect all the input from the user when required; it will also present output when required to do so by the user. HTML is generally used for this purpose.

The most common HTML data collection tool is the form. We are going to be seeing a lot of it during the course of this article. I’ve generated all the templates using Dreamweaver. Dreamweaver makes it easy to make cosmetic changes to aspects of a template that you want to change.

Application Framework

The application framework will consists of three core components:

Database support – This component will offer database abstraction to the applications. See the section on database support on the next page.

Error handling – All applications will need debugging and error handling during and after development. This error handling class will offer such support. Therefore, all applications that use the framework will have to use this support to generate error messages in a uniform way.

Authorization and Authentication – None of the applications using the framework will have to deal with logging users in and out of the system. This will be done by the central authorization facility. Each application will have to use its own business logic to decide which users to grant and deny access. This component will use the database support from the framework to find out whether a user exists and if so, it will redirect the user to the index page of the intranet site; otherwise the user will be informed that her login details did not match.

{mospagebreak title=Database Support}

I mentioned in the previous section that database support will include an abstraction layer. Access to the database will therefore be "abstract." This means that an application can use any of the supported relational databases without having to worry about changing the code. For example, when we develop our applications we are going to use the popular MYSQL database, but because we are using an abstraction layer, our applications will work perfectly with Oracle or PostgreSQL without the developers needing to change a single line of code. This is of course dependent on the developers not using vendor-specific code.

Comments

To implement an application framework of this size is not easy; it needs careful planning and some kind of organization of code. To this end I have decided to use object-oriented code for the entire project. This is because object-oriented code makes it easy to maintain and troubleshoot the code.

It has its drawbacks though. Chief among these is the fact that it slows down program execution. You are going to have to weigh that when deciding to use this system in the real world.

I would also like to make it clear at this point that this is one of many ways in which to implement an application framework. There are other ways in which it can be done, so it is up to you to weigh the advantages and disadvantages and see which of the systems is best suited to your needs.

Conclusion

In this article we worked through what an application framework is and what it does as well as the best environment in which it functions. We also explored what an intranet system is and how it works. We then discussed in detail the core components found in our application framework.

In the next article we will look at the design and development of the user interface of our intranet. We will look at the CSS code as well as the HTML templates that we will use in the entire intranet. We will also look at the structure of our applications and how they are going to work. Then we will move on to develop the code for the framework components.