Understanding Services And Applications Computer Science Essay

Published: Last Edited:

This essay has been submitted by a student. This is not an example of the work written by our professional essay writers.

      "A web based application is a software package that can be accessed through the web browser. The software and database reside on a central server rather than being installed on the desktop system and is accessed over a network."

Web based applications are the ultimate way to take advantage of today's technology to enhance the organizations productivity & efficiency. Web based application gives an opportunity to access the business information from anywhere in the world at anytime. It also facilitates to save time & money and improve the interactivity with the customers and partners. Web-based applications are easy to use and can be implemented without interrupting the existing work process. Whether we need a content managed solution or an e-commerce system, we can develop a customized web application that fulfills the business requirements.

Web App: Simple Definition

Though fully describing what a web application is can be lengthy, a quite simple description can be "a web application is an application utilizing web and [web] browser technologies to accomplish one or more tasks over a network, typically through a [web] browser."

2.2 Web Services

Web services are designed to provide the messaging infrastructure necessary for communication across platforms using industry standards. Web services also use asynchronous communication to address the latency issue that arises due to requests from remote locations across the Internet. This allows the execution of background tasks for the client (such as responding to user interactions) until the actual completion of the Web service request.

The main advantage of a Web service is that its consumers can use the service without knowing about the details of its implementation, such as the hardware platform, programming language, object model, etc. Web service provides a loose coupling between heterogeneous systems with the help of XML messages, providing interoperability.

Introduction to Web Services

There has been a lot of buzz about "Web Services," and many companies have begun to rely on them for their enterprise applications. So, what exactly are Web Services? Simply, they are yet another distributed computing technology (like CORBA, RMI, EJB, etc.). They allow us to create client/server applications. For example, to keep a database with up-to-date information about weather in the India and we need to distribute that information to anyone in the world. To do so, we could publish the weather information through a Web Service that, given a ZIP code, will provide the weather information for that ZIP code.

Figure 5 depicts the operation of a web service. The clients (programs that want to access the weather information) would then contact the Web Service (in the server) and send a service request asking for the weather information. The server would return the forecast through a service response.

A description...

Fig: 5 Web Services

Web Services are platform and language-independent, since they use standard XML languages. This means that the client program can be programmed in C++ and running under Windows, while the Web Service is programmed in Java and running under Linux. Most Web Services use HTTP for transmitting messages (such as the service request and response). This is a major advantage for building an Internet-scale application, since most of the Internet's proxies and firewalls won't mess with HTTP traffic (unlike CORBA, which usually has trouble with firewalls).

Demerits of Web Services

Currently, Web Services are not very versatile, since they only allow for some very basic forms of service invocation. CORBA, for example, offers programmers a lot of supporting services (such as persistency, notifications, lifecycle management, transactions, etc.). And also transmitting all our data in XML is obviously not as efficient as using a proprietary binary code. What we win in portability, you lose in efficiency.

However, there is one important characteristic that distinguishes Web Services. While technologies such as CORBA and EJB are geared towards highly coupled distributed systems, where the client and the server are very dependent on each other Web Services are more adequate for loosely coupled systems, where the client might have no prior knowledge of the Web Service until it actually invokes it. Highly coupled systems are ideal for intranet applications, but perform poorly on an Internet scale. Web Services, however, are better suited to meet the demands of an Internet-wide application, such as grid-oriented applications.

2.3 Infrastructure Services

Cloud Infrastructure Services

Cloud infrastructure services can be accessed by applications running on either an on-premises foundation or a cloud foundation. Initially, the most common users of cloud infrastructure services will be on-premises, because there aren't yet many applications built on a cloud foundation. Over time, expect this may change, as more and more cloud-based applications also use cloud infrastructure services. Whether they run on-premises or in the cloud, some applications don't need anything beyond a foundation. Still, many can benefit from distributed storage, common identity and other infrastructure services.


Applications commonly use some kind of local storage, hence storage is part of both on-premises and cloud foundations. Remote storage is also useful. Accordingly, it's reasonable to expect that providing a storage service in the cloud will be attractive for many applications. As with on-premises platforms, remote storage in the cloud comes in different styles. For example, Amazon's Simple Storage Service (S3) provides basic unstructured remote storage. The model it exposes to developers is straightforward: objects, which are just bunches of bytes, are stored in buckets. Applications can create, read and delete objects and buckets. Objects cannot be updated however, they can only be entirely replaced. It is yet another example of how platform services must change to support Internet-scale usage, as used in many cloud services.

Connecting applications has become a staple of computing and vendors have provided a way for on-premises infrastructure services to do it. These range from relatively simple technologies like message queues to quite complex integration servers. As integration services move into the cloud, a range of technologies is also appearing. For example, Amazon's Simple Queue Service (SQS) provides just what its name suggests, a straightforward way for applications to exchange messages via queues in the cloud. SQS also doesn't promise in-order, exactly-once delivery. These simplifications let Amazon make SQS more scalable, but they also mean that developers must use SQS differently from an on-premises message queuing technology.


Whether an application runs on-premises or in the cloud, it typically needs to know something about its users. Toward this end, the application commonly demands that each user provides a digital identity, a set of bytes that describes that user. Based on what these bytes contain and how they're verified, the application can determine things such as who this user is and what they're allowed to do.

Many on-premises applications today rely on an on-premises infrastructure service, such as Active Directory, to provide this identity information. When a user accesses a cloud application, however, or an on-premises application accesses a cloud service, an on-premises identity usually won't work. An identity service in the cloud can address these issues. Because it provides a digital identity that can be used by people, by on-premises applications and by cloud applications, a cloud identity service can be applied in many different scenarios. Accessing Amazon cloud services such as EC2 or S3 requires presenting an Amazon-defined identity, for instance, while using Google AppEngine requires a Google account. Microsoft provides Windows Live ID, which can be used for Microsoft applications.

2.4 On-Demand Computing

On-demand computing (ODC) is an enterprise-level model of technology and computing in which resources are provided on an as-needed and when-needed basis. ODC make computing resources such as storage capacity, computational speed and software applications available to users as and when needed for specific temporary projects, known or unexpected workloads, routine work, or long-term technological and computing requirements.

Web services and other specialized tasks are sometimes referenced as types of ODC. ODC is defined as "pay and use" computing power. It is also known as OD computing or utility computing. The major advantage of ODC is low initial cost, as computational resources are essentially rented when they are required.

The concept of ODC is not new. John McCarthy at the Massachusetts Institute of Technology (MIT) made a comment in 1961 that someday computing may be organized to provide services much like public utilities do. Over the following two decades, IBM and other mainframe providers made computing power and database storage available to many banks and other large organizations all over the world. Later, the business model changed as low-cost computers became ubiquitous in the business world.

By the late 1990s, computer data centers were filled with thousands of servers and utility computing emerged. On-demand computing, software-as-a-service and cloud computing are all models for repackaging computational, software application and network services.

Future of On-Demand Computing

Based on the variety of industry visionaries predict the future of on-demand/utility computing is presented:

Standards needed: Virtual pools of resources will be a failure unless there are standards for cross-vendor management-- Corey Ferengul, analyst, Meta Group Inc., Stamford, Conn.

The open-source competitor: Adoption of utility computing on a broad scale has an unlikely competitor: the open-source software movement. Over the next two years, the more the open-source model succeeds, the more likely it is that customers will keep their IT work in-house, to the clear detriment of utility-style providers. -- Doug Tuttle, director of the Global High Technology Practice, Deloitte Consulting, Boston

Doubling your utility: Today, utility computing is in its infancy. IT doesn't have an economy-of-scale economy that amortizes fixed costs as volume grows. We need to work on the systemic issues so that when someone asks you to double the size of your utility, you don't have a failure. -- Greg Papadopoulos, chief technology officer, Sun Microsystems Inc.

Built-in manageability: Utility computing assembles and delivers IT services on the fly to improve the scale, flexibility and productivity of business operations. To achieve this goal, IT will need to manage itself on the fly like a service, in sharp contrast to traditional systems management, with its centralized control of individual IT resources. -- Mike Maples, co-founder and chief strategy officer, Motive Inc., Austin

Back to the future: Utility computing will inspire a return to true capacity planning and there will be a major demand for individuals with capacity planning and improvement knowledge. -- Corey Ferengul, Meta Group

Virtually no difference: Virtualization software will be a normal part of the operating system, included at no additional charge and providing no differentiation for vendors. -- Corey Ferengul, Meta Group

Third World benefits: Over the next four years, the adoption of the utility computing model will accelerate the advancement of developing nations faster than off-shoring. It's far easier for developing countries to adopt the utility computing model, since they don't have to revamp 20 years of existing technical infrastructure to get the benefits. The analog to this is the rapid adoption rates of cellular telephones in China. -- Doug Tuttle, Deloitte Consulting

2.5 Web Application Frameworks

A web application framework is a type of framework, or foundation, specifically designed to help the developers to build web applications. These frameworks typically provide core functionality common to most web applications, such as user session management, data persistence and templating systems. By using an appropriate framework, a developer can often save a significant amount of time building a web site.

Each framework is different, but many provide a variety of useful features. By using a framework, a developer avoids having to re-implement these same features for each web application they create. Features include, i) Data Persistence, ii) Session Management and User Authentication, iii) Security, iv) Caching, v) Administrative interface and vi) Implementation.

Data Persistence

A core feature of all web applications are their need to store information and build web pages based on stored information. Unlike a set of static pages, most web application pages are dynamically generated from persistent data. For example, in a basic content management system a publisher will type an article on an administrative web page, with multiple fields for article body, title, author, etc. That page will later be dynamically generated when a user requests the article from the web application. This allows each article to be templated the same and lets a publisher edit content without knowing HTML or having to edit files directly on a server.

Obviously each web application has its own needs for the exact data structures to persist. A framework can assist in data persistence with a variety of features: i) a consistent API to access multiple data storage systems, ii) automatic or simplified storage and retrieval of data objects, iii) performance enhancements, such as caching above the database layer, iv) data integrity checks, such as validating relationships or confirming required fields are filled and v) SQL building

Session Management and User Authentication

Static public websites can typically treat each visitor as completely anonymous. Web applications, however, often require user accounts and persistence of information across page views. Some web server and runtime configurations provide basic session persistence, but user account management and application specific logic need to be built on top of it. Frameworks can provide generic user accounts, sometimes extendible, so people can register, login and reset passwords. They can also provide user management for administrators.


Sometimes web application pages are only to be made visible to authenticated users. Frameworks can automatically check and require authentication before generating a page.

Once a user is authenticated, a framework can check the specific permissions for that user. These permissions may be managed in a variety of ways. A framework might provide role-based access control, or any variety of other security features. These are typically managed by a developer in code or a site administrator through an administrative interface.


To improve web application performance, web developers will often cache certain content so it does not need to be regenerated on each page request. Frameworks can offer a common interface to disk or database storage of cached content.

Administrative Interface

It's very common for dynamic web sites to need a section specifically built for site administrators. Here the site can be configured and data can be altered. Administrators might create user accounts, manage permissions, change page content, generate reports, or anything else as required. Web application frameworks can assist in building administrative interfaces by:

Generating a navigation structure

Providing common interface elements to form fields, such as a date field with a calendar

Automatically generating edit and list pages from persistent data structures.


All web applications take individual HTTP requests and build appropriate responses. This can be handled in a variety of ways, somewhat dependent on the server platform.

Probably the most popular overall design pattern of web application frameworks is Model-View-Controller (MVC). The initial code of the framework, or the platform itself, evaluates the URL and passes responsibility to the appropriate application controller. The controller then performs any necessary actions with the application's model and then lets the view to build the actual response content.

Another consideration in design of a framework is its flow of execution. Often, all requests to a web application are passed through a single set of code provided by a framework, such as index.php at the root of a PHP application. This code is responsible for initializing user sessions, database connectivity and anything else required on every page load. Control is then passed along to the application-specific code responsible for generating the particular content requested. Python's web.py, for example, takes a list of URLs and the class names which are provided by the application to handle them.

The act of designing and implementing a complete web application framework can be a complex task. Without a few clear goals, development can easily get bogged down with inconsistencies and code bloat. Questions to ask at the onset of framework design include:

What specific domain of problems can web applications built with this framework target? If the answer is "all" then often a lightweight, unobtrusive framework is probably best. However, if a domain of problems can be targeted then the framework can include more functionality specific to those applications.

What level of modularity will the framework provide and support?

What development rules will the framework enforce? For example, will application developers be required to follow a certain file structure? Will any particular design patterns be strictly followed?

What will the learning curve be for application developers to learn the framework? The more elaborate the APIs, the better skilled the developers who use it will need to be.

There are many notable web application frameworks:

For Java: i) Apache Struts, ii) JavaServer Faces, iii) Jt Design Pattern Framework and iv) Apache Wicket

For PHP: i) CakePHP, ii) CodeIgniter, iii) Symfony and iv) Zend Framework

For Python: i) Django, ii) Flask, iii) Pyjamas, iv) web2py, v) Pylons - Aims to be similar like Ruby on Rails, vi) Turbogears - Similar to Django, vii) Twisted - More of a lower-level networking framework, viii) Web.py - Simple and Pythonic, ix) Zope - Very powerful and baroque framework designed for large content management systems and x) Pyroxide - Full MVC framework atop mod_python with a truly object oriented ORM (Object Relational Mapping) layer built in.

For Ruby: i) Ruby on Rails and ii) Ramaze

Other: i) .NET