Documente Academic
Documente Profesional
Documente Cultură
SUBMITTED BY
ANIL KUMAR YADAV
Submitted in the partial fulfillment of the requirements for the degree of B.C.A
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.
Policy Credit Proposal Credit Appraisal Monitoring MIS Document Management System Role Based Security
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.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
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.
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 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.
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
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.
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.
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.
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.
Sanction
OPERATIONS
O P E R A
Policy Norms
T I O N S
Monitoring
Asset Classification
MIS
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
Benchmarks Circulars
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
Export Different Methods of Lending like: Turnover Method First Method Second Method Cash Budget Methods
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
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.
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:
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
Unavailable
Unload
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.
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.
compiled
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.
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.
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.
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.
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.
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
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
Client PC : 1 No each
User
Sanctions, Queries Credit Policy
HO (P&D)
Branch
Proposals, Monitoring reports, Clarifications
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
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
HTML/ XML
Browser Clients
EJB Components
Report Server
Workflow client
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.
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.
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:
- 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.
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
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.
Pre-requisites Maintain Policy Masters Maintain System Parameters Maintain Common Params Maintain Module Params
Maintain details
Borrower
Pre-requisites Maintain Policy Masters Maintain System Parameters Maintain Common Params Maintain Module Params Maintain Borrower details Create Loan Sanction
Appraisal Others
Print pending lists Print Clarifications letter Print Awaiting clarification list
Print pending lists Print Clarifications letter Print awaiting clarification list
Consolidate
LAC Reports
MIS reports at RO
MIS Reports at HO
Upload RO reports
Consolidate Reports
Proposals (RO/HO)
Asset classification
Appraisal Capture borrower details Capture proposal details Capture appraisal note Capture Policy guidelines
Loan sanction
Monitoring Capture BCC Capture MOR Capture QIS Capture POA Policy guidelines
Report
s
Policy guidelines
MIS Reports
Control Credits HO/RO Recovery & law RO Surveillance Rural development Statutory Senior management
Credit Appraisal
Appli catio n
Borrower details
Contact
Proposal details
Link
Reports Approved Appraisal Capture Appraisal Note Financial details Ratio /BE analysis Terms and conditions Recommen dations
Report
Report
Credit Monitoring
Queries to/ Clarifications from branch
Review BCC at RO
Ttt
Quarterly Information System Form I MOR/QIS Forms II & III/ CA Stock Verification
Enter details at RO
Review at RO
Download at RO for HO
Review at HO
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.
CM SSe rver
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
(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.
XBus Internal Process Steps .dat extension file xml file (xml + dtd) file SQL (insert statement) xml file
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.
10.1 APPENDIX - A
Definitions and Acronyms
ACRONYM GL ML PL TM DEFINITION/DESCRIPTION Group Leader Module Leader Project Leader Team Member