30-05-2011, 09:22 AM
SOFTWARE FOR THE NATIONAL RURAL EMPLOYMENT GUARANTEE ACT PROGRAMME
Done at HCL
Introduction
“THE NATIONAL RURAL EMPLOYMENT GUARANTEE ACT, 2005 No.42 OF 2005 - NREGA is an act to provide for the enhancement of livelihood security of the households in rural areas of the country by providing at least one hundred days of guaranteed wage employment in every financial year to every household whose adult members volunteer to do unskilled manual work and for matters connected therewith or incidental thereto”.
NREGA is a kind of eGovernance application where the term eGovernance refers to the process of using information technology for automating both the internal operations of the government and its external interactions with citizens and other businesses. Automation of internal operations reduces their cost and improves their response time while at the same time allowing government processes to be more elaborate in order to increase their effectiveness. Automation of interactions with citizens reduces the overhead for both the government and the citizens, thus creating value for the economy.
NREGA is currently a leading eGovernance application in India. At present, the application works as follows: Household/citizen comes to Gram Panchayat and then Gram Panchayat will register household and registered household can demand employment. Gram Panchayat provide employment, make wage payment, and maintain muster rolls. Program Officer issues the muster roll for the approved work. Program Officer keeps paid muster roll. Gram Panchayat maintains several registers - such as Job Card Register, Demand and Employment provided register.
Overall Description
National Rural Employment Guarantee Act, in short NREGA or EGA, has been passed by the Indian Parliament in the year 2005. The NREGA bill essentially guarantees employment for the unemployed in rural areas for 100 days in a year, through work such as building roads, improving water supply and works that are necessary to improve infrastructure in rural areas. The uniqueness of this bill is in the fact that it carries emphasis on issues like equality of wages for men and women, elimination of work contracting/middlemen, payment of wages only through bank and post office accounts to prevent corruption, creating transparency in workers muster rolls etc. Any individual, irrespective of his socio-economic status can ask for employment (either in writing or verbally) with the Gram Panchayat. The act guarantees that if work is not provided within a 15 day time frame (including the eligibility verification and issuing of the job cards) then the applicant is eligible for unemployment allowance. Work to be done is decided by the Gram Panchayat. Emphasis is given to unskilled manual labor focusing on building roads and other public village
infrastructural facilities, water conservation, a forestation, land development & drought proofing. All adults in a house hold are eligible to work. If the work site is not within 5 kilometers from the applicant’s residence then the applicant is eligible for an additional 10% of the wage. This law can be a big boost for nomadic tribal communities since locally domiciled but migrant population is also eligible for employment.
In NREGA system Adult members of rural households submit their name, age and address with photo to the Gram Panchayat. The Gram Panchayat registers households after making enquiry and issues a job card. The job card contains the details of adult member enrolled and his /her photo. Registered person can submit an application for work in writing either to Panchayat or to Programme Officer. The Panchayat/programme officer will accept the valid application and issue dated receipt of application, letter providing work will be sent to the applicant and also displayed at Panchayat office.
The End Users of NREGA consists of the following:-
Citizen – Citizen can access for Employment Status, Work Status, Financial Statement,
Available Fund at Each Level, Expenditure Statement for Works, etc. They can send their feedbacks/complaints and can also check the status of their complaints.
Panchayats – At Panchayat level one can make data entry for registration, creating new works etc and can generate there corresponding reports.
Workers - One can view Job Card, Demand for Job, Allocation of Job and Employment Given.
Implementing Agencies - Authorized users can make Data Entry for the New Works, Work Allocation, Muster roll etc.
Programme officer (PO) – One can register households and registered households can demand employment. PO can comment and send Projects to District Project Coordinator (DPC) for approval.
District Project Coordinator (DPC) - Programme Officer will issue the muster roll
for the approved work. District project Coordinator will sanction administrative,
technical and financial approvals for each work, and will also attend complaints
of Zilla Panchayat and Programme Officers.
States – One can directly make Data Entry and can generate corresponding Reports.
Administrator – One can Check details regarding Programmes, make Data Entry and
generate Reports.
Reports Required:-
State Level Reports
1. Employment Status
2. Work Status
3. Financial Statement
4. Available Fund at Each Level
5. Fund Transfer Statement
6. Fund Transfer Statement and Expenditure
7. Assets Created
National Level Reports
1. Employment Status
2. Work Status
3. Financial Statement
4. Available Fund at Each Level
5. Expenditure Statement for Works
6. Category wise Expenditure Statement for Works
7. Muster Roll
8. GP level Reports
Some Features of NREGA:-
Security and privacy
Authentication requirements for government solutions are significantly more stringent than those for typical business applications. The dealings of an individual with a business are less common than those of an individual with a government, since most of will have to apply for voter identity cards. Identity theft is only one of the problems that can be caused by poor authentication in eGovernance applications. The sheer volume of information that governments maintain on individuals makes privacy issues extremely important. Since NREGA application requires strong authentication processes, possibly involving multiple government agencies, it is imperative to offer authentication as a government-managed service in the NREGA infrastructure.
Properly layered structure
Software is in accordance with guidelines of scheme which follows a layered approach. Each layer is identified and managed according to the stakeholders needs so that proper management and analysis can be done. Panchayats can view their data in form of reports at their level. At block level all the reports of Panchayats under the Block can be viewed. At District
reports for the entire Block under the District can be viewed.
Separate role for each stakeholder
Stakeholders identified is as follows –
Citizen
Panchayats
Gram Panchayat
Block Panchayat
Zilla Panchayat
Workers
Implementing Agencies
District Programme coordinator (DPC)
Programme officer (PO)
States
Banks and post office
Administrator
Engineers
Enter schedule of rates
Cost Estimation
MB Book
Software is Unicode enabled
Software provides local language support which gives a good understanding of the process to all software users who are well conversant with there local language and make s/w more user friendly.
Available in online as well as offline mode
Software is available in online as well as Offline mode. States having Infrastructure for data entry in online mode are encouraged to work on online version. States with poor Network infrastructure are provided with offline mode
and their data get uploaded after a fixed interval.
Offline module is available in Microsoft technologies as well as open source technologies
NREGA soft offline version is available in Microsoft technologies as well as Open source technology which gives flexibility to the user of choose platform at his end. This makes Software more compatible with all platforms.
Linked with BPL Data 2002
Software is linked with family survey known as BPL census 2002 where information on rural household in rural area is available. It is a loose linking of two databases in the sense that if a family is found in that database then all the information regarding the persons in the family above 18 years of age can be copied to NREGA database but if a family is not found then it can be added into NREGA database.
Capturing Data at grass root level
Software facilitates entry of Works and workers at Gram Panchayat level.
User Friendly
Software is designed according to requirement of each stakeholder, and prerequisite for using this software is that a person must know Computer. Input forms and reports are designed in user friendly manner with local language support. Error reporting is also done to facilitate user to understand the problem and correct it.
SYSTEM STUDY
EXISTING SYSTEM
Present Manual System
Request for employment is given by the applicant verbally or in writing containing the information of the family members willing to do unskilled work.
All the data is manually entered into computer at the block level from where the after verification approval is given and job card is issued.
Manually attendance is taken at the worksite and entered into muster roll and this muster roll is manually send to the block level for entry into the data base and preparation of wages. This being time consuming exercise which results in delay in wages to workers.
Also as most of the time payment is made in cash, it takes time for the manual disbursement of salaries in cash to the workers.
Shortcomings of Present System
There is no method to stop / check multiple enrollment of same person in the system.
It is difficult to monitor that after enrolled person get employment within 15 days as per the Act.
It is impossible to keep check on the proxy workers.
It is difficult to ensure that payment reaches rightful beneficiaries.
Manual maintenance of muster roll at each of the jobsite and updating of the same in the central block level computer is in itself is a challenging task. This requires lot of traveling between jobsites Gram Panchayat and blocks etc. by the programming officer.
The system is prone to intentional or unintentional manual errors. As this muster roll plays the most important role in the whole system.
NREGA is countries one of the biggest social welfare schemes implemented at the ground level across the length and breadth of the county. For effective implementation of this scheme an extensive fool proof monitoring solution is required. For this there has to be solution which is fully secured, affordable and could be easily implemented.
To address to this requirement HCL Infosystems Ltd. had come up with a fool proof, affordable and easy to implement Biometric E-Job card & Handheld Device Based Solution for NREGP. This is a solution which can be actually implemented on the ground level without much dependency on computer literate manpower.
PROPOSED SYSTEM
Solution:
To address to these problem finger print based biometric E-Job card and hand help device with remote updating facility is proposed. This solution would help in timely monitor of the projects on daily bases; update the central data remotely without any manipulation and disbursement of funds in time.
Proposed Scope of the Solution:
Registration Process:-
NREGA-01: Applicant approaches the Gram Panchayat office and submits application for registration under NREGA scheme on plain paper or any other means, containing the information of those adult members of the family who are willing to do unskilled work or an individual may appear personally.
NREGA-02: Verification of application data like residential address, applicants are the adult member of the family etc. This have to be done within fortnight after the application is received at Gram Panchayat. Then his/her photo and finger print will be taken.
NREGA-03 After the verification the gram panchayat will enter the particulars in the system at the gram panchayat.
NREGA-04 Assigning a unique registration number to the registered household at Gram Panchayat.
NREGA-05 Copies of the registration will be sent to Programming officer for planning, tracking and recording and then those are forwarded to bock and then to district level and above.
NREGA-06 If a person submitted incorrect information. In such cases the gram panchayat will refer the matter to the Programming Officer. The Programming Officer after verifying all data for such persons will issue a list of such persons publicly and present to the gram shabha.
NREGA-07 The gram panchayat will issue e-Job cards to every household.
NREGA-08 A door- to door survey may also be done to identify persons willing to register under the Act. For this purpose the team can be provided by gram panchayat, also the President will head the team.
Registration Process Work Flow
TECHNOLOGY USED
Java
Java is a pure object-oriented language. Java was designed to be easy for professional programmer to learn and use efficiently. Java inherits the C/C++ syntax and the object-oriented features of C++. Java can be used to create two types of programs-applications and applets.
An output of a Java compiler is not executable code. Rather, it is a byte code. Byte code is a highly optimized set of instruction that is designed to be executing by the Java Run-time system, which is called the java virtual machine. Translating a java program into byte code helps makes it much easier to run a program in a wide variety of environments. Because the execution of every java program is under the control of JVM, the JVM can contain program and prevent it from generating side effects outside of the system. The use of byte code enables the java run-time system to execute programs much faster.
Benefits of using Java
Java is Secure. Java achieves the protection by confining a java program to the java execution environment and not allowing it to places extraordinary demands on a page, because the programs must execute reliably in a variety of system. The hard-to-track-down bugs are simply impossible to create in Java.
Java is multithreaded. Java was designed to meet the real-world requirement of creating interactive, networked pages. To accomplish this, Java supports multithreading programming, which allows you to write pages that perform multiple tasks simultaneously.
Java is dynamic. Java programs carry with them substantial amount of run-time type information that is used to verify and resolve accesses to objects at run time. This makes is possible to dynamically page link code in a safe and expedient manner.
Java’s exception handling. Java’s exception handling avoids the problem of checking errors and handling them manually and brings run time error management into object-oriented world. Access to other parts of the computer. Java programs can be dynamically downloaded to all the various types of platform. Thus, it is portable.
Java is robust. It is a strictly typed language; it checks your code at compile time. However, it also checks your code at run time. Thus the ability to create robust program was given high priority in the design of java. The multi-platform environment of the web
Java Server Pages
Java Server Pages (JSP) is a technology based on the Java language and enables the development of dynamic web sites. JSP was developed by Sun Microsystems to allow server side development. JSP files are HTML files with special Tags containing Java source code that provide the dynamic content.
The first thing to understand about Java Server Pages is that it's a natural extension to the Java Servlet technology. In fact, after some preprocessing by a translator, JSP pages end up being nothing more than Java servlets. This is a point that many beginning developers have a hard time understanding. JSP pages are text documents that have a .jsp extension and contain a combination of static HTML and XML-like tags and scriptlets. The tags and scriptlets encapsulate the logic that generates the content for the pages. The .jsp files are preprocessed and turned into .java files. At this point, a Java compiler compiles the source and creates a .class file that can be executed by a servlet container. The translator that turns the .jsp file into a .java file takes care of the tedious work of creating a Java servlet from the JSP page. Figure 1-2 illustrates how a JSP page is translated and compiled into a servlet.
JSP page is translated and compiled into a Java servlet
JSP technology has become an extremely popular solution for building web applications using the Java platform. JSP offers several advantages over its competitors:
JSP is a specification, not a product. Developers are able to choose a "best of breed" approach.
JSP pages are compiled, not interpreted, which can lead to better performance.
JSP pages support both scripting and access to the full Java language and can be extended through the use of custom tags.
JSP pages share the Write Once, Run Anywhere™ characteristics of Java technology.
As mentioned in the previous section, one of the limitations of using hardcoded HTML inside of servlets is the problem of separating page design and application logic programming responsibilities. This separation is easier with JSP pages, because the HTML designers are free to create web pages with whatever tools they choose (many of today's popular tools are capable of working with JSP and custom tags). When they are comfortable with the page layout, the JSP developers can insert JSP scriptlets and custom tags and save the files with a .jsp extension. That's pretty much all there is to it.
When the time comes to change the page layout or page logic, the developer modifies the JSP page as needed and allows it to be recompiled automatically. Together, JSP pages and servlets are an attractive alternative to other types of dynamic web programming. Because both are based on the Java language, they offer platform-independence, extensibility into the enterprise, and, most importantly, ease of development.
JSP Scriptlets or Tag Libraries?
Many developers believe custom tags, rather than scriptlets or expressions, should be used
in JSP pages. The rationale is:
Scriptlets mix logic with presentation.
Scriptlets break the separation of roles.
Scriptlets make JSP pages difficult to read and maintain.
Custom tags, on the other hand, centralize code in one place and help maintain the separation of responsibilities. They also support the concept of reuse, as the same tag can be inserted into multiple pages while the implementation resides in a single location. There also is less redundancy and potential for copy-and-paste errors with custom tags.
JSP Model 1 and Model 2 Architectures
The early JSP specifications presented two approaches for building web applications using JSP technology. These two approaches were the JSP Model 1 and Model 2 architectures. Although these terms are no longer used in the JSP specification, they still are widely used throughout the web tier development community. The two JSP architectures differ in several key areas. The major difference is in how and by which component the processing of a request is handled. With the Model 1 architecture, the JSP page handles all of the processing of the request and is responsible for displaying the output to the client.
Figure 1-3. JSP Model 1 architecture
Notice that there is no extra servlet involved in the process. The client request is sent directly to a JSP page, which may communicate with JavaBeans or other services, but ultimately the JSP page selects the next page for the client. The next view is determined based on either the JSP selected or parameters within the client's request. In contrast, in the Model 2 architecture, the client request is first intercepted by a servlet, referred to as a controller servlet. This servlet handles the initial processing of the request and determines which JSP page to display next. This approach is illustrated in.
As shown in the figure, a client never sends a request directly to a JSP page in the Model 2 architecture. This allows the servlet to perform front-end processing, including authentication and authorization, centralized logging, and help with internationalization. Once request processing has completed, the servlet directs the request to the appropriate JSP page. How the next page is determined varies widely across different applications. For example, in simpler applications, the next JSP page to display may be hardcoded in the servlet based on the request, parameters, and current application state. In more sophisticated web applications, a workflow/rules engine might be used. As you can see, the main difference between the two approaches is that the Model 2 architecture introduces a controller servlet that provides a single point of entry and encourages more reuse and extensibility than the Model 1 approach. With the Model 2 architecture, there is a clear separation of the business logic, presentation output, and request processing. This separation often is referred to as a Model-View-Controller (MVC) pattern. While the Model 2 architecture might seem overly complicated, it actually can simplify an application greatly. Web applications built using the Model 2 approach generally are easier to maintain and can be more extensible than comparable applications built around the Model 1 architecture.
Struts Architecture Overview
This section presents a high-level architectural view of a Struts application. Although this section shows architecture for an enterprise application, not all applications written using Struts will be of this size and makeup. However, this type of application does allow us to present many facets of how Struts applications may be configured. Many applications—especially J2EE applications—can be described in terms of their tiers. The application's functionality is separated across these tiers, or functional layers, to provide separation of responsibility, reusability, improved scalability, and many other benefits. The separation of tiers may be a physical separation where each is located on a separate hardware resource, or it may be purely logical. In the latter case, one or more tiers are collocated (i.e., arranged or grouped together) on the same hardware resource and the separation exists in terms of software.
Figure 2-1 illustrates the tiers that may be used by a typical Struts application.
Not every Struts application will contain all of the tiers illustrated in Figure 2-1. For many smaller applications, the middle tier may consist primarily of a web container that interacts directly with a database in the enterprise information system (EIS) tier.
What Is a Container?
There are many different types of containers—EJB containers, web containers, servlet Containers and so on. In general, containers provide a hosting environment for software Components to run in. Containers provide general services that the components within the environment can use, so that the component developers don't have to worry about providing these services. A web container allows servlets, JSP components, and other Java classes to be deployed and executed within the container. Services such as the Java Naming Directory Interface (JNDI), connection pooling, and transaction services can be configured at the container level—similar to the way in which EJB containers manage security, transactions, and bean pooling—and the component developers don't have to worry about managing these resources. When using the services provided by a container, component developers may have to give up some control of the environment to the container. Third-party vendors, who must follow certain guidelines that are explicitly laid out in public specifications, build these containers. Although each vendor is allowed to implement certain portions of the container in a proprietary manner, they must follow the specifications to ensure that applications are portable.
The Client Tier
The client tier provides a way for users to interact with the application. This interaction may be through a web browser or it may be programmatic, through a web services interface. Regardless of the type of client, the interaction includes submitting a request and receiving some type of response from the middle tier. In the case of the Struts framework, the most common type of client is a web browser. However, it is also possible to have clients such as wireless devices and Java applets.
The Web Tier
Figure 2-1 shows the middle tier as an aggregate of the web tier plus some type of application server component (in this case, an EJB container). These two tiers often are combined, and many application servers include web tier functionality.
The web tier allows the client tier to communicate and interact with application logic that resides in other tiers. In more traditional web applications, it's not uncommon for some or all of the application logic to reside in this tier. In larger, enterprise-scale applications, the web tier acts as a translator and maps HTTP requests into service invocations on the middle tier. The web tier also is responsible for managing screen flow based on application and user state. The web tier communicates with either a database or, in the case of an enterprise application, an application server. The web tier is the glue that binds client applications to the core backend business systems. The components that reside in the web tier allow developers to extend the basic functionality of a web service. In the case of Struts, it does this through framework components that run in a servlet container.
The Middle Tier
The middle tier is often referred to as the " application tier" or "server." This is due in part to the fact that there is often an application server within this tier. Not all Struts applications have an application tier. This is especially true for small web applications—many small projects forgo using a large application server and communicate directly with a database or some other data store. When an application server is present, the web tier communicates with it using some variation of Remote Method Invocation (RMI). If an EJB server is present in the application tier, the communication protocol is RMI over IIOP (Internet Inter-ORB Protocol).
What is an Enterprise Java Bean (EJB)?
Special type of “bean” bean - Just a Java class. Typically follows naming conventions for methods to create properties. May also implement class XXX BeanInfo to provide information about class.
Enterprise Java Bean is a bean designed to run inside an EJB server.
From the server, we get certain benefits. By the nature of the EJB and server interaction, we also have several limitations.
EJB is supplemented by a deployment descriptor: an XML file which provides the container with information about how the bean is to be deployed. Gerard C. Weather by Introduction Enterprise Java Beans
Why use Enterprise Java Bean?
EJB servers are expensive. Sun Reference Implementation (RI) is free -- and worth every penny! Don’t overspend on application tech
Best used where performance demands scale of application -- primarily transaction rate -- warrants.
For sites with less traffic, using HTML/JSP/servlets/beans with a database backend may be simpler, cheaper, and easier. Heidi J. C. Ellis and Gerard C. Weather by Introduction Enterprise Java Beans 6
EJB server characteristics
May be distributed over multiple hardware boxes Software manages -- location transparency
Provides services Naming Security Concurrency Transactions Persistence Distributed objects Asynchronous Messaging Interoperability Heidi J. C. Ellis and Gerard C. Weather by Introduction Enterprise Java Beans 8 Enterprise Java Bean roles
EJB specification defines five roles humans can play Enterprise Bean Provider – application domain expert who writes the Java code and the deployment descriptor. Work product is ejb jar files.
Application Assembler - assembles beans into larger units, perhaps with other components (e.g. JSP). Also produces jar files.
Deployer - installs the jar files in specific environment Note: Whether these roles, especially the first two, will be performed by different people is questionable.
Server provider - provides the environment to run EJBs in. (BEA, IBM, Sun. etc.) Gerard C. Weatherby Introduction Enterprise Java Beans
Container provider - provides the thing the server runs in. Note: As of EJB 2.0, there is no delineation of the interface between container and server. Right now, they’re one thing. We’ll consider container and server synonyms.
How does it work?
In general each EJB class you write interacts with other EJBs via interfaces. Clients (JSP or standalone) also interact with EJBs this way.
There is not a direct connection between calling code and the EJB implementation. The EJB server generates code which sits between client and EJB. This code is where the server implements the required services. Details necessary for the server to implement the code are contained in the deployment descriptor. Gerard C. Weather by Introduction Enterprise Java Beans.
What kinds of EJBs are there?
Entity Beans -- represent persistence objects, typically stored in a database. They can be Container managed -- meaning the server generates the necessary SQL to insert/update/delete data. Bean managed -- the programmer writes the necessary code
Session Beans -- represent an interaction or work process which lies on behalf on the client. They can be Stateless - no information is retained by the object between method calls Stateful - information is retained
Message Beans -- process Java Message Service (JMS) messages Heidi J. C. Ellis and Gerard C. Weather by Introduction Enterprise Java Beans
Types of interfaces
Entity and Session Beans can support two kinds of client Interfaces Home interfaces Used to create, find and destroy bean instances Obtained via a name (JNDI) Interface (business interface) Provides business logic API Obtained from home interfaces
Each type of interface has two versions Remote interfaces can be used anywhere Most flexible Gerard C. Weather by Introduction Enterprise Java Beans
Java Native Interface (JNI)
The Java platform is relatively new, which means there could be times when we will need
to integrate programs written in the Java programming language with existing non-Java language
services, API toolkits, and programs.
The Java platform provides the Java Native Interface (JNI) to help ease this type of integration.
The JNI defines a standard naming and calling convention so the Java virtual machine can locate and invoke native methods. In fact, JNI is built into the Java virtual machine so the Java virtual machine can invoke local system calls to perform input and output, graphics, networking, and threading operations on the host operating system.
JNI in programs written in the Java programming language to call any libraries (dll) on the local machine, call Java methods from inside native code, and explains how to create and run a Java virtual machine instance.
What is Native Method ?
Functions written in a language other than Java
They could be in C or C++
Get the report here:
http://4sharedfile/1NWU04Pg/MCA_Project_Report.htm
