Software application development is booming currently. The recent years have been of profound skill development, but as the skills have increased so has the need for more diverse software applications to do all different things for varying businesses. With a diversity of programming tasks to perform, programmers need to be careful in their selection of a suitable programming language for the application in question.

If we talk about options, the earlier proprietary methods have now been supplemented with another group of programming tools which have recently become popular as “open source.” So now, there are two major groups of web application development languages to look into - open source and proprietary. Open source is a great alternative leading to cost-effective development of dynamic applications. Among the commonly used open source programming languages are PHP, JSP, and Perl, while ASP.Net and ColdFusion are the well-known proprietary technologies.

PHP

It’s an open source programming tool that’s completely free. However, that’s not the only reason why web developers have developed a preference for it. Other major strengths of PHP are that it’s plain, flexible, and updated more regularly than other languages by a massive international community of users who developed it and are actively engaged to develop this platform.

ASP.Net

ASP.Net is categorically the most flexible of the web application programming tools. Anyone can apply it with both scripted languages (such as Jscript, VBScript, Perlscript, Python) and compiled ones (like C, Cobol, Smalltalk, Lisp, VB). In addition to that, its flexibility is also apparent in the compatibility of applications with development environments such as VisualStudio.NET, WebMatrix, Borland's Delphi, and C++ Builder.

JSP (Java Server Pages)

Java Server Pages, or JSP, is an open source scripting language that can be consummated without even knowing JavaScript. It is supported by Oracle, so programmers can use Oracle JDeveloper to create JSP pages.  It is extensible, and the tag extensions used in this language are straightforward and spotless in form. It allows Java tag library developers to outfit it with simple tag handlers, which is quite a major advantage over other software programming languages.

Perl

It’s both full-grown and powerful, which makes it a well-liked open source application programming language. It provides web application developers roughly any tool they need to create dynamic web pages. Another good thing, quite common to most open source languages, is that it keeps benefiting from an ongoing development offered by a large user community, which is also greatly supportive to the developers using it.

ColdFusion

It is another powerful language, presently owned by Adobe. It’s easier to get started with it and create forms and dynamic web applications; it could be done with lesser training, fewer code, which means time saving.

Choices are many, but the above programming languages are being principally used to develop successful, proficient software applications. While open source is cheap and is often rather uncomplicated and capable to fulfill the application flexibility need, proprietary is more acceptable when it comes to fulfilling the security, scalability, and complexity demands. Furthermore, it’s also important to count on the in-house expertise when it comes to choosing a right tool as that would only determine how the application will be managed in future.

Let me start with a common misconception that a web-based application or system is ideal only for an ‘online’ business or e-business. Any business or corporate body can benefit from such an application. In fact, you would be delighted to see how a web-based system minimizes your resources and cuts your overhead by managing or automating a certain aspect of your business.

Let me relieve myself now with sharing why your business should have some web based business applications implemented and also some great benefits that web-based business applications can bring to you, your employees, and ultimately your business.

Why should you incorporate a web-based application in your business?

Centralized working – A web-based system will enable you and your business to consolidate all information into one centralized database. By adding all back-end functionality necessary for the daily operations of each employee into one central business application, you will be collecting data and perform tasks for multiples areas of your business. A company’s internal network, such as an Intranet, or integrating a system into a website’s back-end section to allow employees gain access for some back-end tasks is an excellent example of centralization. Small- or medium-sized businesses can greatly benefit by such solutions.

Automation – A web-based application can help your business tremendously with automation of some burdensome and expensive manual process. Imagine a business that sells products where customers order on phone. In this case, a web-based system that allows your customers to login to the back-end of your website and make the purchases automatically could help in many ways. Primarily the owner gets an advantage of an overall reduction in his employee overhead, and the other benefit is that he can view the updated sales data at any time through automated sales reports.

Increased productivity – It is easy to understand how centralization of your company’s data and automation of the back-end operations of your business can dramatically improve the overall working system of your business. It provides an opportunity leading to enormous business growth. Data centralization provides an efficient system whereby your users save a lot of time, which naturally increases their productivity. On the other hand, a logical consequence of automation is that you save your money on manpower and other resources, which is ultimately your profit.

So, by relying on web-based business software application, you get a new success formula. You just need to change your traditional business mindset and start taking such forward moves.

Introduction

Multitier or ‘N-tier’ architecture is a software system segregated into separate sections (referred to as tiers or layers). The default set value of ‘N’ is three. It’s an architectural methodology incorporated as a part of web based software application development.

The need

There are many reasons of using such layers to construct an application. Here they go:

• Scalability: A layered structure provides an optimal amount of scalability to the system. Any of the tiers can be upgraded or interchanged independently without affecting the functioning of others.

• An ease in implementing changes: A software system is subject to changes. This change can come in the form of a functionality change, a functionality enhancement, a completely new module, or even a hardware infrastructure enhancement, and so on. In any case, changes can occur during the initial development or after the first version is complete. By designing a system architecture as multitiered from the very beginning, one can minimize the impact on the whole system when implementing any change to any layer.

• Maintenance ease: If the source code is organized into multiple tiers, debugging and application maintenance as a whole becomes easier. As a developer it is easy for you to locate specific sections where an error is occurring or a change is needed and do the needful. A well-structured architecture brings an easy solution to defects and bugs and allows easy upgrades or enhancements, which otherwise would be very much time consuming.

The description of individual layers

A typical multitiered application consists of:

• Entity Tier (your website application)
• Business Tier (the brain of your application)
• Data Tier (the data processing section of your application)

Entity Tier: This is the presentation logic layer, something that the users view. This includes simple control and user input validation, is similar to a web application. It is also known as ‘thin client.’ It has a reference of the business layer. This layer has no knowledge about the system working, database, or any information.

Business Tier: This is the ‘brain’ of your entire application. It provides the business processes logic and the data access. It will act as a bridge from the presentation to the data access so that the information can be processed in some cases and, in other cases, can simply be the conduit to ensure the smooth flow of information. This layer will have the most information about the activity and the processing that needs to take place and will have a heavy implementation of the business objects.

This layer does not know any information to access data. It just gives the requirement to the ‘data access layer.’ It sets forth the business rules from the earlier gathered requirements.

Data Tier: This is the only layer of your application that knows how to interact with the database servers and retrieve the required information. Without any knowledge as to who is asking or whom is it giving the information to, all what this layer does is that it gives information back to the request object.

Data retrieval process is most likely in the form of selecting, querying, inserting, updating, or deleting information to and from the database.

I hope this article has provided you a useful insight into the advantages of splitting an application into multiple layers. Have a great going!

A critical aspect related to web application development is that it should be built in a way that it gets an ability to manage active sessions well. Here are a few ways to achieve it:

• Web applications need to have a method to establish sessions keeping track of a user’s requests and account logout. If your application has a logout button or link on every page, the users will be allowed to log out easily. Also, those who have not logged in for a while should be locked out until they reregister.
   
• Timeout settings: These can be based on how users are likely to interact with web applications as well as how sensitive the data is.

• If you don’t want browsers to cache your content, you can do so by setting the cache-control directives in the server response headers (set it to no-store). There are some limitations for this, however. Unfortunately, no-cache and no-store are not supported by HTTP 1.0 caches (they are HTTP 1.1 headers). Moreover, non-HTML content is often cached even when the above tags are set. Another concerning factor is that some browsers are able to store user-supplied form data, often insecurely. If any of your Web Forms collect sensitive data, add the attribute AUTOCOMPLETE=FALSE. This warns the browser not to store the data (it’s not a part of HTML specification, however). If you consider your application high-risk, you can ask the user on a shared PC to clear the browser's cache and history.

• If you want to ensure that session replay attacks don’t occur after idle timeout or user logoff, it is critical that you clear the server-side session state, destroy the session on the server, and overwrite any session cookies on the browser when the user logs out or the session expires. Also, URL should not include session IDs because they can be seen by shoulder surfers, cached by the browser, and stored in the referrer logs of other sites. Ideally, a user's entire session should be SSL-protected to prevent session ID exposure through network interception. Session IDs that are long, complicated, random numbers and expire and regenerate prior to any significant transaction, or after a certain number of requests or period of time, especially when switching to SSL, reduce the risk from session-hijacking and brute-force attacks.

Make sure that you document the goals of managing software application sessions and the mechanisms implemented to achieve them in your security policy to avoid any future complications.

No matter what rich internet application (RIA) technology you use, be it Flex, Ajax, JavaFX, Silverlight, or any other RIA technology, there would be a basic similarity in the architecture in that most typically there will be a stateful client application and a backend layer of separate services. Success in designing and building a rich internet application would depend a lot on how well this differentiation is understood and taken care of.

As RIA lends itself more to client-server development rather than traditional web development, the client knows about itself and about the types of data it requests. With no extra markup, it will request only the data it needs from the server. Most often this would result into a cleaner services layer and less-complicated server requests, a reduced overall server load in some cases.

The outcome always is client communicating with the server through the services layer; it hardly matters whether you use AMF remoting, XML over HTTP, JSON, or SOAP. Their respective pros and cons don’t have a significant effect on the big picture. On the sub-architecture side, each component of the larger architecture has an architecture of its own, which is important to understand.

Model-View-Controller (MVC) is a software architectural pattern where an application is broken into separate layers for the data model, the user interface (view), and the business logic. The logic, model, and views are decoupled, and communicate through an intermediary controller. This pattern allows both abstraction of logic and reuse of code/components throughout the application. Unlike the traditional web based software development where there is a singular MVC, in the world of RIA there are two layers of MVC – one MVC inside the client application itself and another in the backend services. It’s not that every application uses a formal MVC or a fully mature framework for handling the client and services, but still each side typically has at least a fundamental MVC-type of functionality.

While the client MVC maintains the state of the application, handles all data requests to the server, and controls how the data is presented in the view, the MVC on the server handles requests from the client. It processes the requests from the client application, delegating actions on the server. This could include things like saving data in a database, updating the file system, or analytical processing of some kind. However, instead of a user interface, here the view would be the format of the data that is being returned to the client application and it would determine the result format (JSON, XML, etc.). A differentiated service layer also brings the benefit that you can already have the infrastructure built to create a public API on top of your services logic, in case you need or desire to maintain one.

RIA development can be done with a variety of technologies. For writing backends, you have programming languages like Java, ColdFusion, PHP, Rails, .NET, etc., and on the client side, there are established MVC frameworks for Flex/ActionScript and Ajax, some emerging ones for Silverlight, and adapted Java frameworks for JavaFX. You need to define the needs and capabilities of your application well if you want to determine both the back-end and the front-end application architecture well.