Thursday, March 18, 2010

Environmental Threats- Computer Security


To gain high secure, a system must be concerned about the interference of natural matters too. The natural matters which affect the security of a computer system are called as ‘Environmental Threats’. Some of the examples for environmental threats can be categorized as extreme cold,heat,humidity,dust,rainfalls,earthquakes, floods, fires, hurricanes, snow, ice, mud slides and sink holes.

Methods of mitigating Environmental Threats

· Air filters should remove fine dust particles because outdoor dust is brought in on clothes and shoes

· Air filters must be cleaned or replaced in a regular schedule.

· Periodically air heating equipment should be turned on, even it isn’t needed. This is to incrementally burn off that would other wise accumulate and be converted to an appreciable amount of smoke, when the equipment is activated for the first time after a long time period.

· Water detectors should be placed above and below a raised floor to monitor the rise of water level.

· An automatic power shutdown should be triggered by a sensor that is lower than the lowest energized wire.

· Any equipment that produces strong magnetic fields should be kept in a room separate from any media that is not scheduled to erase.

· Computers should be kept away from sources of vibrations, including printers. If this can’t be arranged, vibration absorbing mats can be placed under the computer or offending device.

· A dependable and redundant system of air conditionings and humidity controls need to be implemented, monitored continuously and issued alerts when problems occurred.

· If possible the use of a humidifier and dehumidifier should be used to keep a proper humidity levels as climate area and air conditioners can affect greatly the proper levels of humidity in this controlled environment.

· Routers and switches should be placed in an equipment rack with the proper spacing between devices to allow for proper airflow. Typically you will want to allow one “rack unit” or RU between the equipment within the rack.

· Automatic fire detectors should be placed on the ceilings of the rooms as well as hidden spaces (Eg.below raised floors and above suspended ceilings).These fire detectors must be able to function during a power outage.

· An alarm triggering a HI or LOW temperature parameter should be sent to a remote monitoring facility, emailed, text messaged, or paged to the proper personnel.

· As a backup plan, fans should be stored nearby for use in an emergency, as they could mean the difference between keeping equipment online and functioning and being destroyed by the heat if a failure was to occur.

· Long term preservation of data should be stored in magnetic or optical format to keep those data in perpetuity.

· The important and necessary data of the system should be kept as backups in magnetic or optical format to keep for a long time.


  1. The paper 'The Changing Face of Network Security Threats'
  2. The book 'Internet Encyclopedia,Volume 03'

Monday, March 15, 2010

WSRP Specification


The WSRP specification defines a web service interface for interacting with presentation-oriented web services. Initial work was produced through the joint efforts of the Web Services for Interactive Applications (WSIA) and Web Services for Remote Portlets (WSRP) OASIS Technical Committees in September, 2003.

It is an interoperability standard. It’s platform- and language-neutral. It’s all about requesting and transmitting chunks of HTML using SOAP.

The purpose of the Web Services for Remote Portlets protocol is to provide a web services standard that allows for the "plug-n-play" of remote running portlets from disparate sources. Many sites allow registered users to personalize their view of the website by turning on or off portions of the webpage, or by adding or deleting features. This is sometimes accomplished by a set of portlets that together form the portal.

WSRP defines how a portal can connect to a diverse set of information service providers using a single, generic protocol that requires only one type of portlet (a WSRP consumer portlet). This has the potential of greatly easing the integration burden associated with portal deployments.

The Key capabilities of WSRP

  • Allow portals to publish portlets so that other portals can consume them without programming.
  • Make the Internet a marketplace of visual Web services, ready to be integrated into portals.
  • Allow anybody to create and publish his or her content and applications as user-facing Web services.
  • Allow line-of-business portal administrators to browse directories for WSRP services to plug into their portals without programming effort.
  • Enable interactive, user-facing Web services to be easily plugged into standards-compliant portals.

WSRP v1 and v2

WSRP v1 provides a limited interoperability platform. So that effort could be concentrated on WSRP v2. WSRP v2 will augment the initial standard with cross-portlet coordination and access management features.

This major update to the standard will permit for a more useful integration of multiple of content sources, regardless of whether they are local or remote, into a new web application.

In addition, WSRP v2 may support some subsets of Web 2.0 technologies, such as AJAX and REST, without requiring them.

WSIA (Web Services for Interactive Applications) will extend the concepts in WSRP to a range of distributed Web applications, not just portals.

Java Portlet Specification


The Java Portlet Specification provides a standard for developing portal components with the Java programming language. This specification, originally released in October 2003 called as JSR168, is gaining popularity as not only a standard for traditional portals, but also as a framework for deploying 'plug-ins' for standard Web applications.

Currently there are three Java Portlet Specifications as JSR168, JSR170 and JSR 286.

JSR 168

JSR168 is a standard relating to portlets within Java-based portals. JSR168 defines a standard set of behavior for portlets and a standard interface that governs how portlets interact with the portlet container (typically a portal package) in which they are hosted. In simple way it defines a portlet specification, including a contract between the portlet container and the portlet. JSR 168 is defined by the Java Community Process (JCP) in October 2003.

Goals of JSR168

• Define the runtime environment, or the portlet container for portlets.
• Define the API between portlet container and portlets.
• Provide mechanisms to store transient and persistent data portlets.
• Provide a mechanism that allows portlets to include servlets and JSP.
• Define a packaging of portlets to allow easy deployment.
• Allow binary portlet portability among JSR168 portals.
• Run JSR168 portlets as remote portlets using WSRP protocol.

JSR 168 offers numerous useful portal-specific capabilities as follows.

• Portlet modes – JSR 168 provides three modes for portlet interactions.
VIEW - This mode, a mandatory one that's defined by a portlet, renders markup fragments.
EDIT - This optional mode enables changes to per-user settings to customize rendering.
HELP – This optional mode displays help information.

The major changes and enhancements of JSR168

• Decoupling the portlet class from servlets.
• Ensuring that JSR168 aligns well with the emerging WSRP specification in areas such as URL rewriting, portlet modes, window states, multistep navigational state and portal container context.
• Offering general architectural cleanup to allow for flexibility and extensibility over time.
• This standard ensures that portlets were cross-vendor and -server compatible.

Issues in JSR 168

• Inter-portlet communication and event model. This is arguably the most important gap in the JSR168 specification
• Provision for client-side portals.
• Tight coupling with one or more user interface frameworks, such as Struts, Java Server Faces (JSF) and Barracuda.


JSR-170 is a specification developed under the Java Community Process (JCP) program in April, 2005.
It promises the Java world, and possibly beyond, a unified API that allows accessing any compliant repository in a vendor- or implementation-neutral fashion, leading to the kind of clean separation of concerns that characterizes modern IT architectures.
The JSR-170 API defines how an application and a content repository interact with respect to a number of content services. For example the versioning facilities of a content repository are clearly defined, so an application knows how to browse the version history, check in and checkout content items, or update and merge content in a standard fashion.

JSR 286

While JSR-168 laid the foundation for the portal architecture, it lacked many features that applications and developers needed. This forced developers back into creating non-portable, vendor-specific solutions, which therefore defeated the very purpose of having a portal specification. Then The Java Portlet Specification V2.0 (JSR-286) was created to enhance JSR-168 and improve upon its shortcomings. On June 12th, 2008, JSR-286, went final and was publicly released.

Major enhancements of JSR 286
  • WSRP 2.0 alignment
  • Serving AJAX or JSON data directly through portlets
  • Serving dynamically generated resources directly through portlets
  • Inter-Portlet Communication through events
  • Setting Markup Head Elements
  • Caching Changes
  • Public Render Parameters
  • Window ID / Namespacing Consistency
  • Additional CSS classes
What was left out of the JSR286 Specification
  • Clear Read / Write AJAX support
Developers have no way to make sure other Portlets receive state change information, when updating state through a Resource URL.
  • Improved Groups and Permissions Support
  • More CSS Classes
Although some additional CSS classes have been defined by the JSR 286 specification, they are insufficient to meet the demands of good user interfaces.

Portlet Standards

This is a topic researched by me for the literature survey of our final year group project.


Over the past few years, portals have evolved rapidly in the Internet space. They have helped businesses aggregate secure and personalized content and applications to the Web.Portlets used by portals function as pluggable user-interface components that provide a presentation layer to information systems.

In the early days of portal development, little emphasis was placed on component interoperability or reuse. Why? Because portlet APIs for development or customization at that time were limited to a single portal product only.

To overcome these problems, the Portlet Specification was started to provide interoperability between portlets and portals.

Portlet Specification defines the contract between a compliant portlet container and portlets. It defines a common Portlet API and infrastructure that provides facilities for personalization, presentation, and security. This standardization allows for portability of portlets between portal implementations.


• Support multiple portal products. The compliant portlets can be deployed to all compliant portal frameworks without extensive engineering changes.
• Code re-usability.
• Creates a wider market opportunity for portal tools: IDE’s, test tools, performance measurement tools and reporting interfaces.
• Support all compliant portal servers without additional engineering and support costs.

Mainly there are two categories for portlet standards.

1. Java Portlet Specification (JSR168, JSR286)

Installing SVN on Windows

Install SVN Server

The steps to install SVN on windows as a service are listed below.

Download the latest Subversion Windows binary installer from svn windows binary installer download. At the time of writing, that's 1.67. Then install it. (It’s better to override the default install path and going with something shorter as C:\svn\).

The SVN installer adds c:\svn\bin to the installation path and can launch a command prompt and start working with it immediately.

Then create the first source repository using following command.

svnadmin create "C:\svn\repository"

Within that newly created ‘repository’ folder, uncomment the following lines in the conf/svnserve.conf file by removing the pound character from the start of each line:



Next, add some users to the conf/passwd file. Uncomment the default harry and sally users to play with, or add own users:


Then to install Subversion as a Windows service issue the following command:
sc create svnserver binpath=”c:\svn\svnserve.exe --service –r c:\svn\repository”

displayname=”Subversion” depend=Tcpip start=auto

It's set to auto-start so it will start up automatically when the server is rebooted, but it's not running yet. To fix that,issue the following command:

net start svnserver

Access SVN Server by clients

Most people use TortoiseSVN to interact with Subversion. Download the latest 32-bit or 64-bit Windows client (1.6.7 as of this writing) from and install it.

svn:// is specified as the prefix to our source control path, which means we're using the native Subversion protocol. The Subversion protocol operates on TCP port 3690.

So as an example you can access your SVN repository by typing following url in IE browser;