Major Project Report

PROJECT REPORT ON CREDIT MANAGEMENT SYSTEM

SUBMITTED BY
ANIL KUMAR YADAV

Submitted in the partial fulfillment of the requirements for the degree of B.C.A

(BACHELOR OF COMPUTER SCIENCE) TO

SIKKIM MANIPAL UNIVERSITY DIRECTORATE OF DISTANCE EDUCATION

Server Components Programming Languages

EJB HTML, JSP, Java, JavaScript,Struts

Operating System Web Server Application Server Database Engine Server Network Processor

Linux 7.1, Windows XP Weblogic 7.0 J2EE-compliant application server Oracle 9i N-tier server centric environment that can scale to any number of servers P III, P IV

Preface

As with any project, documentation forms an integral part of this project too. Documentation plays a vital role in the Software Engineering Process in satisfying the future queries of the user and in the efficient maintenance of the application. Hence this report serves a detailed documentation for this system. It has been taken care that this document elicits the system development process in a lucid and an understandable manner. The contents have been divided into segments, all of which have been explained in detail in the following pages. I have tried my best to elucidate all the relevant details of the project to be included in the report. While in the beginning I have tried to give a general view of the project, to make it clearer, in the later stages I have included the portion that was specifically assigned to me and also describing where that part is actually being used.

Acknowledgement
Unless you venture into the real world you never know, how futile your efforts could be without the help of the various and, how tough the real world environment is. And even tougher work is enumerating and enlisting all the individuals whose contributions went into the making of this project. I am grateful to Tata Consultancy Services, for providing me with an opportunity to work with them and be an active team member of a project of such importance. I would like to especially thank Mr. Anand panday for without their continuous help and motivation this project would not have been possible. They always endeavored me towards learning and gaining knowledge and helped me at all stages of the project by spending his invaluable time and effort. Acknowledgements are also due to my parents, friends and all those people who have been continuous support to me in the successful completion of this project.

Index Contents Page No.

1.Background Information7 Profile of TATA CONSULTANCY SERVICES 2.Problem Description and Objectives.12 2.1. Project Overview..13 2.2. Objective of the Project..14 2.3. Brief Narrative of Work....15 2.4.Salient Features of the Project17 3.Statement of Scope10 3.1. Scope of the Project21 3.2. Contributions of the Project 22 4.Project Plan...24 4.1. Project Organization...25 4.2. Functional Modules....28

4.2.1. 4.2.2. 4.2.3. 4.2.4. 4.2.5. 4.2.6. 4.2.7.

Policy Credit Proposal Credit Appraisal Monitoring MIS Document Management System Role Based Security

4.3. Tools and Technologies.35

4.3.1. Bea Weblogic Server 7.0..36 4.3.2. Servlets.38 4.3.3. Java Server Pages...47 4.3.4. Enterprise Java Beans55 4.3.5. Oracle 9i...68

5.System Requirement Specifications72 5.1. Administrative Requirements..73 5.2. Tools and Technologies...77
5.2.1. 5.2.2. 5.2.3. 5.2.4. Software Requirements Hardware Requirements System Specification at Central site System Specification at Client site

6.Analysis and Modeling..79 6.1. Proposed System.80

6.2. Technical Architecture81 6.3. System Architecture....82 6.4. Application Architecture84 6.5. Error Analysis...88 6.6. Data Transfer and Communication..92 6.7. Input and Output Specification..94 6.8. Overview of Credit Operations101 7.Problem Assigned.103 7.1. Overview. . 7.2. Oracle Database Administration. 7.3. User Interface Design 7.4. Screen Design.. 8.Future Works.. 8.1. Future Scope of Development
6.5.1Front End Error Analysis 6.5.2Back End Error Analysis

9. Conclusions. 9.1 Conclusions Drawn

10. Appendix 10.1. Appendix A Acronyms 10.2. Appendix B Bibliography

1.1 Profile of TATA CONSULTANCY SERVICES

Profile
Tata Consultancy Services (TCS) is a part of the US$ 15 billion Tata group of enterprises. Established in 1968, Tata Consultancy Services (TCS) dynamic blend of strategy consulting and system integration services to help organizations architect and build their businesses in the global economy.
Indias top software exporter since 1968 Growth rate of 48.5% in 2000-01-revenue at Rs 4560 crores ($1 billion) Over 800 clients; 7 out of US Fortune Top 10 for 2000 are TCS clients More than 60,000 person years of experience Global spread of 106 branches in 30 countries Projects in 55 countries Fifteen development centers assessed at SEI CMM Level 5 Four centers at P-CMM Level 4 More than 1100 consultants qualified as Certified Quality Analysts (CQAs). End-to-end solutions through domain and technology expertise. Continuous enhancement of abilities through new service practices Global reputation in providing state of the art solutions to complex problems Innovative products Expanding capabilities through research and academic relationships with various universities across the world

Consistently doubling its revenue every two years, TCS revenue for 2000-01 stood at Rs 4560 crores ($1 billion). It achieved a growth rate of 48.5% - a growth fuelled by a cumulative experience of more than 60,000 person years across diverse technology areas and business domains, enabling TCS to offer end-toend consulting and IT solutions to more than 800 clients, across 55 countries.

Research & Development

TCS offerings are backed by its investment (over 4% of its revenues) in Research and Development in cutting edge technology. Its software tools foundry at Tata Research Development and Design Center, Pune is one of the most advanced in the world. TCS also has research alliances with several world-renowned universities, such as the

University of California at Riverside and San Diego, the Indian Institutes of Technology (IIT), and the Rotterdam School of Management.

People
Over 22,000 consultants form the backbone of the TCS mission, coming from the best universities and institutions in the world. At TCS technology specialists and business management experts share expertise to gain a thorough insight into the clients business, and look for innovative ways to apply technology for lasting solutions.

Quality
With fifteen of its centres, and one of its joint ventures companies, assessed at Level 5 - the highest level in the Carnegie Melon SEI Capability Maturity Model scale, more consultants over 12,800 work at SEI-CMM level 5 quality, than in any organization in the world. From these locations, TCS provides several Fortune 500 clients 24x7 software support and IT outsourcing through client-dedicated offshore Global Development Centres. TCS also has several Competency Centers where technologists develop expertise in niche areas of technology and business domains. In August 2001, TCS became the first organization in the world to be assessed at P-CMM Level 4.

Alliances
TCS increases the diversity of its offerings through strategic alliances and joint ventures with global leaders in technology and eBusiness, such as BEA, Netscape, Microsoft, Macromedia, SAP, McKinsey & Co. and Compaq to name a few. TCS is also a founder member of the Internet Security Alliance (ISA) and a member of the Universal Description, Discovery and Integration project (UDDI), through which it works with world technology leaders for enhancing Internet security and usability.

Industry and Service Practices

TCS brings to this professional relationship expertise in the area of System Solution through a tight integration of its Industry Practice (IP) and Service Practice (SP) Groups.

Industry Practice
Banking, Financial Services and Insurance (BFSI) Telecom Manufacturing and Process Industries Transportation Healthcare Utilities Others (Government, Technology, Companies, Media, Tourism, etc.)

Service Practice
E-Business: Business Intelligence, CRM, ERP, Supply Chain Management, Internet Services, Groupware. Application Development and Maintenance: Re-engineering, Euro Currency, Multimedia, Visual Computing, Image Processing, GIS. Engineering Services: CAD, CAM, CAE, Real Time Systems and Process Controls Computer Security: Audit, Implementation and Design, Security Architecture Large Projects: Project Management, Planning and Delivery Infrastructure Development and Management: (Formerly Outsourcing and Systems Integration)

Banking
TCS commands a comprehensive array of products, project implementation skills, expertise and experience in implementing third party solutions, covering the entire logistics of the banking industry. TCS has worked with some of the best banks worldwide, providing them mission-critical solutions and services for more than two decades.

Consulting and Research

TCS offers consulting and research services in the following areas: Management consultancy and business process reengineering Management information systems and decision support systems Management audit Systems audit Research on credit and non-performing assets (NPA) Risk management (both credit and market risk) Costing Balanced score card and performance management Organizational development & restructuring IT strategy consultancy

Service Areas
TCS also offers various services to the banking industry in realizing operational solutions. e-Banking and e-commerce solutions Application software design, development, implementation, training and support in the areas of retail banking, wholesale banking, and treasury Integration with a variety of electronic delivery channels like ATM, tele-banking, internet, mobile banking and call center operations Facilities management, outsourcing and system integration services Performance measurement, review and tuning services Real-time gross settlements (RTGS), payment gateways

2.1 Project Overview

Project Name Organization Name Client Name Project Type : : : : Credit Management System TATA Consultancy Services LEADING INDIAN BANK Development Project Large Project Ms. Shyamali Basu Mr. Ashok Avasthi

Project Categorization : Group Leader Project Leader : :

2.2 Objective of the Project

CMS is a web-based credit solution. The system has been developed using J2EE Technology and TCS proprietary tool Master Craft and runs in Windows NT Environment and using Oracle as a database. The objective of the project is to carry out the customization of the existing product and enhance the functionality to meet the requirements of the LEADING INDIAN BANK. CMS would help the client to meet its objectives of better credit quality and faster turnaround time for credit applications thus increasing the credit portfolio of the Bank and providing customer satisfaction. Other Objectives include To fulfill the market need of a web-enabled thin client Credit Management System. Make non-technical users to understand and modify business process. Decrease time and cost of initial implementation. Customizable, independent applications and components.

2.3 Brief Narrative of Work

Quality of Credit in banks suffers due to: Poor and inadequate appraisal & review mechanism Lack of follow up & monitoring Delayed and inaccurate MIS The clients will log on to the site and will be able to apply for the loans online. The procedure for the bank will follow the stages listed below: I. II. III. IV. V. VI. Borrower Proposal Appraisal Sanction/Rejection Monitoring Follow up

The borrower will come with an application for loan. The bank will process it and will make a proposal for it. After that the bank will appraise the borrower and his assets according to banks own rules and regulations. Depending upon the result of Appraisal the proposal will be either sanctioned or rejected. The bank can at any stage ask for further documents to be provided by the borrower. If the borrower is able to satisfy the bank with the proofs the bank will move ahead. All these things will be handled by the system itself. CMS is a Credit Management System that meets the requirements of the Credit Administration Department of Sri Lankan banks and banks in the Asia Pacific Region and thus has a great market potential.

Therefore the customization of CMS has to be carried out with promoting and expansion in mind. Design facilitating multi-lingual feature. Incorporation of Multi-Currency. Design of generic workflow: The application would consist of workflow only for the appraisal process. However, the design would be such as to facilitate its expansion into a full-fledged workflow based product.

2.4 Salient Features

Modular Approach The system is modular and its modules are seamlessly integrated. Various modules of CMS are as follows: Credit Policy & Guidelines This module automates the functions of the Credit Policy Cell of the Credit Department at the Head office i.e. to decide upon the credit sanctioning policies of the bank. It captures the Norms and Guidelines, Banks Master, ECGC (Export Credit Guarantee Corporation) Caution List, Defaulter List and Central Bank caution list to create the various policy masters. It also involves defining various loan facilities and credit schemes provided by the bank, interest rates, recommended financial ratios, industrial classification, types of securities, criteria for borrower rating, methods that can be used for computing the working capital finance requirements of a borrower and various fees like processing fee, up-front fees, lead bank fees. The key function of this module is to maintain a database of Banks policies Credit Appraisal This module covers the major function of the credit department i.e. to sanction loans falling under its discretionary powers as per the banks credit policy. It allows user to process credit proposal received from a borrower, credit appraisal and capturing the credit decision of sanction or

rejection of the loan followed by preparation of relevant letters and advises. It involves trend analysis of the past performance, and analysis of the future prospects based on financial statements of the borrower, and using financial tools like ratio analysis, fund flow analysis and credit sanction models. The key functions of this module are: Borrower profile Proposal Appraisal Credit Decision

Credit Monitoring Credit Monitoring involves post-sanction follow-up of loans and credit facilities and assertion of the status of the borrower. The sanctioning authoritys monitoring is based on various documents and reports like BCC (Branch Compliance Certificate), MOR (Monitoring Officers Report), QIS (Quarterly Information System), CA stock verification report, post-sanction visit reports, which are submitted by the branches. The dealing officer scrutinizes these and obtains clarifications from branches in case any irregularity or non-compliance is observed. The key functions of this module are: Borrower Monitoring Loan Audit Cell Documents Management System (DMS) This module is responsible for preparation of requisite documents, which are issued to the customer or are to be maintained by the bank itself. The key functions of this module are: Creation of documents Maintenance of documents

MIS This module has functions, which capture the branch data to generate quarterly, half-yearly and yearly statutory and regulatory reports related to Credits, Rural Development, Off Site Surveillance and Recovery & Law. This is followed by consolidation of various branch reports at RO and then finally at HO to generate various MIS and RBI reports. This module has to provide following types of reports Statutory Control Statistical Simple Functional Interface for the User The data entry screens displayed are simple and easily understandable, with Graphical User Interface (GUI). The system has been developed keeping in mind that the users may not be well acquainted with usage of computers. That is why a simple menu driven Graphical user interface has been provided. Context Sensitive help is also available at each page so that user can easily understand the usage and functionality of each screen. Several Decision Support Tools for Credit Appraisals The system offers several decision support tools for credit appraisals, which enhances the speed and quality of the appraisal and decision-making. Some of these are mentioned below. Rating and Pricing Ratio Calculations Functional Validations Re-Computation of financial analysis based on Banks assessment Sensitivity Analysis

 Reduces the drudgery of making multiple reports based on repetitive data. Based on one time data received from branches on two standard formats. Addresses issues relating to quality of data and delays in manual preparation of MIS.

3.1 Scope of the Project

Corporate Credit Management System would help Banks to meet its objectives of better credit quality and faster turnaround time for credit applications thus increasing the credit portfolio of the Bank and providing customer satisfaction. Credit Management Solution provides for follow-up action for nonreceipt or delayed receipt of reports and review of reports by higher officials. Helps the bank in creating and tracking credit information regarding irregularities with regard to conduct, performance and compliance of each account based on feedback from the branches. This information can give invaluable early warning signals and bank can take mid course corrective and preventive actions.

3.2 Contributions of the Project

Standardization of Processes The project provides Standard formats for application/appraisal note. It helps in easy Bank-wide dissemination of management policies. It enables on-line availability of policies and circulars of the bank. Improved Credit Quality Calculation of ratios for ratio analysis is made convenient. It makes available financial tools like Capital Budgeting, Sensitivity Analysis calculation are performed by the software. Availability of Checklists Facility to recast borrowers projection with automatic calculation of all dependencies On-line availability of monitoring information Financial analysis in the form of decision support questions Availability of Credit Rating Model Improved productivity Automatic Generation of Appraisal Note and Letters.

Automated financial calculations. On-line availability of defaulters list during appraisal. Automated generation of MIS. Automated tracking of irregularity & non-receipt of reports. Better Management Control Availability of data for analysis and policy formulation. Timely MIS. Rigorous monitoring.

The project will create a better and more efficient environment for the end user as well as for the bankers. There will be a single repository of data from where the information can be shared by Regional, Zonal and Branch offices of the banks. Banks are eagerly anticipating such a system which means, they are also very much looking forward to install a system like CMS. The system is committed to change the way loans are disbursed. A user can access his account at any time and get his status updated.

4.1 Organization of the Project

The system is organized into the following modules: 1. Policy This module automates the functions of the Credit Policy Cell of the Credit Department at the Head office i.e. to decide upon the credit sanctioning policies of the bank. It captures the Norms and Guidelines, Banks Master, ECGC (Export Credit Guarantee Corporation) Caution List, Defaulter List and Central Bank caution list to create the various policy masters. It also involves defining various loan facilities and credit schemes provided by the bank, interest rates, recommended financial ratios, industrial classification, types of securities, criteria for borrower rating, methods that can be used for computing the working capital finance requirements of a borrower and various fees like processing fee, up-front fees, lead bank fees. 2. Credit Proposal This module covers the major function of the credit department i.e. to sanction loans falling under its discretionary powers as per the banks credit policy. It allows user to process credit proposal received from a borrower, credit appraisal and capturing the credit decision of sanction or

rejection of the loan followed by preparation of relevant letters and advises. It involves trend analysis of the past performance, and analysis of the future prospects based on financial statements of the borrower, and using financial tools like ratio analysis, fund flow analysis and credit sanction models. 3. Credit Appraisal This Module deals with handling of sanction or rejection of proposals that have been approved. Each appraisal results in a credit decision. The credit decision could be sanction or rejection. The system can accord sanctions of various types: Fresh : These are accorded for new borrowers/ projects. Renewal : These are accorded to the existing borrowers without increase in banks exposure Renewal-cum-Enhancement : These are also accorded to the existing borrowers with increase in banks exposure Reduction : These are accorded to the existing borrowers with decrease in banks exposure Reschedulment : In this case the loan repayment schedules are changed or altered. 4. Monitoring Credit Monitoring involves post-sanction follow-up of loans and credit facilities and assertion of the status of the borrower. The sanctioning authoritys monitoring is based on various documents and reports like BCC (Branch Compliance Certificate), MOR (Monitoring Officers Report), QIS (Quarterly Information System), CA stock verification report, post-sanction visit reports, which are submitted by the branches. The dealing officer scrutinizes these and obtains clarifications from branches in case any irregularity or non-compliance is observed. 5. MIS Report This module has functions, which capture the branch data to generate quarterly, half-yearly and yearly statutory and regulatory reports

related to Credits, Rural Development, Off Site Surveillance and Recovery & Law. This is followed by consolidation of various branch reports at RO and then finally at HO to generate various MIS and RBI reports. 6. RBS (Role Based Security) This module is responsible for the security of the system. All users should not be allowed access to entire database. Each user is assigned a User ID and a password along with the access rights. RBS module maintains a database of these users and their roles and checks whether the user is authorised for a particular access or manipulation operation.

7. DMS (Document Management System) This module is responsible for preparation of requisite documents, which are issued to the customer or are to be maintained by the bank itself. The entire procedure of credit management starting from customers proposal, to sanction of loan including appraisal and financial analysis requires a lot of documents to be maintained. All these documents are created and managed by DMS module.

4.2 Functional Modules

Loan Applications
B O R R O W E R S

Sanction

Appraisal Credit Decision Sanction/ Rejection POA Sanction

OPERATIONS

O P E R A

Policy Norms

Monitoring Monitoring reports Loan audit cell

Monitoring Reports Position of Account

T I O N S

Monitoring

Asset Classification

MIS

(Functional architecture of CMS at a glance)

The above figure depicts the interaction of various modules in CMS. the borrower along with the financial details first submits a loan application. The system enters the appraisal module. After analysis, a credit decision is made (sanction/rejection). While taking a decision, the policy norms are taken into consideration. This is where policy module is needed. After issuing the sanction letter, monitoring phase begins, in which the financial activities of customer are monitored. During all these phases documents are created and maintained. 4.2.1 Credit Policy Credit policy encapsulates norms, guidelines and benchmarks based on guidelines provided by Reserve Bank Of India and the Banks own policies and guidelines. These are used by the system at the time of assessment of limits or for monitoring or generation of MIS. These are maintained at the Head Office and can also be used at any site where CMS is installed. Centralized Maintenance at HO
Guidelines & Circulars

Policy

Guidelines Policy replication BO Norms Policies & guidelines for Appraisal, Monitoring, MIS

Banks guidelines and Benchmarks

Benchmarks Circulars

Defaulter lists Banks Caution lists ECGC

(Schematic diagram showing policy maintenance and utilization)

RBI guidelines and circulars are gathered and stored in the database along with the BANKs own policies and Benchmarks. These act as guidelines for Appraisal, monitoring, MIS, etc. Defaulters list and Caution list maintained by monitoring the performance of customer and checking it against the policy benchmarks.

4.2.2 Credit Appraisal Credit Appraisal addresses assessment of credit needs of the borrowers who deal with the bank. It supports proposal handling and sanction of regular, ad-hoc, renewal and enhancement of limits.
Loan Application

Borrower Profile

Proposal Details

Decision Credit

Appraisal / Assessment

Credit Rating

Functional capabilities of the appraisal Policy Details module are detailed below: Handling of different types of proposals towards sanctioning of fund based/non-fund based facilities: Working Capital requirements Term Loan requirements Composite Loan requirements Different types of business activities for which appraisals can be undertaken: Manufacturing Trading Manufacturing & Trading Leasing & Hire-Purchase

Specialized Appraisals Ship Breaking Sugar/Tea/Construction Term Loans

 Export Different Methods of Lending like: Turnover Method First Method Second Method Cash Budget Methods

Types of Sanctions Fresh Renewal Renewal-cum-Enhancement Reduction

CMS can also handle the following In-principle Approvals Validity Extensions Confirmation of Actions Follow up mechanism for: Renewal and review of accounts Adjustment of adhoc/additional limits Validity extensions Submission of proposal for in-principle approval

Aids for Credit Appraisal: On-line availability of Benchmarks, Guidelines, Norms & Guidelines Financial Tools & Techniques Break-even Analysis Capital Budgeting Sensitivity Analysis Provision to calculate Standard and Additional Ratios

 Borrower rating for existing cases based on the pre defined parameters Search in Defaulters & Caution Lists Cash Budget Methods for industries like tea, sugar etc. Check list of documents needed for appraisal On line availability of loan covenants Group exposures & prudential exposure monitoring Monitoring Details Credit Rating as a tool for borrower Appraisal and Pricing. Focus Questions to aid credit officer see deviations in values of important financial indicators. Capture of Credit Decision Sanction Rejection Raising of queries Appraisal note with least typing effort: Availability of previous data for renewal Executive Summary Process notes for: Regular sanctions and renewals In-principle approvals Validity extensions Confirmation of actions Adhoc /additional limits Electronic Approval of Appraisal Note. Generation of Sanction/Rejection Letters and Reminders etc. Handling of Amendments of Sanctions/Stipulated Terms & Conditions.

4.2.3 Credit Monitoring Credit Monitoring provides for the follow up mechanism after the limits are sanctioned. It is based on both off-site and on-site reports and feedback (Monitoring officers report, Visit report).

Branch
Track Irregularities Review Reports Variance Analysis Seek Clarifications Generate Reminders

RO
Track Irregularities Review Reports Variance Analysis Seek Clarifications Generate Reminders

HO
Track Irregularities Review Reports Variance Analysis Seek Clarifications Generate Reminders

(Flow of monitoring process and activities) Borrower accounts are monitored for their conduct after a loan has been sanctioned. Some periodic reports / information are received from the borrowers based on the BANK specific guidelines. Bank should be able to assess the health of the borrower account using this information. The system generates reports in the form of letters for the following: a. Non-receipt of information b. On review comments for clarifications raised by the reviewer c. On variance analysis made by the system. Further, borrower accounts are also monitored based on internal follow up of the bank. This follow up is undertaken based on various internal reports, reviews and follow up measures, like stock verification by CA & banks officials, visit reports etc. The system

generates reports in the form of letters for non-receipt of information and based on review comments. Monitoring of sanctioned limits based on the financial details submitted by the borrowers in following statutory forms: QIS I QIS II QIS III Follow up based on internal reports of the Bank: CA Stock Verification Compliance Reports like, Branch Compliance Certificate for a sanction Monitoring Officers Reports Visit Reports Position of Account outstanding amounts due/overdue In the system, areas of irregularities can be maintained which can be linked to bank defined irregularities. For each of the internal report, the irregularities are specified and the reviewer can specify review remarks. The system tracks irregularities/clarifications and reviews comments . Generation of letters and reminders for CMS user of irregularities and clarifications. Loan Audit Cell Review of appraisals made / loans sanctioned by branch offices under their discretion by the higher office Generation of letters and reminders from BO/HO seeking clarifications. 4.2.4 Credit MIS

Over two hundred reports are generated for credit department including priority sector and recovery reports. These reports are meant for control, top management and for statutory reporting.

Control
Overdue Loan Proposals Proposal/Dispos Registe al rs Statement of Irregular Standard Accounts

Top Mgmt

Credit Reports

MI S

Statutory
Reports

Other Departmental Report s

Discretio n Consortiu Register R egist m er

(Type of MIS, which can be generated using CMS)

4.3 Methodology
Software Engineering Model Used- RATIONAL UNIFIED PROCESS The Rational Unified Process (RUP) is an iterative software development framework that enhances team productivity and promotes team unity by delivering software best practices to all team members. The RUP standards make it easier to manage the development and deployment of our Business Internet Solutions, allowing us to achieve faster time-to-market with new products and services.

R E C O V PE RR I y O R I T y

Rational Unified Process (RUP) is an object-oriented and Webenabled program development methodology. RUP and similar products such as Object-Oriented Software Process (OOSP), and the OPEN Process - are comprehensive software engineering tools that combine the procedural aspects of development (such as defined stages, techniques, and practices) with other components of development (such as documents, models, manuals, code, and so on) within a unifying framework. RUP establishes four phases of development, each of which is organized into a number of separate iterations that must satisfy defined criteria before the next phase is undertaken: in the inception phase, developers define the scope of the project and its business case; in the elaboration phase, developers analyze the project's needs in greater detail and define its architectural foundation; in the construction phase, developers create the application design and source code; and in the transition phase, developers deliver the system to users. RUP provides a prototype at the completion of each iteration.

Architecture of the RUP The process has two structures or, if you prefer, two dimensions: The horizontal dimension represents time and shows the lifecycle aspects of the process as it unfolds. The vertical dimension represents core process disciplines (or workflow) that logically group software-engineering activities by their nature. The first (horizontal) dimension represents the dynamic aspect of the process expressed in terms of cycles, phases, iterations, and milestones. In the RUP, a software product is designed and built in a succession of incremental iterations. This allows testing and validation of design ideas, as well as risk mitigation, to occur earlier in the

lifecycle. The second (vertical) dimension represents the static aspect of the process described in terms of process components: activities, disciplines, artifacts, and roles.

(Two Dimensions of the RUP)

4.3.1 Bea Weblogic Server 7.0 Weblogic server is an industrial-strength implementation of the J2EE platform suitable for developing high-volume, dynamic web sites and enterprise applications. It gives developers unmatched flexibility in how they design, implements, and deploys these systems on their corporate networks. Weblogic provides exhausted support for all aspects of the J2EE standard; making it easy to build Web and Enterprise applications that connect to databases, mail systems, messaging systems, CORBA-based systems, and legacy systems on a variety of platforms. Extensive

security features are built into Weblogic so you can tightly control access to applications, web sites, and resources contained within them. Companies around the world use Weblogic to solve a surprising array of difficult computing problems. Weblogic and J2EE make it remarkably easy to build applications that seamlessly integrate data and computing resources from all corners of your organization. The Weblogic environment After installing Weblogic, start the server by typing the command startweblogic at the command prompt. After the server is up and running, start the Weblogic console in the browser. Here we can create domains, data sources and JDBC Drivers. Weblogic Server Directory Structure: The following figure shows the directory structure of the Weblogic installation. At the top level is the bea directory. Within this directory are the directories containing JDK, installation logs and java utilities as described below:

Figure: Weblogic directory Structure Directory

jdk CMS applications DefaultWebApp classes Other directories

Contents
Contains the java development kit. Domain created for deploying the project. This folder contains the .jar files i.e. the java archive containing the EJB class files and deployment descriptors. This folder contains the GUI components i.e. the JSPs and HTML files. This folder contains the servlets. They contain the necessary java files, utilities and Weblogic library files and JARs needed by the application.

JDBC Drivers: One of the most common uses of Weblogic server is to Webenable data residing in relational database management systems (RDBMSs), such as Oracle. New driver can be configured through the Weblogic console. Here we first create a connection pool by specifying the URL of the database server. Then we create the Data Source using this connection pool. After creating the domain and configuring the data source the server is ready for deploying applications. 4.3.2 Servlets Java Servlet Technology As soon as the Web began to be used for delivering services, service providers recognized the need for dynamic content. Applets, one of the earliest attempts toward this goal, focused on using the client platform to deliver dynamic user experiences. At the same time, developers also investigated using the server platform for this purpose. Initially, Common Gateway Interface (CGI) scripts were the main technology used to generate dynamic content. Although widely used, CGI scripting technology has a number of shortcomings, including platform dependence and lack of scalability.

To address these limitations, Java servlet technology was created as a portable way to provide dynamic, user-oriented content. A servlet is a Java programming language class that is used to extend the capabilities of servers that host applications access via a request-response programming model. Although servlets can respond to any type of request, they are commonly used to extend the applications hosted by Web servers. For such applications, Java Servlet technology defines HTTP-specific servlet classes. The javax.servlet and javax.servlet.http packages provide interfaces and classes for writing servlets. All servlets must implement the Servlet interface, which defines life-cycle methods. When implementing a generic service, you can use or extend the GenericServlet class provided with the Java Servlet API. The HttpServlet class provides methods, such as doGet and doPost, for handling HTTP-specific services.

The Servlet Life Cycle The life cycle of a servlet is controlled by the container in which the servlet has been deployed. When a request is mapped to a servlet, the container performs the following steps : 1) If an instance of the servlet does not exist, the Web container a. Loads the servlet class. b. Creates an instance of the servlet class. c. Initializes the servlet instance by calling the init method. 2) Invokes the service method, passing request and response objects. If the container needs to remove the servlet, it finalizes the servlet by calling the servlet's destroy method. Hence servlets have a welldefined life cycle.

A servlet goes through a three stage life cycle: Initialization Service Destruction
Failure Create Success Success Initializ e Failure

Available (Servicing Requests) Destroy request Destro y

Unavailable

Unload

Figure: The servlet life cycle

Initialisation The servlet container loads servlets either at server startup or when they are accessed (dynamically). Many of the application servers contain a way of specifying which servlets are loaded at startup. After a servlet class is instantiated, the container creates the servlet configuration ServletConfig object that can be optionally passed as a parameter to the init() method.You can override the no-argument init() method if you need to perform startup tasks such as opening database connections, creating session objects, finding naming services and so on.

If the initialization is successful, the servlet is available for service; otherwise, the process will throw ServletException or UnavailableException. Service After initialization, the container invokes the service() method, passing a request and response object. The main purpose of the service() method is to get information from the HTTP request, perform the tasks needed to answer this request, collate the needed information, and finally post the response based on that information. Destruction The Servlet Container stops a servlet by invoking the destroy() method of the servlet interface. The destroy() method is invoked when the container determines that the servlet should be removed from the service; for example, if the container is being shut down or more memory is required. Typically, you override the destroy() method to release any resources previously allocated in the init(). ServletContext The ServletContext object permits multiple servlets within a Web application to have access to shared information and resources.There is one instance per Web application per Java Virtual Machine(JVM). Using the ServletContext object, a servlet can log events, set and get attributes, and obtain URLs. The ServletContext object, a servlet can log events, set and get attributes, and obtain URLs. The ServletContext object is rooted at a specified path. The path can be obtained during runtime using the getContextPath() method of the HttpServletRequest object.

Handling Errors Any number of exceptions can occur when a servlet is executed. When an exception occurs, the Web container will generate a default page containing the message A Servlet Exception Has Occurred But you can also specify that the container should return a specific error page for a given exception. Initializing a Servlet After the Web container loads and instantiates the servlet class and before it delivers requests from clients, the Web container initializes the servlet. To customize this process to allow the servlet to read persistent configuration data, initialize resources, and perform any other one-time activities, you override the init method of the Servlet interface. A servlet that cannot complete its initialization process should throw UnavailableException. Writing Service Methods The service provided by a servlet is implemented in the service method of a GenericServlet, in the doMethod methods (where Method can take the value Get, Delete, Options, Post, Put, or Trace) of an HttpServlet object, or in any other protocol-specific methods defined by a class that implements the Servlet interface. The general pattern for a service method is to extract information from the request, access external resources, and then populate the response based on that information. For HTTP servlets, the correct procedure for populating the response is to first retrieve an output stream from the response, then fill in the response headers, and finally write any body content to the output stream. Response headers must always be set before the response has been committed. Any attempt to set or add headers after the response has been committed will be ignored by the Web container. The next two sections describe how to get information from requests and generate responses.

Getting Information from Requests A request contains data passed between a client and the servlet. All requests implement the ServletRequest interface. This interface defines methods for accessing the following information: Parameters, which are typically used to convey information between clients and servlets Object-valued attributes, which are typically used to pass information between the servlet container and a servlet or between collaborating servlets Information about the protocol used to communicate the request and about the client and server involved in the request Information relevant to localization HTTP servlets are passed an HTTP request object, HttpServletRequest, which contains the request URL, HTTP headers, query string, and so on. An HTTP request URL contains the following parts: http://[host]:[port][request path]?[query string] The request path is further composed of the following elements: Context path: A concatenation of a forward slash (/) with the context root of the servlet's Web application. Servlet path: The path section that corresponds to the component alias that activated this request. This path starts with a forward slash (/). Path info: The part of the request path that is not part of the context path or the servlet path. Constructing Responses

A response contains data passed between a server and the client. All responses implement the ServletResponse interface. This interface defines methods that allow you to: Retrieve an output stream to use to send data to the client. To send character data, use the PrintWriter returned by the response's getWriter method. Indicate the content type (for example, text/html) being returned by the response with the setContentType(String) method. This method must be called before the response is committed. Indicate whether to buffer output with the setBufferSize(int) method. By default, any content written to the output stream is immediately sent to the client. Buffering allows content to be written before anything is actually sent back to the client, thus providing the servlet with more time to set appropriate status codes and headers or forward to another Web resource. The method must be called before any content is written or before the response is committed. Set localization information such as locale and character encoding. HTTP response objects, HttpServletResponse, have fields representing HTTP headers such as the following: Status codes, which are used to indicate the reason a request is not satisfied or that a request has been redirected. Cookies, which are used to store application-specific information at the client. Sometimes cookies are used to maintain an identifier for tracking a user's. Invoking Other Web Resources Web components can invoke other Web resources in two ways: indirectly and directly. A Web component indirectly invokes another Web resource when it embeds a URL that points to another Web component in content returned to a client.

A Web component can also directly invoke another resource while it is executing. There are two possibilities: The Web component can include the content of another resource, or it can forward a request to another resource. To invoke a resource available on the server that is running a Web component, you must first obtain a RequestDispatcher object using the getRequestDispatcher("URL") method. Maintaining Client State Many applications require that a series of requests from a client be associated with one another. Web-based applications are responsible for maintaining such state, called a session, because HTTP is stateless. To support applications that need to maintain state, Java servlet technology provides an API for managing sessions and allows several mechanisms for implementing sessions. Accessing a Session Sessions are represented by an HttpSession object. You access a session by calling the getSession method of a request object. This method returns the current session associated with this request, or, if the request does not have a session, it creates one. Associating Objects with a Session You can associate object-valued attributes with a session by name. Such attributes are accessible by any Web component that belongs to the same Web context and is handling a request that is part of the same session.

Session Tracking A Web container can use several methods to associate a session with a user, all of which involve passing an identifier between the client and the server. The identifier can be maintained on the client as a cookie,

or the Web component can include the identifier in every URL that is returned to the client. If your application uses session objects, you must ensure that session tracking is enabled by having the application rewrite URLs whenever the client turns off cookies. You do this by calling the response's encodeURL(URL) method on all URLs returned by a servlet. This method includes the session ID in the URL only if cookies are disabled; otherwise, it returns the URL unchanged. Finalizing a Servlet All of a servlet's service methods should be complete when a servlet is removed. The server tries to ensure this by calling the destroy method only after all service requests have returned or after a serverspecific grace period, whichever comes first. If your servlet has operations that take a long time to run (that is, operations that may run longer than the server's grace period), the operations could still be running when destroy is called. This requires the servlet to perform the following tasks: Keep track of how many threads are currently running the service method Provide a clean shutdown by having the destroy method notify long-running threads of the shutdown and wait for them to complete Have the long-running methods poll periodically to check for shutdown and, if necessary, stop working, clean up, and return To ensure a clean shutdown, your destroy method should not release any shared resources until all the service requests have completed.

4.3.3 JavaServer Pages Technology

A java server page is a template for the web page that uses Java code to generate an HTML document dynamically. JSPs are run in a server side component called JSP Container, which translates them into equivalent Java Servlets. JavaServer Pages (JSP) technology allows you to easily create Web content that has both static and dynamic components. JSP technology makes available all the dynamic capabilities of Java servlet technology but provides a more natural approach to creating static content. JSPs have all the advantages of the servlets: They have better performance and scalability than CGI scripts because they are persistent in memory and mutithreaded. No special client setup is required. They have built in support for HTTP sessions,which makes application programming possible. They have full access to Java technology network awareness,threads,and database connectivity-without limitation of client-side applets. They are automatically recompiled whenever necessary. Because they exist in the ordinary Web Server document space ,addressing JSP pages is simpler than addressing servlets. Because JSP pages are HTML like,they have greater compatibility with Web development tools.

JSP A JSP page is a text document that contains two types of text: static data, which can be expressed in any text-based format (such as HTML, SVG, WML, and XML), and JSP elements, which construct dynamic content. The recommended file extension for the source file of a JSP page is .jsp. The page can be composed of a top file that includes other files that contain either a complete JSP page or a fragment of a JSP page. The recommended extension for the source file of a fragment of a JSP page is .jspf. The JSP elements in a JSP page can be expressed in two syntaxesstandard and XML-though any given file can use only one syntax. A JSP page in XML syntax is an XML document and can be manipulated by tools and APIs for XML documents. A JSP page is executed by JSP engine ,which is installed in Web server or JSP-enabled application server such as Weblogic or SilverStream.A JSP engine receives requests made by client to JSP page,then generates responses from JSP page back to the client. Normally JSP pages are compiled into Java Seervlets ,a standard Java Extension.

JSP File Pre-processed

.java file servlet

compiled

.class file servlet

Features of JSP Pages JSP pages are feature rich and make efficient use of the serverside components. Efficient use of server-side Java: Many features of java make it desirable platform for writing server applications.Server applications benefit from Javas development features such as type safety ,virtual absence of memory leaks and multithreading support.

Web Development, Deployment, and Maintenance: JSP pages facilitate the development process for programmers and page authors alike. By supporting component-based development and customized tag libraries,JSP pages not only simplify page authoring but also provide a strong foundation for a wide range of page authoring tools. Components That Are Reusable: Developers are able to share and exchange components that perform common operations ,including making them available to larger user or customer communities.The component based approach speeds overall development while allowing organization to leverage their existing expertise and development efforts for optimal results.It promotes reuse,which in turn promotes consistency. Separating Business Logic and Presentation: Using JSP technology, Web page developers construct HTML and/or XML tags to design and format the Web page.The logic that generates the content is brought together in tags and Javabeans components and bound together in scriplets ,which are ultimately executed on the server side.If core logic is encapsulated in tags and beans ,other individuals can edit and work with JSP page without affecting the generation of content.This helps authors protect their own propreitary code while ensuring complete portability for any HTML-based Web browser. Large Development Community and Widespread Support: The JSP specification is developed under the Java Community Process,ensuring that the specification has a broad spectrum of industry input and support.The reference implementation is developed openly under the Apache process. Platform Independence: Java Server Pages provides a componentbased,platform independent process for building Web-based applications.This widespread ,multi-platform support allows Web developers to write their JavaServer Pages code once and run it anywhere. Next Generation Page Development with Tags: The Java Server Pages technology encapsulates much of the functionality required for dynamic content generation in easy-to-use,JSP-specific XML-like tags ,allowing Web page developers to work with familiar tools and constructs to perform sophisticated functions.Standard JSP tags can perform functions that are difficult and time-consuming to code such as

accessing and instantiating JavaBeans components ,setting or retreiving bean attributes ,and downloading applets.JSP technology is extensible through development of custom tag libraries. The Components of a JSP Page JSP Directives JSP directives are used to pass instructions to JSP engine. These directives include the following: Page directivesThese directives communicate page-specific information,such as buffer and thread information or error handling Language directivesThese specify the scripting language ,alongwith any extentions. The include directiveThis directive can be used to include an external document in the page.If an element is to be used many times throughout a site ,it is easier to maintain common files in one central location and include them in several pages than o update them in each JSP page. A taglib directive This indicates a library of custom tags that the page can invoke.This is powerful and relatively unobtrusive.It avoids adding scriplet or embedded code,which is hard to maintain. JSP Tags A number of standard tags have been specified: Jsp:usebean This tag declares the usage of an instance of a JavaBeans component.The JavaBeans component instantiates and registers the tag if the bean doesnot already exist. Jsp:setpropertyThis sets the value of the property in a bean .

Jsp:getpropertyThis tag gets the value of a bean instance propety,converts it to a string,and puts it in the implicit object out Jsp:includeThe tag will cause the specific file to be included in the current JSP page. Jsp:forwardThis tag will forward or redirect control to another Jsp page. Scripting Elements Jsp page can include small scripts called scriplets.A scriplet is a code fragment that is executed at request time process.scriplets may be combined with static elements on the page , thus creating a dynamically generated page. Scripts are delineated with <% and %> markers.If multiple scriplets exist ,they are each appended to the _jspservice() method in the order in which they are coded. To give it linkage to JSP container ,JSP container , a JSP page has access to a number of the implicit objects .These are automatically initialized objects that have predefined variable names. These variables are Request Response Pagecontext Session Application Out Config Page

 Exception

Declarations A declaration is used to incorporate Java statements into JSP page. Declarations have three primary uses: Variable declarations: Both class and instance variables can be defined, although care must be taken to ensure that write access to the variables is synchronized because servlets, by default are multithreaded. Method definitions: Additional mehods can be added to the generated servlet by means of JSP declarations.Because the generated code is not inside the _jspService() method,however it does not have access to implicit variables(request,response,etc.) Inner classes: Declarations provide a convenient means for writing inner classes. An HTTP request can be advantageous. JSP provides two general capabilities to support this : Including othervresources,either with <%@include %> or <jsp:include>. Forwarding a request using <jsp:forward>. The Page Directive The page directive enables a page author to supply instructions to the JSP container.The operation of each attribute can be specified: Language: the scripting language(java,by default) Extends: a specialized superclass for the page

Import: the package and classes that should be visible to the generated servlet Session: whether to create an HTTP session object Buffer: the output buffering model Autoflush: whether to flush the buffer when full or throw an exception IsThreadSafe: whether to implement SingleThreadModel Info: a description of the page to be displayed in a development tool ContentType: the character encoding used by the JSP response IsErrorPage: whether to supply access to the implicit exception variable ErrorPage: the URL of a page that handles uncaught exceptions Deploying And Developing JSP Pages Write your JSP pages ,Java servlets ,JavaBeans components,and other supporting Java classes. Package the JSP pages and supporting classes in the appropriate archive format. Deploy the archive to J2EE-compliant server. Writing JSP Pages To create a Web application that contains one or more Jsp pages 1) Create a directory structure for application that conforms to the format requiredfor the Web application.

 WAR(Web Archive)Container for the Web-based application.A zip file contains the contents of the root directory and all subdirectories. Root directory Can contain JSP pages ,HTML documents,and any other contents for the application.These objects can also be subdirectories of the root WEB-INFA required subdirectory for descriptive deployment files that contain all the components of application that should not be available directly to the clients. The WEB-INF directory must contain a file called web.xml that is the deployment descriptor for the Web application. 2) Write the JSP pages and save them in root directoryof Web application. 3) Create any Java Servlets,JavaBeans components,or other supporting Java classesrequired by the application and compile these classes. JSP Architectures JSP technology provides a standard for a declarative ,presentation centric method of developing servlets. JSP pages are subject to translation phase and request-processing phase.The translation phase is carried out only once ,unless JSP page changes ,in which case it can be repeated.Jsp page can be precompiled into class files.Precompilation may be especially useful in removing the startup delay that occurs when a JSP page delivered in source form receives the first request from a client. The JSP page implementation class file extends HttpJspBase,which implements the Servlet interface.The service method of this class, _jspService(),esentially sends the contents of the JSP page to the method.The _jspService() method can describe initialization and destroy events by providing implementations for jspInit() and

jspDestroy() methods within their JSP pages. The _jspService() method replies to a clients request. There are atleast two approaches to building and applying JSP technology.These approaches differ essentially in terms of where the request processing is performed . One approach allows for business logic and presentation code to be intermixed with presentation itself(HTML).Maintaining hundreds of JSP pages could be expensive ,especially if the corporate look and feel changes often.The more mature approach prescribes that all the code, business logic, and such be excluded from presentation to the extent that this is possible. 4.3.4 Enterprise Java Beans Enterprise Java Beans (EJB) is a server side component architecture that enables and simplifies the process of building enterprise-class distributed object applications in java. By using EJB you can write scalable, reliable and secure applications without writing your own complex distributed object framework. EJB is about rapid application development for the server side: you can quickly and easily construct server side components in Java by leveraging a pre-written distributed infrastructure provided by the industry. EJB is designed to support application portability and reusability across any vendors enterprise middleware services. Component Architectures In Java Java Beans are development components and are not deployable components. The Enterprise Java Beans (EJB) standard defines component architecture for deployable components called Enterprise Beans. Enterprise Beans are larger, coarser-grained application components that are ready to be deployed. Deployable components must be deployed in a container that provides run time services to the components, such as services to instantiate components as needed.

Enterprise Beans are very similar to two other types of Java components: applets and servlets. Applets can be deployed in a web page, where the browsers applet viewer provides a run time container for the applet. Servlets can be deployed in a web-server, where the webservers servlet engine provides a run time container for the servlets. Enterprise Beans are deployed in an application server where the application server provides a run time container for the Enterprise Java Beans (EJB). Enterprise Java Beans (EJB) are not intended for the client side, but are server side components. They are meant to perform sever side operations such as executing complex algos. The server side has different kind of need for a rich GUI environment. An application server provides this high-end server side environment for the Enterprise Java Beans and it provides the run time containment necessary to manage the enterprise beans. N-Tier Architecture An n-tier architecture adds one or more tiers to the 2-tier model (classical server-client model). In n-tier deployment, your presentation layer, business logic layer and data layer are separated into respective physical tiers. Concrete example of an n-tier architecture is a three-tier web based deployment. The description is as follows: Presentation tier runs within the address space of one or more web servers. It consists of Java servlets or Java Server Pages (JSP) and workflow logic. Business Logic tier runs within the address space of one or more application servers. Application servers are necessary to provide a suitable containment environment for the business logic components to run in. Data tier consists of one or more databases and may contain data related logic in the form of stored procedures. An n-tier architecture have the following characteristics:

 Deployment costs are low. Database switching costs are low. Business logic migration costs are low. You can secure parts of your deployment with firewalls. Resources can be efficiently pooled and re-used. Each tier can vary independently. Performance slowdown and errors are localized. Maintenance costs are high.

Types Of Enterprise Java Beans: Session Beans A session bean represents a single client inside the Application Server. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server. As its name suggests, a session bean is similar to an interactive session. A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. Like an interactive session, a session bean is not persistent. (That is, its data is not saved to a database.) When the client terminates, its session bean appears to terminate and is no longer associated with the client. There are two types of session beans: stateless and stateful. Stateless Session Beans A stateless session bean does not maintain a conversational state for the client. When a client invokes the method of a stateless bean, the bean's instance variables may contain a state, but only for the duration of the invocation. When the method is finished, the state is no longer retained. Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client.

Because stateless session beans can support multiple clients, they can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients. At times, the EJB container may write a stateful session bean to secondary storage. However, stateless session beans are never written to secondary storage. Therefore, stateless beans may offer better performance than stateful beans. A stateless session bean can implement a Web service, but other types of enterprise beans cannot. The state of an object consists of the values of its instance variables. In a stateful session bean, the instance variables represent the state of a unique client-bean session. Because the client interacts ("talks") with its bean, this state is often called the conversational state. The state is retained for the duration of the client-bean session. If the client removes the bean or terminates, the session ends and the state disappears. This transient nature of the state is not a problem, however, because when the conversation between the client and the bean ends there is no need to retain the state. When to Use Session Beans In general, you should use a session bean if the following circumstances hold: At any given time, only one client has access to the bean instance. The state of the bean is not persistent, existing only for a short period (perhaps a few hours). The bean implements a Web service. Stateful session beans are appropriate if any of the following conditions are true:

 The bean's state represents the interaction between the bean and a specific client. The bean needs to hold information about the client across method invocations. The bean mediates between the client and the other components of the application, presenting a simplified view to the client. Behind the scenes, the bean manages the work flow of several enterprise beans. To improve performance, you might choose a stateless session bean if it has any of these traits: The bean's state has no data for a specific client. In a single method invocation, the bean performs a generic task for all clients. For example, you might use a stateless session bean to send an email that confirms an online order. The bean fetches from a database a set of read-only data that is often used by clients. Such a bean, for example, could retrieve the table rows that represent the products that are on sale this month. Entity Bean An entity bean represents a business object in a persistent storage mechanism. Some examples of business objects are customers, orders, and products. In the Application Server, the persistent storage mechanism is a relational database. Typically, each entity bean has an underlying table in a relational database, and each instance of the bean corresponds to a row in that table . Difference between Entity Beans and Session Beans Entity beans differ from session beans in several ways. Entity beans are persistent, allow shared access, have primary keys, and can participate in relationships with other entity beans.

 Persistence Because the state of an entity bean is saved in a storage mechanism, it is persistent. Persistence means that the entity bean's state exists beyond the lifetime of the application or the Application Server process. If you've worked with databases, you're familiar with persistent data. The data in a database is persistent because it still exists even after you shut down the database server or the applications it services. There are two types of persistence for entity beans: bean-managed and container-managed. With bean-managed persistence, the entity bean code that you write contains the calls that access the database. If your bean has container-managed persistence, the EJB container automatically generates the necessary database access calls. The code that you write for the entity bean does not include these calls. Shared Access Entity beans can be shared by multiple clients. Because the clients might want to change the same data, it's important that entity beans work within transactions. Typically, the EJB container provides transaction management. In this case, you specify the transaction attributes in the bean's deployment descriptor. You do not have to code the transaction boundaries in the bean; the container marks the boundaries for you. Primary Key Each entity bean has a unique object identifier. A customer entity bean, for example, might be identified by a customer number. The unique identifier, or primary key, enables the client to locate a particular entity bean. Relationships Like a table in a relational database, an entity bean may be related to other entity beans. For example, in a college enrollment application, StudentBean and CourseBean would be related because students enroll in classes.

You implement relationships differently for entity beans with bean-managed persistence than those with container-managed persistence. With bean-managed persistence, the code that you write implements the relationships. But with container-managed persistence, the EJB container takes care of the relationships for you. For this reason, relationships in entity beans with container-managed persistence are often referred to as container-managed relationships. The Enterprise Bean Class For session beans, an enterprise bean class typically contains business process related logic. For entity beans an enterprise bean class typically contains data related logic. The most basic interface that all bean class must implemet is the javax.ejb.EnterpriseBean interface. The EJB Object When a client wants to use an instance of an enterprise bean class, the client never invokes the method directly on an actual bean instance. Rather the invocation is intercepted by the EJB Container and then delegated to the bean instance. Thus , the EJB container is acting as a layer of indirection between the client code and the bean. This layer of indirection manifests itself as a single network-aware object called the EJB OBJECT. The Remote Interface Bean clients invoke methods on EJB Objects rather than the bean themselves. To perform this, EJB object must clone every business method that the bean class expose. A special interface is created that duplicates all the business logic methods that the corresponding class exposes. This interface is called the remore interface.

The Home Object The client cannot instantiate an EJB Object directly as it might be on a different machine.To acquire a reference to an EJB Object, the client code asks for an EJB Object from an EJB Object factory. This factory is responsible for instantiating EJB Objects. The EJB specification calls such a factory a home object. The Home Interface Home interfaces simply define methods for creating, destroying and finding EJB Objects. The required methods are defined in the javax.ejb.EJBHome interface The Deployment Descriptor Specifies the middleware requirements of the bean. One uses the deployment descriptor to inform the container about how to manage the bean, the beans life-cycle needs, the transactional neeeds etc. The Ejb-jar file This is the last step before deploying the bean. This is a compressed file that contains everything we have written above: Enterprise Beans Remote Interface Home Interface Deployment Descriptor

The Life Cycle of Enterprise Bean An enterprise bean goes through various stages during its lifetime, or life cycle. Each type of enterprise beansession or entity, has a different life cycle.

The Life Cycle of a Stateful Session Bean Figure 1 illustrates the stages that a session bean passes through during its lifetime. The client initiates the life cycle by invoking the create method. The EJB container instantiates the bean and then invokes the setSessionContext and ejbCreate methods in the session bean. The bean is now ready to have its business methods invoked.

Figure 1 Life Cycle of a Stateful Session Bean

While in the ready stage, the EJB container may decide to deactivate, or passivate, the bean by moving it from memory to secondary storage. (Typically, the EJB container uses a least-recentlyused algorithm to select a bean for passivation.) The EJB container invokes the bean's ejbPassivate method immediately before passivating it. If a client invokes a business method on the bean while it is in the passive stage, the EJB container activates the bean, calls the bean's ejbActivate method, and then moves it to the ready stage. At the end of the life cycle, the client invokes the remove method, and the EJB container calls the bean's ejbRemove method. The bean's instance is ready for garbage collection. The Life Cycle of a Stateless Session Bean Because a stateless session bean is never passivated, its life cycle has only two stages: nonexistent and ready for the invocation of business methods.

Figure 2 Life Cycle of a Stateless Session Bean

The Life Cycle of an Entity Bean Figure 3 shows the stages that an entity bean passes through during its lifetime. After the EJB container creates the instance, it calls the setEntityContext method of the entity bean class. The setEntityContext method passes the entity context to the bean. After instantiation, the entity bean moves to a pool of available instances. While in the pooled stage, the instance is not associated with any particular EJB object identity. All instances in the pool are identical. The EJB container assigns an identity to an instance when moving it to the ready stage. There are two paths from the pooled stage to the ready stage. On the first path, the client invokes the create method, causing the EJB container to call the ejbCreate and ejbPostCreate methods. On the second path, the EJB container invokes the ejbActivate method. While an entity bean is in the ready stage, an it's business methods can be invoked. There are also two paths from the ready stage to the pooled stage. First, a client can invoke the remove method, which causes the EJB container to call the ejbRemove method. Second, the EJB container can invoke the ejbPassivate method.

Figure 3 Life Cycle of an Entity Bean

At the end of the life cycle, the EJB container removes the instance from the pool and invokes the unsetEntityContext method. In the pooled state, an instance is not associated with any particular EJB object identity. With bean-managed persistence, when the EJB container moves an instance from the pooled state to the ready state, it does not automatically set the primary key. Therefore, the ejbCreate and ejbActivate methods must assign a value to the primary key. If the primary key is incorrect, the ejbLoad and ejbStore methods cannot synchronize the instance variables with the database. In the pooled state, the values of the instance variables are not needed. You can make these instance variables eligible for garbage collection by setting them to null in the ejbPassivate method.

Description of Files Included with Entity Beans The entity bean class It is the java class that models persistent data. It maps to an entity definition in a database schema. For example, an entity bean class could map to a relational table definition. In this case, an entity bean instance of that class would map to a row in that table. EJB requires that an entity bean class must fulfil some standard callback methods. The entity beanss remote interface It is the interface to your bean on which clients invoke. In it you place each of your entity beans business method signatures. The entity beans home interface It is the interface clients use to create, find, and destroy entity bean EJB objects. This home object is the factory for your EJB objects. To find the home object, client must perform a JNDI lookup. The entity beans primary key class It is a unique identifier for youe entity bean. A primary key is an object that may contain any number of attributes. This could be what ever data necessary to uniquely identify entity bean data instance. The one rule is that your primary key class must be serializable and follow the rules for Java object serialization. The entity beans deployment descriptor It contains a list of properties that should be used by the container on deployment. Deployment descriptors inform container about your bean. The entity beans environment properties It allows end user to customize your entity bean on deployment. Environment properties are optional.

Developing and Using Entity Beans To write an entity bean class, your class must implement the javax.ejb.EntityBean interface. This interface defines a number of required methods that your entity bean class must implement. Most of these methods are management methods that are called by your EJB container. ejbCreate() : Session beans require ejbCreate() methods, but they are optional for entities. You do define ejbCreate() method if you want to provide a way to create some underlying data through EJB. EJB does allow for you to create data indirectly, via direct database inserts or legacy systems. Thus ejbCreate() is optional. The parameters to ejbCreate() can vary. This allows for multiple ways to initialize an entity bean instance and thus allows different ways to create entity bean data in a database. You must duplicate your ejbCreate() methods in your home interface. In EJB, clients do not directly invoke on beans, they invoke an EJB object proxy. The EJB object is generated through home object. ejbFind() : It is used to find an existing entity bean in storage. Finder methods do not create any new database data, they simply load some old entity bean data. The parameters to ejbCreate() can vary. This allows for multiple ways to find database data. All finder methods must begin with ejbFind. You must have at least one finder method, called ejbFindByPrimaryKey. A finder method must return either the primary key for the entity bean it finds or an enumeration of primary keys if it finds more than one. You must duplicate your ejbCreate() methods in your home interface. In EJB, clients do not directly invoke on beans, they invoke an EJB object proxy. The EJB object is generated through home object. ejbPassivate() : If too many beans are instantiated, the EJB container can passivate some of them, which mean writing the beans to temporay storage such as a database or file system. The container can then release the resources the beans had claimed.

ejbActivate(): When a client needs to see a bean that has bean passivated, the reverse process automatically occurs. The container kicks the bean back into memory, or activates the bean. Any released resources during ejbPassivate() are allocated again to bean. ejbRemove(): Whenever container is about to remove your bean instance, it calls your beans ejbRemove() callback method. It is a cleanup method alerting your bean that it is about to be destroyed and allowing it to end its life gracefully. It is required method of all beans, and it takes no parameters. Therefore there is only one ejbRemove() method per bean. Business methods: In addition to required callback methods, you may require one or more business methods in your bean. These methods actually solve business specific problems. For clients to call your business methods, you must list your business methods in your beans remote interface. Primary Keys Entity Beans define an object called the primary key. Its sole purpose is to identify uniquely each entity bean within the system. The primary is a serializable java object, and maybe any of the primitive wrapper objects such as java.lang.Integer, java.lang.String. Using and existing java class is an effective way to minimize efforts on the primary key. EJB developers may create their own class to identify an entity bean. This can be especially useful in compound primary keys, where more than one persistent field is used to identify the entity bean.

4.3.5 Oracle 9i Database is a coherent collection of data with some inherent meaning, designed, built and populated with data for a specific purpose. A database stores data that is useful to us. This data is only part of entire data available in the world around us. To be able to successfully design and maintain databases we have to do following: 1) Identify which specific objects in the world are of interest to us: These objects are called Entities in the Entity-Relationship Model (ER Model). 2) Identify which type of data is required to describe those objects: These properties of objects are called Attributes of the Entity. 3) Identify relationship between the objects: This relationship defines the linkage between Entities, thus forming complete ER Model. Hence database is storage designed, built and populated with data for objects, their attributes and the relationship between them that are of interest to us. Oracle As RDBMS Oracle product is based on Client-Server technology and is thus primarily divided into: Oracle Server Tools Oracle Client Tools Oracle Server: Oracle is a company that produces the most widely used, Server based, Multi user Relational Database Management System (RDBMS). The Oracle Server is a program installed on the Servers hard

disk drive. This program must be loaded in RAM so that it can process user requests. It is actually the Back-end of the project whose primary job is to manage data optimally, among multiple users that concurrently request for the same data. It is single entry point to access of data. Any one-point, data access system has the capacity of offering excellent data security. The Oracle Server takes care of the following: Updating the database. Retrieving information from the database. Accepting query language statements. Enforcing data integrity specifications. Enforcing transaction consistency. Managing data sharing. Optimizing queries. Managing system catalogs. Oracle Client Tools: Once the Oracle Engine (Server Program) is loaded in to servers memory, users would have to log into the engine to get work done. It is actually the Front-end of the project, which provides an interface to the user so that the data retrieved from the Server can be manipulated. It allows the user to pass data manipulation requests to the Oracle Engine. Oracle engine then interacts with the user by displaying data and messages (if any) as requested by the user. Oracle Corporation has several client-based tools that facilitate this. E.g. SQL*PLUS , PL/SQL Developer.

Database Connectivity with Oracle Engine in Project: In Corporate Credit Management System, Weblogic Server is used for database connectivity with oracle engine. The Weblogic Server creates Connect Pool to allow all the J2EE components to access database. It also allows for connection pooling, thereby reducing number of connections made per J2EE component. Hence the burden on oracle engine is reduced. It also helps in bringing the consistency in accessing database, thereby reducing the chances of error and increasing the maintainability factor. Characteristics of Oracle: Structures: These are objects that store or access data from the database. E.g. tables, views, or indexes. Operations: These are actions used to define structures or manipulate data between structures. E.g. commends like create, delete or update to manipulate data, and select to view data. Integrity Rules: They govern kinds of actions allowed on the data and the database structures. E.g. constraints like primary key, foreign key etc.

5.1 Administrative Requirements

The following types of users will use the proposed system: Data Entry Operators Data entry operators will enter data sent from different branches, related to the, static details of loans sanctioned at various branches, variable information on all loans etc. These operators could be internal (BANK personnel) as well as external. Operational Users Operational users, typically desk officers in charge of the accounts, will enter information related to the proposals, appraisals, and loans sanctioned and monitoring reports at the RO/HO. This category will also include other BANK staff who will be responsible for performing day-to-day functions like compilation of data, printing of reports, running batch programs, etc. Function Managers Function managers will be overall in-charge of the assigned function. They will be responsible for sensitive functions like approvals, assigning responsibility to other users, etc. In addition to above users, the system will have a Database administrator (DBA), responsible for the technical aspects of database management. DBA will have access to SQL*PLUS and will be responsible for performing day-to-day operations on the database like startup, shutdown. The security features for the proposed system will be: The application software and the database will be protected from illegitimate access, use, or modification by providing security at the system and functional level. The security system will ascertain whether the user is a valid ORACLE user who is authorized to perform a particular function or to modify the database, before allowing the user to proceed.

 Only certain users will be given read only access to the database via SQL*PLUS. SQL*PLUS will not be available for update to any application user. No development utilities like Oracle Forms, Reports etc. will be stored on the users PCs. The form, report, library, and script executables would be stored in a specific mapped drive on the Pentium server. The users will logon to the server with a common account, which will have read only access on the executables. An option shall be available to the application user to change the password. It is recommended for the users to change the password after every month. A facility will be provided to the user to specify another employee on whose behalf he could work on the system (only if authorized by the application manager). In this case, the acting officer will acquire the privileges of the officer he is imitating but the system will put his stamp (user-ID) as part of row level auditing. The system will provide a facility to form a group consisting of privileges to various application programs. For example, the POLICY_ALL group, comprising of very senior officers, can be created with create, update, view and delete privileges on various Credit Policy Masters. This group can be assigned to a user. This user will be able to perform all the operations on Credit Policy programs. Another group POLICY_VIEW can be created consisting of only view privileges on Credit policy related data. This group can be assigned to another user who will be able to only view the Credit Policy data. The functional manager will maintain the link between the employees and the application programs that he/she can access. An employee can have more than one application assigned to him/her. When the user will log-on to the system, the system main menu will be displayed showing various modules of the Loan origination system like Policy, Appraisal, Monitoring, MIS Reports, etc. Each module will have its own menu that will be called from the main menu. User will be able to access various

application programs from the module menu. For example, the user will be able to go to the Capture BCC Information programs from the Monitoring module menu, provided he/she has the required privileges. It will be possible for the functional manager to grant different privileges on the same screen to different users, if applicable. On the database administration front it is suggested that only the DBA will have access to the SQL*PLUS session and will keep the passwords for database management. He will also be the Operating System super user. He would mainly look after the technical aspects of database administration. Benefits from the Proposed System Main Deviations in Processes from the Existing System All borrowers will be referred to by the unique borrower identification assigned by the system. The unique credit sanction number assigned by the system will refer to all credits sanctioned by the bank. All monitoring reports will refer to the credit sanction number so assigned. Reports relating to the OSS, Recovery and Rural Development currently sent by the branches to the ROs will be generated at the RO based on information available in the system. There will be a single format for appraisal note for all proposals that fall within the powers of the RO and HO. All irregularities reported in the monitoring reports will be classified under a pre-defined list of irregularities and will be assigned an irregularity code. Only the salient features and irregularities in monitoring reports will be stored.

 The functionality provided by registers like Power Registers, Loan Proposal and Disposal Registers, etc. will be provided by means of screens and reports, which will be generated, based on the loan sanction, proposal details. For the proposals that fall under the powers of the HO, the proposal and borrower details can be captured at the RO and further uploaded at HO/RO. The system will provide a facility to assess the borrower and assign a borrower rating based on certain pre-defined parameters.

5.2 Tools and Technologies

System Software Specifications
Server Components Programming Languages Operating System Web Server Application Server Database Engine Server Network Processor EJB HTML, JSP, Java, JavaScript,Struts Linux 7.1, Windows XP Weblogic 7.0 J2EE-compliant application server Oracle 9i N-tier server centric environment that can scale to any number of servers P III, P IV

Hardware Requirements The following is the hardware configuration, which would be required for a centralized version of CMS. However, it may vary widely based on the banks volumes and performance requirements. The actual server configurations and data storage requirements can be arrived at only after studying the banks volumes, growth in data etc. The network bandwidth will be influenced by the performance desired by the bank. System specifications at the CENTRAL SITE

Application Server : 1 Nos - With following configuration

1 x server 2 x 750MHz RISC CPU 2 x 1024MB High Density DRAM Mem Module 2 x 18GB 10K Hot Plug Ultra160 disk 1 x DVD ROM Device 1 x Hot Swap Power Supply, Redundant System 1 x Latest OS Version 1 x Terminal console

Database Server : 1 Nos - With following configuration 1 x server 2 x 750MHz RISC CPU 2 x 1024MB High Density SyncDRAM Mem Module 2 x 36GB 10K HotPlug Ultra160 disk 1 x DVD ROM Device 1 x Hot Swap Power Supply, Redundant System 1 x Terminal console

System specifications at the CLIENT SITE

Client PC : 1 No each

PII and above CPU, >= 64 MB RAM, >= 8 GB Hard disk

6.1 Proposed System

Proposed system
Senior Management

Data input, Reviews, Follow up

MIS Reports, Feedback/ Approvals & Credit Decisions

User
Sanctions, Queries Credit Policy

HO (P&D)

Branch
Proposals, Monitoring reports, Clarifications

Credit Management System

Transfer of doubtful & NPA accounts

HO Recovery & Law

HO Inspection & Control

Inspection Reports, Clarifications Reply to Clarifications, Follow up

Banks Balance Sheet Information Proposals, LAC, Other reports, Replies for Queries Queries, Sanctions, & Advices

HO Central Accounts

HO (Central Accounts)

RO (Credits)

Branch Weekly

Other Banks

Exchange of Information

ECGC
Statutory Reports

Central Bank

ECGC Caution List

Over view of the Credit Management System 6.2 Technical Architecture

The following figure illustrates the basic architecture of the solution. Database and documents form the storage layer. Application layer contains the business logic in terms of servlets, beans and JSPs. Presentation layer is the front end and contains javascripts and HTML files. The client browser interacts with these components using https protocol. This ensures the security of underlying data and programs against unauthorized access.

FIREWALL

Browser Clients

Presentation Layer

Application Layer

Storage Layer

JSP

Servlets

Document management system

HTML/ XML
Browser Clients

EJB Components

J2EE Web Server

J2EE Applic ation Server

RDBMS

Report Server

Workflow client

6.3 System Architecture

System Distribution Strategy While selecting the most suitable data processing option for BANK, following assumptions of BANK functioning were taken into account: Each RO works as an independent unit. There is high concentration of transactions and local processing at RO and within each department of HO. Few interactions are required between RO and HO and between HO departments for day-to-day operations. For example, Credit Department does not require any data from Central Accounts department or any other department for its day to day working. The data transmitted between RO & HO is usually required to be transmitted on periodic basis. For example, Loan Audit Cell (STRO) reports is transmitted from RO to HO at the end of every month. Data is not required in same detail at every location. For example, only a summary of RO sanctions is required at HO. Each RO needs to capture information about only those branches, which fall under it, whereas HO need to have data about all the branches under all the ROs.

 Some master data items like RO Master and Branch Master are required at all the HO departments. In future, the network may be expanded to include the computerised branches. Against this backdrop, a centralized and networked data processing environment is suggested. BANK applications will be based on WAN-LAN environment. There will be a Local Area Networking (LAN) segment, based on Client-Server computing, within each department in the HO and within an RO. These LAN segments will be connected over WAN. Each LAN segment will have the application running on client-server architecture. In such an environment the server is a high-end machine that acts as a focal point for the network; and the clients are intelligent nodes, which provide user interface. The database will reside on the server, whereas the front-end application will be loaded on the clients.

BO

RO

RO CMS at HO

RO

J2EE N-Tier architecture will be used at BANK with a dedicated server and a database.

6.4 Application Architecture

The CMS application will be based on n-tier architecture. It gives the application a modular structure in its implemented environment. The existing system was client server architecture and hence there were lots of hassles. The business application has a form structure to enter the data and a data repository for storing the data. The forms used, form the client part of the application whereas the data repository is the server part. The client part will enforce the validity of data and will ensure that the business rules are followed. The server component, a database server, will serve all the clients. The advantage lies in the modularity and ease of maintenance. In this scenario you have multiple components the front-end interface, the middle layer and the back-end. Depending on the change, the modification is restricted to the corresponding component only. This architecture also splits the processing power required between the server machine and the client machine, in case intelligent clients are used. Whatever local computation can be performed, especially validations are carried out on the client machine without overloading the server machine.

In BANK project, a n-tier architecture has been conceptualized. The front-end component will be at the client and the middle layer and database components will be on the server. The benefits of n-tier architecture are derived from: Greater architectural flexibility Better integration More productive development environment Better manageability and reduced constraints. The division of functionality into various layers for other software components is described in following sub-sections. User Interface Component All user interactions (inputs/outputs) in the application are handled by the user interface component. It is also known as the presentation component. This component consists of the presentation logic & presentation resources. In addition it will also support the following features: Error handling Security - It will also store the security privileges of the user and terminal at runtime and will have the logic to enable or disable operations based on these privileges. Reports - The interface between the application and the SQL report writer will be part of this component. The common print dialog will also be part of this component. Housekeeping jobs - It will provide an user friendly interface for changing environmental settings and housekeeping jobs like backup, recovery, and invoking batch jobs if required.

The user interface component will be implemented in the front-end layer. BR Component BR component or Business rule component is also known as Application logic component. This component mainly consists of application/business logic and validations. a. Business Logic Business logic is application functionality specific logic. This component ensures that the data for each business transaction is correct and complete according to the functionality. For this, business logic validations and processing will be built into the system. Business logic that does not require database access will be implemented at the front-end. Business logic that requires access to database will be implemented at the backend. b. Domain & Range Validations Domain and range validation will be done at any of the three layers depending on the requirement. These are as follows: Data type validations and range validations like Quantity should be greater than zero will be implemented at the front end. For all static values, e.g. values in a combo, validation is not required at the front-end layer. But still to maintain data integrity rules or constraints will be defined at the backend. Any cross-field validation independent of database access will be implemented at the front-end. c. Data dependent validations

These validations will mainly consist of data dependent business logic checks, entity integrity, referential integrity, and data dependent crossfield checks. These validations can be implemented at the backend using rules, constraints (primary key, unique, foreign key, check, default), triggers and store procedures. This will minimize the network traffic. However, exceptional cases may be there when these things will be implemented at the front-end. d. Processing Rules Any processing related with formatting or presentation of data will be done at the front end. Any processing that does not require database access will be done at the front end. Any calculation or business processing that requires database access will be done at the backend.

6.5 Error Analysis

Three categories of outcomes can occur when a function is called during program execution: Normal, Erroneous and Abnormal. Normal Execution The function executes normally and returns. The possible result codes are defined for the function and represent the range of possible outcomes of the function. The result code can indicate success or failure or can even indicate a particular type of failure that is within the normal range of expectations. For example, a file-status function can return a code that indicates that the file does not exist. Erroneous Execution The caller makes some mistake in passing arguments to the function or calls the function in an inappropriate context. This situation causes an error, and it should be detected by an assertion during program development.

Abnormal Execution Abnormal execution includes situations where conditions outside the programs control are influencing the outcome of the function, such as low memory or I/O errors. Catching and throwing exceptions should handle abnormal situations. The Error and Exception Handling in the BANK application can be broadly divided into two categories: Front-end Error Handling Back-end Error Handling 6.5.1 Front-End Error Handling All the error messages will be stored in the library and will be retrieved through a generic function wherever required. The generic function will help to maintain the consistency throughout the application. Information to be substituted in the error message at run time will be passed by the function containing the error handling code. An error that is encountered in a database operation being performed by the on-line screen/report will return the error number to the calling program. The calling program will call the generic function to extract the message corresponding to this error and display the message on the screen. CMS incorporates the logic for the screens and the error messages to be multilingual. This means that the application can be incorporated to have support for any language; only one needs to make the appropriate file for that language. The foreground and background colors of all the fields in error are changed to highlight the errors. When the validations for the screen are restarted (after the user fixes the errors), the error fields are reset to the default colors.

6.5.2 Back-End Error Handling All the user defined error messages related to the errors occurring during database operations in batch programs and reports will be stored in a database table and will be raised at the server end. These will be logged in a text file. Database Components The data for the CMS application would reside on ORACLE 9i database. The application shall access the database through stored procedures as far as possible. Tables Data required by the application will be organized into tables. These will initially be defined by DESIGNER tool and then refined. All tables will also maintain four additional columns for the user like who created the record, date when the record was created, the user who last

modified the record and the date when the record was last modified. These columns will provide an audit facility on updates and inserts to the database. Views Views may be used in cases where it is required to restrict the accessibility and visibility of specific data to particular users. Indexes DESIGNER automatically creates indexes for primary key and unique constraints. In addition, indexes on particular columns will be created explicitly to improve the performance of query, update and delete operations. A clustered index will be created on each table on those columns that are used in queries to the greatest extent. Creation of clustered indexes explicitly provides for greater control on the way data is actually stored on disk. Clustered indexes should be created before any non-clustered indexes so that the non-clustered indexes do not have to be rebuilt. A table should have more than one index if necessary and the indexes should be created on columns that: are frequently retrieved in sorted order are frequently searched in ranges are frequently used in joins Constraints Constraints are an additional method for enforcing data integrity at the table level. They are application rules that ORACLE enforces automatically. Constraints limit the possible values that users can enter into a column. There are 5 types of constraints available in ORACLE:

Primary Key null Unique Foreign Key Default Check

- values entered must be unique and cannot be - values must be unique - value must exist as primary key in referenced table - value inserted when no value is specified explicitly - A Check constraint enforces domain integrity.

6.6 Data Transfer and Communication

Data Transfer Across Modules

Borrower details Proposal details Appraisal Note details Policy Monitoring & conduct of Sanction details Sys Parameters In-principle Braccount Master info approval RO Master Amendment Validity extension Dept Master Ad-hoc/Additional Policy Masters. limits MIS Reports RO Norms, Guidelines Advances District Master Disbursement Branch Common/Module details Borrower/ Parameters Sanction details Advances Advances account and disbursement details Masters for

Appraisal

Sanction details

Monitoring

BCC MOR QISI/QISII QIS-III CA Stock Verification Site Visit Details STRO 16 Details

details

Security

MIS Reports Rural Development MIS Reports Credits Recovery OSS

Borrower/Sanction Details

POA details

A common database will be used for all the 4 modules (Policy, Appraisal, Monitoring, MIS Reports) of the CMS, at each location. Most of masters like Branch Master, RO Master, Facility Master, and Scheme Master are used by all the modules and will form part of the policy module. Other modules may also access the transaction data, which is created or owned by a module. However access by another module is allowed only in read mode. For example, the Loan Sanction details are generated by the Appraisal module and are used by the Monitoring module. The position of account data created by Monitoring module is used by Appraisal module.

6.7 Input and Output Specifications

System Flow - Appraisal

Pre-requisites Maintain Policy Masters Maintain System Parameters Maintain Common Params Maintain Module Params

Maintain details

Borrower

Maintain Proposal details Create Appraisal Note

Capture Credit Decision Create Loan sanction

Print Sanction Letter

Print Rejection Letter

Appraisal Regular Sanction

Pre-requisites Maintain Policy Masters Maintain System Parameters Maintain Common Params Maintain Module Params Maintain Borrower details Create Loan Sanction

Maintain Validity Extension

Maintain Ad-hoc /additional details

Print Advice Print Advice

Appraisal Others

Upload DICGC & Form IX

System Flow - Monitoring

Pre-requisites Maintain Policy Masters Maintain System Parameters Maintain Common Params Maintain Module Params

Capture Monitoring Reports

Generate LAC reports

Print pending lists Print Clarifications letter Print Awaiting clarification list

Monitoring RO System Flow

Monitoring HO System Flow

Pre-requisites Maintain Policy Masters Maintain System Parameters Maintain Common Params Maintain Module Params Maintain Borrower details Create Loan sanction

Capture Monitoring Reports

Enter LAC reports

Upload LAC reports

Print pending lists Print Clarifications letter Print awaiting clarification list

Consolidate

LAC Reports

MIS reports at RO

Enter Branch Information

Enter MIS Reports Details

Generate MIS Reports

MIS Reports RO System Flow

MIS Reports at HO

Upload RO reports

Consolidate Reports

Enter MIS Reports Details

Print MIS Reports

6.8 Overview of Credit Operations

Proposals (RO/HO)

Sanctions under branch discretion,

Asset classification

Appraisal Capture borrower details Capture proposal details Capture appraisal note Capture Policy guidelines

Loan sanction

Monitoring information & Information on conduct of account

Monitoring Capture BCC Capture MOR Capture QIS Capture POA Policy guidelines

Report
s

Details of POA & other variable details

Capture Policy Policy details Norms

BCC/MOR/QIS Reports/ CA Stock Verification/ Visit Report

Borrower & loan sanction details

Policy guidelines
MIS Reports

Monitoring information and information on conduct of account

Variable data from branches on jotting sheets

Control Credits HO/RO Recovery & law RO Surveillance Rural development Statutory Senior management

The dotted line represents the System Boundary

Credit Appraisal

Appli catio n

Capture Borrower Details like Borrower Allied/sist er

Concern

Capture Credit Proposal

Borrower details

Contact
Proposal details

Details like Proposed facilities Security Guarantor Check for encCMS

Querie Capture inprinciple Details Reports

Link

Clarification for queries

Capture Credit Decision Loan Sanction/ Report s

Reports Approved Appraisal Capture Appraisal Note Financial details Ratio /BE analysis Terms and conditions Recommen dations

Rejection Terms and condition Loan sanction / rejection

Assess Borrower Rating Borrow er Rating

Report

Loan sanction details

Other activities Ad-hoc & Additional Validity

Appraisal note details

Report

Business Workflow for Credit Appraisal

Credit Monitoring
Queries to/ Clarifications from branch

Branch Compliance Certificate (BCC)

Enter BCC details at RO

Review BCC at RO

Down load at RO for HO (HO cases)

Ttt

Quarterly Information System Form I MOR/QIS Forms II & III/ CA Stock Verification

Enter QIS Form I details at RO

Down load at RO for HO (HO cases)

Enter details at RO

Review at RO

Download at RO for HO

Review at HO

Queries to/ Clarifications from branch

Queries to/ Clarifications from RO/branch

Figure: Business Workflow for Credit Monitoring

The dotted line represents the System Boundary

Overview:
At TCS ,great learning opportunities were provided to me. I worked on various technologies both on front end and back end .On front end I was assigned task of designing screens using jsp and servlets .Back end work included Oracle data base management using tool pl/sql developer ,used to query data ,create procedures ,views, triggers etc.

User Interface Design:

Following Step: 1. Disbursement Request fired from the Browser to eCredit server 2. eCredit server call Storage Procedures in eCredit Database server 3. eCredit Database fires a Request Message to Local Socket Listener. 4. Whenever the Local Socket Listener receives a message it converts the message into .dat extension file. This message file sends to Request Client Listener

Account Creating Process

Brow Brow ser ser
1 5 1 4

CM SSe rver

CMS Datab ase Serve r 3 Local Socket Listene r

1 2

for verification.
5.After verification Request Client Listener will transform message file to the XBus server. 6.Now the XBus server follows the following series of steps mentioned in diagram XB us Ser ver

4 5 Reques t Client Listene r 6

(Record insert into intermediate DB) 7.After inserting the record in intermediate Database, it will send Account creation request message to the CBS Socket Listener.
8.CBS Socket Listener will intimate the CBS server

1 3

1 1

CB S Ser ver

9.CBS server reads the record and processes it. 10.Response from CBS server will insert the record in intermediate Database. 11.After inserting the record in intermediate Database, it will send Account creation response message to the Local Socket Listener.
Same step follows mention in step no 4. Same step follows mention in step no 5.

CBS Socket Listene r 9

1 0

Interf ace Datab ase Serve r

XBus Internal Process Steps .dat extension file xml file (xml + dtd) file SQL (insert statement) xml file

following series of steps mentioned in diagram

(Record insert into eCredit DB)

Response display client Browser fg

Steps for Disbursement of Loans:

After the CIF No. (Customer Identification Number ) has been generated for a borrower we need to extract the account numbers for that customer from CBS. For this purpose Interface named Disbursement of Loans has been created in Sanction module of eCredit. For each facility entered when the appraisal for that borrower is created a separate account number is generated from CBS. The facility chosen while creation of appraisal should have an entry in the policy screen Product wise facility mapping . When we press on Disbursement of loan button the following procedure takes place. 1. Request fired from the jsp goes to eCreditServer 2. The package in eCreditDB is called .T_LOAN_SANC in eCreditDB is updated and column PT_20_PRGM_5 is set to one. This is a flag which when set to one depicts that the particular sanction has been disbursed to CBS for account info. 3. The package PK_INTERFACE_CBS in EcreditDB fires a request msg to Local Socket Server through the function fn_get_ACCReqMessage. This request msg is in the form of eCreditInfile067001.dat file. 4. Local Socket Server sends this message to Request Client Server . 5. Request Client Server sends dat file to xBus sever . 6. Now the xBus server follows the following series of steps mentioned in standard.confg file .dat xml xml + dtd sql (insert stmt ) 7. This insert stmt inserts record into the intermediate DB in the table INTF_ACCOUNT . At the time of insert the flag PROCESS_STATUS is set to zero . (The number of inserts depend on the number of requests which in turn depend on the number of facilities) 8. After insert a trigger is fired which sends a request message to the CBS server . 9. CBS server reads the request and processes it . 10.Response from CBS updates INTF_ACCOUNT (intermediate DB) and sets PROCESS_FLAG equal to one .It also inserts data into T_Z_INTF_ACC_DTL (intermediate DB).

11.Insert into this table fires a trigger which sends a response msg to Socket server in the form of eCreditOutfile-1-067002.dat file . 12.Local Socket Server sends this message to Request Client Server . 13.Request Client Server sends dat file to xBus sever . 14.Now the xBus server follows the following series of steps mentioned in standard.confg file .dat xml xml + dtd sql (insert stmt ) 15.This insert statement inserts data(account number) into the eCreditDb in T_Z_INTF_ACC_DTL.

8.1 Future Scope of Development

As is very wisely said that there is always a scope for improvement. Although the CMS Project incorporates very extensively the operations of the Credit Department of a Bank, there are some points that can be incorporates to make the project more alluring to other customers of TCS. This project is being developed keeping in mind so that it can be customized to meet the needs of any other bank, and hence the future scope of the project is very wide. This is being aggravated by the fact that the banks are anticipating such a system: wherein they can make their Credit Business turn into eBusiness and yield faster and better returns than the existing manual work that is being performed by them. LOS can be customized according to the requirements of other banks and the area offices, zonal office levels of a bank can be accommodated into the system to cover the entire gamut of banks operations.

9.1 Conclusions Drawn

The industrial training that I underwent was truly a very rewarding experience for me in more than one way. It has given a big thrust to my technical knowledge as prospective Software professional. It has also helped me enhance my skills on the personal front. And I feel truly satisfied by the fact that getting a chance to work in such a real live application project is rare. I think I have exploited the opportunity that came my way to the fullest extent by increasing my technical know-how and also gaining the valuable work experience from the esteemed organization. I truly gained an insight into the working of the real web-based systems. This was even more rewarding as it was a typical real world situation. This project has strengthened my knowledge of JSP, Struts, Servlets and Enterprise Java Beans. CMS is a state-of-the-art web-based banking solution, with workflow management offering significant competitive advantages as it increases the productivity and improves the quality of service to the clients. It can be installed at designated branches and ROs of the bank for processing of loans and for handling credit administration of the bank. It supports comprehensive MIS needs of the bank and suits international banking requirements. The suite of reports can help the bank in getting timely feedback for taking corrective actions and control.

10.1 APPENDIX - A
Definitions and Acronyms
ACRONYM GL ML PL TM DEFINITION/DESCRIPTION Group Leader Module Leader Project Leader Team Member

10.2 Appendix B Bibliography

The Complete Reference: Java 2 by Herbert Schildt The Complete Reference: Java Server Pages by Phil Hanna Java Servlets by Karl Moss Inside Servlets by Dustin R. Callaway Mastering Enterprise JavaBeans by Ed Roman SQL, PL/SQL: The Programming Language of ORACLE by Ivan Bayross http://java.sun.com/j2ee BEA WebLogic Server by Joe Zuffoletto