B.C.S.E. Final. Project Report. e-krishi. ssd. Jadavpur University. Department of Computer Science and Engineering

Transcription

1 ssd e-krishi B.C.S.E. Final Submitted by: Project Report Under the guidance of: Prof. Dr. Pradip K. Das Jadavpur University Department of Computer Science and Engineering Somak Aditya Partha Bhaumik Ritaban Dey Anirban Sinha ( ) ( ) ( ) (04886) CENTER FOR MOBILE COMPUTING AND COMMUNICATION

2 Jadavpur University Department of Computer Science & Engineering This is to certify that Somak Aditya (Reg. No of , Class Roll No ), Partha Bhaumik (Reg. No of , Class Roll No ), Ritaban Dey (Reg. No of , Class Roll No ) and Anirban Sinha (Reg. No of , Class Roll No ), students of Jadavpur University Computer Science & Engineering Department, have done a Project under my supervision titled An Integrated Framework for providing Location based Agricultural Information to Mobile Clients in Regional Indian Language (Bengali). The project is approved for submission towards fulfillment of the requirements for the degree of Bachelor of Computer Science and Engineering (BCSE) under Jadavpur University (Prof. Dr. Pradip. K.Das) (Dr. Sarmistha Neogy) Project Supervisor Dean, Computer Science & Engineering Dept. Faculty of Engineering and Technology, Jadavpur University Mody Institute of Technology and Science Jadavpur, Kolkata 32. Lakshmangarh , Rajasthan, India & Former Professor, Computer Science & Engineering Dept. Jadavpur University, Kolkata 32. & Former Director, Centre for Mobile Computing and Communication, Jadavpur University.

3 An Integrated Framework for Providing Location-based Agricultural Information to Mobile Clients in Regional Indian Language

4 Acknowledgement 1 Acknowledgement We are indebted to our respected supervisor Prof. (Dr.) Pradip K. Das, Dean, Faculty of Engineering and Technology, Mody Institute of Technology and Science, Lakshmangarh , Rajasthan, India and Former Professor, Computer Science and Engineering Department, Jadavpur University, who has been there as a friend, philosopher and guide throughout our endeavour and without whose ideas, suggestions, support and guidance this project would not have been possible. We also express our gratitude to Dr. Sarmistha Neogy, Department of Computer Science and Engineering, Jadavpur University, our advisor in the final stages of the project documentation. We heartily acknowledge the support and co-operation of Anirban Ghosh of the Centre for Mobile Computing and Communication, Jadavpur University, Salt Lake. He provided us with necessary equipment like notebooks, modems and cellphones and helped us to perform our project work in world class facilities of the CMCC laboratory. We also extend our gratitude to our seniors Satadru Pan, Ayan Biswas, Debarshi Roy and Sourav Mondal for their generous assistance and invaluable suggestions.

5 Contents 2 Contents Introduction 05 Section 1: Overview System Architecture Presentation Tier Application Tier Data Tier Design Principle 11 Section 2: Client Introduction Overview Design of GUI using Canvas Advantages of using Canvas Buttons using images Types of images used Positioning of images on canvas Design of GUI using Screen Advantages of using Screen Some code snippets Screens and Navigation Navigation between Screens Home/Main Screen Crops Screen Secondary Services Screen Disease Symptoms Screen Weather Screen Soils Screen Fertilizers/Insecticides Screen Format of the SMS GUI Design Principles Adding more options in a screen Handling of events 46

6 Contents 3 Section 3: Middleware Introduction Overview Block Diagram Subcomponents of middleware Receipt of SMS Java SMS API Description of the classes used Weather Database Message Parsing Parsing of the incoming message Description of the SMS string Method of parsing Examples Query Generation Generating the SQL Query Examples Flexible Design Sending query to server and receiving result Reply Generation Algorithm for reply generation Examples Translation Conversion of reply from English to local language Rephrasing the English sentence English grammar Bengali grammar Actual Translation Procedure Examples Location Specific Service Updation of the LANGUAGE database in the middleware 80 Section 4: Server Introduction Description Apache Tomcat MySQL JDBC (Java Database Connectivity) Servlet Database How server works Test cases 94

7 Contents 4 Section 5: Performance Analysis Analysis Methodology Scenario Scenario Discussions 102 Section 6: Installation Client/customer side installation Introduction Minimum requirements Installation Procedure Configuration How to use Middleware installation Introduction Requirements Procedure Test case Server side installation Introduction Minimum requirement Installation Procedure Server Setup 117 References 118

8 E KRISHI INTRODUCTION An introduction to the world of e-krishi

9 Introduction 6 Introduction Wireless Communication, especially personal mobile devices, has seen tremendous growth over the past few decades. As a consequence, value-added data services, WAP based applications and web (GPRS, EDGE and 3G) services are in high demand. This trend also enables the mobile service providers to increase the Average Revenue Per User (ARPU) and attract more consumers towards such services. Services like location-based services, medical and agricultural tele-consultation, banking and finance on the move, advertising campaigns by prominent business houses and government-aided mass literacy campaigns are key components of this portfolio. All such services can have a common centralized architecture based on some robust wireless communication technologies and can be typically subdivided into four explicitly distinguishable phases: Query Submission, Interaction with User, Query Processing, Service Provision. The implementation details of a phase can vary from one kind of service to the other. Agricultural Consultancy Services use existing affordable technologies to provide information about market prices of various agricultural commodities, advice about agricultural practices, fertilizers, insecticides and pesticides, and weather forecast information in order to increase farm productivity. Such services bridge the communication gap between the farmer and the government and thus stop the exploitation of the farmers in the hands of the middlemen. Our model provides a way of tackling the problems perennially plaguing Indian agriculture characterised by fragmented farms, weak infrastructure and the involvement of numerous intermediaries. In this system, farmers send requests to avail the service from their mobile phones and get back appropriate response in real time after the request is processed in some back end processing system. Here we propose a 3-tier architecture model involving a client mobile device, a reflective middleware and a back-end server to create an integrated framework for the providing of agricultural information to farmers in remote parts of rural India. Context aware ubiquitous computing emphasizes on using context of user devices to provide services that are appropriate to particular space and time. The task involved in the middleware can be generalized as sensor data aggregation, context reasoning and context

10 Introduction 7 aggregation. Here we have used a context aware reflective middleware architecture for providing the information stored in a database in a remote back-end server to the farmers in a local Indian language. Farmers use a graphical user interface (GUI) in local language in their mobile devices to send the request. Middleware receives the request, obtains the information in English from the database in back-end server, transforms it into local language according to the requirement of the farmer and dispatches the reply to the mobile device of the farmer. So the middleware is a reflective middleware because it changes its translation scheme according to the requirements of the user. This report is organized in six sections. Following overview (Section 1), client, middleware and server designs are presented in Sections 2, 3 and 4 respectively. Section 5 contains the performance analysis and experimental results. Section 6 contains the installation and configuration details.

11 SECTION 1 OVERVIEW An Overview of the System and the Architecture

12 Section 1 Overview 9 Overview: Top Level Design and Architecture 1.1 System Architecture In the realm of software engineering a multi-tier architecture is a client-server architecture in which an application is executed by more than one distinct software component. Here we use the most prevailing and popular of the multi-tier architectures namely 3-tier architecture to model our system. In a typical system incorporating 3-tier architecture there are three essential tiers or layers: Presentation, Application and Data. Our system involves these three tiers in the respective units Client mobile device, Middleware and Back-end database server. Figure 1.1: Top level design Figure 1.1 depicts a top-level view of the entire system showing the essential and discrete software systems that comprise the 3-tier model.

13 Section 1 Overview Presentation Tier This is the topmost layer of the application as viewed by the user. It consists of a graphical user interface (GUI) in local language in the J2ME-enabled mobile phone of the farmer. The GUI is menu-based in which the farmer navigates to and selects the appropriate option corresponding to the information he/she wants to request for. The application then sends a query in a predefined format to the mobile number of the service center. The farmer receives the reply in his mobile phone as a short message (SMS) in local language Application Tier This is the thickest software layer that resides in the middleware and is a logical tier which controls the functionality of the application by performing detailed processing. This essentially consists of four broad modules a GSM modem driver, an SMS parser application, a network interface application and an English-to-local language converter. The GSM Modem Driver is basically a Java application to interface a GSM modem which is connected to the serial port of the middleware application server. It implements the Java communication API and a third party Java SMS API for the purpose of reading SMS one by one from the memory of the SIM card inserted into the GSM modem. The driver then transfers the data read from the SMS to the parser module. The Parser is responsible for context checking it parses the SMS to check what information is requested. If the SMS does not match any of the predefined formats the parser simply sends an error message back to the GSM modem driver which sends an error SMS back to the client mobile device. On the other hand if the format matches a predefined type, the different fields in the SMS are separated to identify what service is requested and in which local language. The query generator module of the parser then formulates a SQL query and forwards it to the network interface application. The Network Interface Application is involved in communication with the remote back-end server over the internet. It sends the query generated by the parser to the server and receives the information requested in English. Then it forwards the English answer to the English-to-local language converter module. The English-to-local language Converter is responsible for translation of the English reply to a local language before forwarding it to the GSM modem driver which in turn transmits the reply in local language back to the client

14 Section 1 Overview 11 mobile device. For the translation purpose, two sub-modules are involved a converter C which rearranges and modifies the English reply, and a translator T which does word by word translation from English to local language Data Tier This is the database layer and is extensively used for data storing and retrieving. The main agricultural information database which stores all information to be relayed to the farmer as per request comprises this layer and this resides in a remote back-end server which communicates with the middleware through the internet. The Agricultural Database Interface Application is basically a J2EE servlet that runs in a servlet container like Apache Tomcat or Glassfish and it serves to receive the SQL query from the middleware through the Network Interface Application. The servlet then connects to the main agricultural database, retrieves the information as per query and retransmits the information through the internet to the Network Interface Application in the middleware. 1.2 Design Principle All layered architectures are typically characterised by a front-end and a back-end. Here the Presentation Tier is the front-end which directly interacts with the user (farmer) through the mobile device. The middleware and the back-end server comprise the back-end which is involved with all the processing and information retrieval and remains invisible to the user. The greatest advantage of layered architecture lies in the maintenance of the software. Such architecture enables the roles and responsibilities of a computing system to be distributed among several independent computers which connect through a network. Each layer is independent of the other and can be modified, repaired, upgraded, replaced and even relocated keeping the other layers totally unaffected by the change. This independence from change reflects a vital property of the Object-Oriented Programming practice encapsulation.

15 SECTION 2 CLIENT User Interface Design in the Mobile Device of the User

16 Section 2 Client 13 Client 2.1 Introduction In this section we describe in detail the front-end design the design, implementation and action of the User Interface on the Client device. The client device essentially used by an agricultural practitioner is a commonly used cellular phone. A cellular phone (also called mobile phone) is a long-range, electronic device used for mobile voice or data communication over a network of specialized base stations known as cell sites. In addition to the standard voice function of a mobile phone, telephone, current mobile phones may support many additional services, and accessories, such as SMS for text messaging, , packet switching for access to the Internet, gaming, Bluetooth, infrared, camera with video recorder and MMS for sending and receiving photos and video, MP3 player, radio and GPS. Traditional cellular telephones have a keypad that contains numbers and letters. Developers seeking to build applications that run on cell phones must strike a balance between a thick client and a thin client. A thick client is front-end software that contains the logic to handle a sizable amount of data processing for the system. A thin client is front-end software that depends on back-end software for much of the system processing. Mobile devices used by farmers are expected to just provide the minimal specifications for functioning of the application. Constraints are several memory, small screen, low clock frequency of mobile processor and limited battery power. To cope with these, the application running on the mobile phone of the farmer is limited to just presenting a Graphical User Interface which provides menu-based option selection and creating a formatted query string that is transmitted as SMS to the server side. The bulk of the processing and data storage is dealt with by the middleware and server. Hence this design is essentially an implementation of a thin client. The essential focus in designing the front-end is in simplicity one that can be used by farmers with minimal training and experience. Agricultural workers cannot be expected to have working knowledge of the intricacies of a cell phone and applications. So the user

17 Section 2 Client 14 interface should be as simple and user-friendly as possible. Moreover, mobile phones used by farmers can be typically expected to be low-end as neither are farmers power users who can make ample and justifiable use of the features of a high-end phone nor can they afford a highend phone and the government cannot be expected to distribute expensive handsets to farmers in a large scale. So our design just assumes that a mobile set should have the basic keypad, a colour screen, Java 2 Micro Edition (J2ME) support with MIDP 1.0/2.0 and CLDC 1.0, 200 kilobytes of user memory, local language support and SMS sending/receiving capability. No other features or specifications are required for the functioning of the application. Mobile phone applications can be developed using one of several platforms Java 2 Micro Edition (J2ME), Symbian C++, Windows Embedded Compact (Win CE) or Linux. Of these J2ME is the most widely used platform and is ubiquitously supported in almost all mobile devices ranging from elementary handsets to high-end PDAs, palmtops and communicators. Symbian C++ and Windows CE can be used to develop very powerful applications but they have the limitation of running only on Symbian Series 60 devices and Windows Mobile devices respectively. Moreover, our application is not intended for power users and does not implement any advanced API s that J2ME do not support. In light of all these arguments, J2ME is the best solution approach in the current scenario to develop a simple Graphical User Interface based application using minimal amount of memory and no advanced API s or Embedded OS features, and one that can run on almost all devices from low-end to business.

18 Section 2 Client Overview We have incorporated a Graphical User Interface (GUI) in local language into the mobile application which in simplest terms converts the request of farmer into English string in back-end and sends that English SMS to the middleware. The mobile user downloads the application from the Internet in the language of his choice once and for all. After this, whenever he wishes to place a query, he has to select from a specified set of options or image icons only. The SMS query, which is in a predefined format in English, is prepared automatically by the system in response to the icons selected. This can be abstracted as the transformation: equerystring = L2E (lquery) (1) where equerystring is the formatted SMS transmitted by client to middleware, lquery is the service queried by the farmer, and L2E is the back-end conversion module that prepares the SMS in appropriate format based on the selection of options in the GUI by the farmer. It can be noted that this is possible only because the number of possible query strings that can be generated is limited. This helps in three ways: 1. The possibility of an undefined SMS format that can give rise to the problem of transmitting back an error message to the end user is completely eliminated. 2. It is very advantageous if the incoming SMS is in English rather than in a local language as that would have necessitated a converter for each local language. An incoming SMS in English renders a touch of uniformity to the system the local language the answer must be transmitted back is appended as a part of the SMS query only which the middleware can process. 3. This system eliminates any need of knowledge of the SMS format and back-end processing for the naïve farmer who does not have to care about what SMS is being sent and can just select options from the GUI.

19 Section 2 Client 16 The design of the GUI involves creating a few menu-based screens which provide options from which a farmer can choose his required one. The implemented screens are home screen, crops screen, disease symptoms screen, services screen, soils screen, weather screen and fertilizers/insecticides screen. The user can navigate between these screens through Select and Back options provided along with. Depending on the chosen option in a screen the SMS is generated in a pre-defined format in the back-end. For designing the screens we have used two of J2ME s GUI design classes Canvas and Screen. Canvas is the lower level display class which gives complete freedom and flexibility to the developer for designing the interface. Typically screens designed using Canvas are rich in graphics and images, and provide a higher visual user experience. Screen, on the other hand, is the higher level display class which provides in-built classes like List which can be used to create a selection-based menu. Screen based display pages are low on graphics and images and generally applications built using Display are light on memory.

20 Section 2 Client Design of GUI using Canvas Advantages of using Canvas The Canvas class of J2ME and its derivatives are used to gain low-level access to the display, which is necessary for graphic- and animation-based applications. A graphic is used with a canvas. An instance of the Canvas class can be considered as an artist s canvas on which one can draw images that might include text. An instance of the Graphics class is similar to the artist s tools that are used to draw an image. For example, colour, lines, and arcs are some of the graphic tools available to create an image on the canvas. The Canvas class and the Graphics class give total pixel control over everything that appears on the canvas. This low-level control is particularly helpful in our context as it can be used to position images at precise locations all over the canvas. The collection of images created using aesthetic colours and placed at appropriate locations in the canvas renders an integrated graphical feel to the user interface Buttons using images The first part of the architecture is the Local Language GUI which resides at users mobile. The problem in designing such GUI s is that J2ME canvas doesn t support buttons. So it is not possible to create buttons having label in local language. So we took a totally different approach.we implemented buttons using PNG images of local language menus. For each button we keep two images: one for the button in the ON state and one for the button in the OFF state. For example given below are the images for buttons "আবহ oয় " (weather) and ব ধ ক প (cabbage).

21 Section 2 Client 18 (a) (b) Figure 2.1: Images for "আবহ oয় " (weather) button in (a) ON and (b) OFF states (a) (b) Figure 2.2: Images for ব ধ ক প (cabbage) button in (a) ON and (b) OFF states In general OFF state buttons are created using images of darker colour while ON state buttons are created using images of lighter colour. The colour of the text is also varied to differentiate between the two states Types of images used Images are essentially of four distinct types: 1. Header: This resides at the top of the canvas and shows the name of the application i-ক ষ (e-krishi). Figure 2.3: Image for header 2. Information: This image resides just below the header and just above the buttons and it instructs the user to select an appropriate option from the list of buttons.

22 Section 2 Client 19 (a) (b) (c) (d) (e) (f) Figure 2.4: Images for Information for (a) Home and Services Screens, (b) Disease Symptoms Screen, (c) Crops Screen, (d) Weather Screen, (e) Soils Screen and (f) Fertilizers/Insecticides Screen 3. Button: These are the images used for buttons which can be in ON state or OFF state as previously discussed. The user scrolls through the list of buttons which toggle between ON and OFF states as they get selected / de-selected. The buttons lie just below the Information and just above the Footer. (a) (b) Figure 2.5: Images for Buttons: (a) ON state and (b) OFF state 4. Footer: This resides at the bottom of the canvas and provides naming for the right, left and center soft key action buttons of the mobile handset. Three typical actions are চয়ন (select), প বর বতর (back) and ps ন (exit). Figure 2.6: Images for two types of Footer

23 Section 2 Client Positioning of the Images on the Canvas Canvas Layout: The canvas is divided into a virtual grid in which each cell represents one pixel. Coordinates mark the column and row of a cell within the grid (Figure 6). The x co-ordinate represents the column, and the y coordinate represents the cell s row. The first cell located in the upper-left corner of the grid has the coordinate location of (0, 0) where the first zero is the x coordinate and the other zero is the y coordinate. The size of the canvas is device dependent since canvas size and the screen size are the same. The canvas size is measured in pixels. Typical sizes are 128 x 160, 176 x 208, 176 x 220, 240 x 320 (QVGA), 352 x 416, 320 x 480, 480 x 640 (VGA), 480 x 800 (WVGA). Figure 2.7: Top left corner of the canvas and co-ordinates Picture Positioning: The whole window is a canvas on which the images are displayed. The pictures are displayed at precise pixel locations depending on the size of the images and the size of the screen. We are developing the application in full screen mode. This implies that the size of the screen is equal to the size of the canvas. To visualize the positioning co-ordinates of the different images on the canvas, let us first consider the sizes of the different items in co-ordinates as follows.

24 Section 2 Client 21 Item Horizontal Size Vertical Size Screen sx sy Canvas cx cy Header Image hx hy Information Image ix iy Button Image bx by Footer Image fx fy Table 2.1: Horizontal and Vertical Sizes (in pixels) of the different components of Canvas Here, we have sx = cx and sy = cy as we are using full screen mode and canvas spans the entire screen. Also, hx = ix = bx = fx = cx i.e. all images are equal in width and span the canvas from left to right horizontally. Position of an image in the canvas is specified by the co-ordinates of the upper left corner of the image in the canvas. The positions of the different images on the canvas based on their sizes and the size of the canvas are shown in Table 2. Image X co-ordinate Position Y co-ordinate Header 0 0 Information 0 hy Button k ( k = 0, 1, 2,..., c b 1) 0 hy + iy + k * by Footer 0 cy fy Table 2.2: Positions of the images in the canvas

25 Section 2 Client 22 Total no. of buttons that can fit in the screen at one time, c b = (cy hy fy iy ) / by As the total no. of options and hence the total no. of buttons in a screen can be greater than c b, hence there is a scrolling mechanism. At any time only cb buttons are displayed; as the user scrolls up or down more buttons come into view. Scrolling up while at top of the list brings the user to the bottom of the list; scrolling down while at bottom of the list brings the user to the top of the list. Selection / De-selection: At one time any one of the options in a screen is selected while all the others are deselected. We just keep track which button of a screen is currently selected and display its ON state image. The rest of the buttons are displayed in OFF state. As a user scrolls down, the button below the current selected button gets selected i.e. image with ON state is displayed, while the current selected button is de-selected. Same thing happens while scrolling up. In this way users change their selections before proceeding.

26 Section 2 Client 23 (a) (b) (c) Figure 2.8: Screenshots depicting positioning of images on canvas and selection / deselection of options. The GUI when (a) র গ (disease), (b) স র/ক টন শক (fertilizer/insecticide), (c) ব ণ (brinjal) and (d) ক ফ (coffee) is selected. (d)

27 Section 2 Client Design of GUI using Screen The display is a crucial component of every J2ME application since it contains objects used to present information to the person using the application and in many cases prompts the person to enter information that is processed by the application. The J2ME Display class is the parent of Displayable. The Displayable class has two subclasses of its own: Screen and Canvas. The Screen class is used to create high-level J2ME displays in which the methods of its subclasses handle details of drawing objects such as radio buttons and check boxes. In contrast, the Canvas class and its subclasses are used to create low-level J2ME displays. We have already described how we use the Canvas class to design the GUI of our application using buttons, information panels, headers and footers. In this section we look at an alternative approach for designing the GUI building a J2ME high-level display by focusing on the Screen class and its derived classes the List, the Command and the Ticker Advantages of using Screen The Screen class and its derived classes can be used to generate powerful visual tools when developing a user interface for your J2ME application. These classes contain methods that generate radio buttons, check boxes, lists, and other familiar objects that users expect to find on the screen when interacting with the application. The List class is a subclass of the Screen class and is used to display a list of items, as in a menu, and enables the user to choose one of those items. This fits nicely with our application scenario where we have a number of menus providing options for the user to select. The List provides options like selecting and scrolling which we don t have to implement like we had to do in case of Canvas and thus LOC (lines of code) is greatly reduced. The Command class is used to create a Command object that can be associated with practically any class except the Alert class. We use the command class to add commands like Back, Select and Exit to the lists. The Ticker is a variable of the Screen class that causes text to scroll on the screen like a stock exchange ticker tape. We use a ticker to display the name of our app e-krishi at the top of each of the lists.

28 Section 2 Client Some code snippets Here we take a look at some code snippets to demonstrate how the GUI design using List has been implemented. Creating the array of service names in Bengali using Unicode: private static final String services[] = {"\u09b0\u09cb\u0997", // rog "\u0986\u09ac\u09b9\u09be\u0993\u09df\u09be", // abohaowa "\u09b6\u09b8\u09cd\u09af", // shoshyo "\u09ae\u09be\u099f\u09bf", // mati "\u09b8\u09be\u09b0/\u0995\u09c0\u099f\u09a8\u09be\u09b6\u0995" // saar/keetnashok }; Creating the array of service images that will be shown along with each service item in the list: for(int i=0;i<num_of_services;i++) SERVICE_IMAGES[i] = Image.createImage("/services/"+SERVICE_NAMES[i]+".png"); Creating the header ticker: header=new Ticker("\u0987-\u0995\u09C3\u09B7\u09BF"); //

29 Section 2 Client 26 Creating the service list using the List class: service_list = new List("\u09AA\u09B0\u09BF\u09B7\u09C7\u09AC\u09BE \u099a\u09df\u09a8 \u0995\u09b0\u09c1\u09a8:", List.IMPLICIT, services, SERVICE_IMAGES); // porisheba chayan korun service_list.setticker(header); Creating the exit command: exit = new Command("\u09AA\u09CD\u09B0\u09B8\u09CD\u09A5\u09BE\u09A8", Command.EXIT,0); // prosthan Adding the exit command and the command listener to the service list: service_list.addcommand(exit); service_list.setcommandlistener(this); Displaying the service list on the screen: display = Display.getDisplay(this); display.setcurrent(service_list);

30 Section 2 Client Screens and Navigation To keep thins short and simple, we have minimized the number of screens and hence the complications. A farmer cannot be expected to work around a complex application and place his request; also it is taken for granted that a farmer with little English education can type in a request in a textbox and that too in a predefined and specified format. So all requests for services are placed by choosing appropriate options from menu-based screens which form the core of the GUI of the application. The different screens used and their functions are shown in Table 2.3. Screen Name Function Home / Main Initial screen that appears when the application is started. Provides a menu from which user chooses what service he wants to avail. Crops Screen that displays a list of crops from which user chooses one according to his requirement. Symptoms Screen displaying a list of common disease symptoms from which user chooses the one he is concerned with. Services Provides a list of services related to crops cost price, sale price, agricultural advice, and availability in market. Weather Screen that displays various time spans for weather forecasts. User chooses the duration for which he wants to know the forecast. Soils Screen showing a list of soils from which user chooses the one he wants to sow in. Fertilizers / Insecticides This provides a list of common fertilizers and insecticides available in the market which are generally used in agricultural practices. Table 2.3: Names of different screens and their functions

31 Section 2 Client Navigation between Screens Users can navigate between the screens using the action soft keys provided on the keypad of the mobile handset. A soft key is a button, located below the display, which performs a function dependent on the text shown just above it at that moment on the display. Figure 8 shows the typical soft keys and scroll keys in a general mobile handset along with the action texts in the display on the screen. Figure 2.9: Soft keys and scroll keys in a typical mobile handset As shown in figure 2.9, the three soft key actions provided by the application are: চয়ন (Select) This selects an option from the list and then brings up the next screen; or it sends the query SMS to the middleware and then exits the application. ps ন (Exit) This action closes the application and returns to the mobile OS. প বর বতর (Back) This action takes the user back to the previous screen i.e. the screen that was encountered by the user before coming to the current screen.

32 Section 2 Client 29 Figure 2.10 shows a Non-Deterministic Finite Automaton (NDFA) modeling the navigation between the screens. Each state (box) in the figure shows a screen; the navigation from one screen to another is done by actions (SELECT, BACK, EXIT) which are shown on the arcs connecting one state to another. The user starts at the applications menu of the mobile handset; from the list of applications he selects e-krishi and launches it. The first screen encountered after launching is the Home Screen. Subsequently navigation is done by choosing appropriate actions through soft keys. At any screen choosing EXIT brings the user back to the application menu of the phone OS. Figure 2.10: NDFA showing the navigation between the different screens

33 Section 2 Client Home/Main Screen The home screen is the first screen encountered by the user after launching the application from the applications menu of the mobile device. The screen displays a list of services from which the user chooses the one he wants to avail. Table 2.4 shows the services along with what they offer and also the string which is appended to the SMS query if the user selects the services. Service Name What It Offers String appended to SMS র গ (Disease) The user selects this option if he wants to know about the remedy to a plant disease. disease আবহ oয় (Weather) The user selects this option if he wants to know the weather forecast for up to one week. weather শসয (Crop) The user selects this option if he wants to know various information regarding crops cost price, sale price, availability in market, and agricultural advice. crop ম ট (Soil) The user selects this option if he wants to know information regarding a soil type. soil স র/ক টন শক (Fertilizer/Insecticide) The user selects this option if he wants to know market availability, prices and actions of a fertilizer or an insecticide. fertilizer Table 2.4: List of Services in the home screen menu, their functions and the Strings appended to the SMS query by selecting each of the services The two soft key actions provided by the home screen are: চয়ন (Select) This selects an option from the list and then brings up the next screen accordingly.

34 Section 2 Client 31 ps ন (Exit) This action closes the application and returns to the mobile OS. The actual layout of the home screen is shown in the screenshots in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says নmবতর ত লক থ ক প র ষব চয়ন ক ন (Select a service from the menu below). Below the information panel lie the buttons or options র গ (Disease), আবহ oয় (Weather), শসয (Crop), ম ট (Soil), স র/ক টন শক (Fertilizer/Insecticide). Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select) and ps ন (Exit). (a) (b) Figure 2.11: Screenshots of the home screen when (a) র গ (disease) and (b) স র/ক টন শক (fertilizer/insecticide) is selected

35 Section 2 Client Crops Screen The crops screen is encountered by the user after selecting শসয (crop) or র গ (disease) from the home screen. The screen displays a list of crops from which the user chooses the one he is concerned with. Table 5 shows a probable list of crops along with the string which is appended to the SMS query if the user selects the crops. However, the list provided in Table 2.5 can be easily extended to include more crops. Crop Name ধ ন (paddy) গম (wheat) প ট (jute) আখ (sugarcane) চ (tea) ক ফ (coffee) পটল (parwal) u c (bitter gourd) ঝ ঙ (cucurbita) আল (potato) ব ণ (brinjal) ব ধ ক প (cabbage) ফ লক প (cauliflower) kম ড় (sweet gourd) ভ (maize) ত ল (cotton) গ জর (carrot) শশ (cucumber) প য় জ (onion) ল u (gourd) ম ল (radish) টময ট (tomato) String appended to SMS crop1 crop2 crop3 crop4 crop5 crop6 crop7 crop8 crop9 crop10 crop11 crop12 crop13 crop14 crop15 crop16 crop17 crop18 crop19 crop20 crop21 crop22 Table 2.5: List of Crops in the crops screen menu and the Strings appended to the SMS query by selecting each of the crops

36 Section 2 Client 33 The three soft key actions provided by the crops screen are: চয়ন (Select) This selects an option from the list and then brings up the next screen i.e. the Secondary Services Screen or the Symptoms screen. ps ন (Exit) This action closes the application and returns to the mobile OS. প বর বতর (Back) This action takes the user back to the previous screen i.e. the Home Screen. The actual layout of the crops screen is shown in the screenshots in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says নmবতর ত লক থ ক শসয চয়ন ক ন (Select a crop from the menu below). Below the information panel lie the buttons or options the list of crops. Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select), প বর বতর (Back) and ps ন (Exit). (a) Figure 2.12: Screenshots of the crops screen when (a) ব ণ (brinjal) and (b) ক ফ (coffee) is selected (b)

37 Section 2 Client Secondary Services Screen The secondary services screen is the screen encountered by the user after selecting শসয (crop) from the Home Screen and then selecting a crop from the Crops Screen. This screen displays a list of services related to crops from which the user chooses the one he wants to avail. Table 2.6 shows the services along with what they offer and also the string which is appended to the SMS query if the user selects the services. Service Name What It Offers String appended to SMS kয়ম লয (Cost Price) The user selects this option if he wants to know about the cost price of a crop. costprice বkয়ম লয (Sale Price) The user selects this option if he wants to know the selling price of a crop. saleprice লভয ত (Availability) The user selects this option if he wants to know whether the crop he is concerned with is available in the market or not. availability uপ দশ (Advice) The user selects this option if he wants to get advice regarding agriculture of a crop. advice Table 2.6: List of Services in the Secondary Services screen menu, their functions and the Strings appended to the SMS query by selecting each of the services The three soft key actions provided by the Secondary Services screen are: চয়ন (Select) This selects an option from the list, sends the query SMS to the middleware and then exits the application. ps ন (Exit) This action closes the application and returns to the mobile OS.

38 Section 2 Client 35 প বর বতর (Back) This action takes the user back to the previous screen i.e. the Crops Screen. The actual layout of the Secondary Services screen is shown in the screenshot in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says নmবতর ত লক থ ক প র ষব চয়ন ক ন (Select a service from the menu below). Below the information panel lie the buttons or options kয়ম লয (Cost Price), বkয়ম লয (Sale Price), লভয ত (Availability), uপ দশ (Advice). Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select), প বর বতর (Back) and ps ন (Exit). Figure 2.13: Screenshot of the Secondary Services screen when kয়ম লয (Cost Price) is selected

39 Section 2 Client Disease Symptoms Screen The Symptoms screen is encountered by the user after selecting র গ (disease) from the Home Screen and then selecting a crop from the Crops Screen. The screen displays a list of symptoms from which the user chooses the one his crop is inflicted with. Table 2.7 shows a list of some probable symptoms along with the string which is appended to the SMS query if the user selects the symptoms. Symptom Name What It Means String appended to SMS প ক Pests and insects affecting plantation. symptom1 পচন Parts of the plants are rotting. symptom2 প ত য় ছ প There are spots on leaves. symptom3 ব dর aভ ব Growth of plants is stunted. symptom4 aক লম ত য Plants are dying prematurely. symptom5 Table 2.7: List of Symptoms in the Symptoms screen menu, their meanings and the Strings appended to the SMS query by selecting each of the symptoms The three soft key actions provided by the Symptoms screen are: চয়ন (Select) This selects an option from the list, sends the query SMS to the middleware and then exits the application. ps ন (Exit) This action closes the application and returns to the mobile OS.

40 Section 2 Client 37 প বর বতর (Back) This action takes the user back to the previous screen i.e. the Crops Screen. The actual layout of the Symptoms screen is shown in the screenshot in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says নmবতর ত লক থ ক র গর লkণ চয়ন ক ন (Select a symptom from the menu below). Below the information panel lie the buttons or options the list of symptoms. Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select), প বর বতর (Back) and ps ন (Exit). Figure 2.14: Screenshot of the Symptoms screen when পচন (rotting) is selected

41 Section 2 Client Weather Screen The Weather screen is encountered by the user after selecting (weather) from the Home Screen. The screen displays a list of durations from which the user chooses the one he wants to know the weather forecast for. Table 2.8 shows the durations along with the string which is appended to the SMS query if the user selects the services. Duration String appended to SMS 24 ঘ (24 hours) day1 48 ঘ (48 hours) day2 72 ঘ (72 hours) day3 96 ঘ (96 hours) day4 eক সp হ (one week) day7 Table 2.8: List of durations in the Weather Screen menu and the Strings appended to the SMS query by selecting each of the services The three soft key actions provided by the Weather Screen are: চয়ন (Select) This selects an option from the list, sends the query SMS to the middleware and then exits the application. ps ন (Exit) This action closes the application and returns to the mobile OS.

42 Section 2 Client 39 প বর বতর (Back) This action takes the user back to the previous screen i.e. the Home Screen. The actual layout of the Weather Screen is shown in the screenshot in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says আবহ oয় র প বর ভ স দনkণ চয়ন ক ন (Weather forecast Select a duration from the menu below). Below the information panel lie the buttons or options 24 ঘ (24 hours), 48 ঘ (48 hours), 72 ঘ (72 hours), and eক সp হ (one week). Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select), প বর বতর (Back) and ps ন (Exit). Figure 2.15: Screenshot of the Weather Screen when 48 ঘ (48 hours) is selected

43 Section 2 Client Soils Screen The Soils Screen is the encountered by the user after selecting ম ট (soil) from the Home Screen. The screen displays a list of soils from which the user chooses the one he wants information about. Table 2.9 shows the common types of soils along with the string which is appended to the SMS query if the user selects the services. It can be noted that more types of soils can be easily added to the list by a little alteration. Service Name String appended to SMS eল ক ভ tক (Area wise) default ব ল (Sandy Soil) soil1 e টল (Lateritic Soil) soil2 ক দ (Clay Soil) soil3 ল ভ (Lava Soil) soil4 ল ল (Red Soil) soil5 দ -আ শ (Alluvial) soil6 লবণ k / ন ন (Saline Soil) soil7 ক ল / ক (Black Soil) soil8 Table 2.9: List of Soils in the Soils Screen menu, their functions and the Strings appended to the SMS query by selecting each of the services

44 Section 2 Client 41 The three soft key actions provided by the Soils Screen are: চয়ন (Select) This selects an option from the list, sends the query SMS to the middleware and then exits the application. ps ন (Exit) This action closes the application and returns to the mobile OS. প বর বতর (Back) This action takes the user back to the previous screen i.e. the Home Screen. The actual layout of the home screen is shown in the screenshots in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says নmবতর ত লক থ ক ম ট চয়ন ক ন (Select a soil from the menu below). Below the information panel lie the buttons or options the list of soils. Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select), প বর বতর (Back) and ps ন (Exit). (a) (b) Figure 2.16: Screenshots of the Soils Screen when (a) ব ল (sandy soil) and (b) ল ল (red soil) is selected

45 Section 2 Client Fertilizers/Insecticides Screen The Fertilizers/Insecticides Screen is encountered by the user after selecting স র/ক টন শক (Fertilizer/Insecticide) from the Home Screen. The screen displays a list of Fertilizers/Insecticides from which the user chooses the one he wants information like market price, availability etc. Table 2.10 shows the names of some Fertilizers/Insecticides along with the string which is appended to the SMS query if the user selects the fertilizers/insecticides. Service Name String appended to SMS iu রয় (urea) fertilizer1 স প র ফস ফট (super phosphate) fertilizer2 জব স র (organic fertilizer) fertilizer3 হ ড়র ড় (bone dust) fertilizer4 ন i ট (nitrate) fertilizer5 গ বর স র (cow dung) fertilizer6 ড. ড. ট. (D. D. T.) fertilizer7 Table 2.10: List of Fertilizers and Insecticides in the home screen menu, their functions and the Strings appended to the SMS query by selecting each of the fertilizers and insecticides The two soft key actions provided by the home screen are: চয়ন (Select) This selects an option from the list, sends the query SMS to the middleware and then exits the application. ps ন (Exit) This action closes the application and returns to the mobile OS.

46 Section 2 Client 43 প বর বতর (Back) This action takes the user back to the previous screen i.e. the Home Screen. The actual layout of the home screen is shown in the screenshot in Figure At the top is the i-ক ষ ( e-krishi ) header. Below the header is the information panel that says নmবতর ত লক থ ক স র চয়ন ক ন (Select a fertilizer from the menu below). Below the information panel lie the buttons or options the list of Fertilizers and Insecticides. Below the buttons and at the bottom of the screen lies the footer that shows two soft key actions চয়ন (Select), প বর বতর (Back) and ps ন (Exit). Figure 2.17: Screenshot of the Fertilizers/Insecticides screen when জব স র (organic fertilizer) is selected

47 Section 2 Client Format of the SMS As we have discussed earlier the final request of the farmer is sent as an SMS to the middleware from the client mobile device. The farmer has no knowledge of this SMS being generated; the process is completely transparent to him. As the farmer proceeds through the menu-based screens one after another selecting options from lists, special control words are appended to the SMS to form the final service request SMS. The general format of the SMS is as follows: <token 1>.<token 2>.<token 3>.<token 4> Here tokens are keywords that helps the middleware to determine what service is being requested; the keywords are separated by the delimiter.. In general, token 1 is the name of the service requested. The last token is the name of the local language in which the application has been developed; this provides the middleware the name of the local language in which the translated reply has to be transmitted back. The tokens in between depends on the type of service. So the format of the SMS can now be specified as: <service-name>.<token 2>.<token 3>.<local-language-name> Possible service names are as follows: crop disease soil weather fertilizer Hence the token <service-name> takes any one of the above 5 values depending on the choice of the user. The token <local-language-name> takes values like bengali, hindi, marathi etc. depending upon the language using which the GUI has been developed. Token 2 can have several values depending on the <service-name> token. Token 3 also depends on the <service-name> token; it can take some values or may remain blank; blank token 3 can be denoted as a null token.

48 Section 2 Client 45 Table 2.11 shows the possible values of token 2 and token 3 with respect to the service names. Also sample SMS s depending on the service names are shown in Table Service Name crop crop id Token 2 Token 3 Sample SMS Secondary service name crop.crop1.costprice eg.: crop1 crop2 etc. eg.: costprice, saleprice, availability advice disease crop id symptom id disease.crop1.symptom1 eg.: crop1 crop2 etc. eg.: symptom1 symptom2 etc. soil soil id null soil.soil1 eg.: soil1 soil2 etc. weather duration id null weather.day1 eg.: day1 day2 day3 etc. fertilizer fertilizer id null fertilizer.fertilizer1 eg.: fertilizer1 fertilizer2 etc. Table 2.11: Possible values of token 2 and token 3 w. r. t. service names

49 Section 2 Client GUI Design Principles Here one thing which must be kept in mind the options (both name of crops and service types) may be changed very easily (change in near about 10 lines of code) and should be decided only after thorough discussion with the providers of the Agricultural database that resides in the back-end server. Even the number of screens is not fixed and can be changed easily Adding more options in a screen The broad design principle of simulating the buttons using two pictures for each button has already been described in previous sections. Now we look at the implementation details in the code. There are arrays for each of the menu items which hold their names. Now images are loaded in a for loop by using the createimage function. Images depicting buttons in ON state are named name of the menu item in the array concatenated with _on and off pictures are named name of the menu item in the array concatenated with _off. So if anyone wants to add a new crop say crop27 in the GUI, he/she has to do 3 things: 1) Add two png image files crop27_on and crop27_off in res folder of package e- Krishi. 2) Add string crop27 in array NAME_OF_CROP[]. 3) Increase the variable NUM_OF_CROPS by one. In the same way, other entities like soils, services, fertilizers/insecticides, and weather durations can be added with just a little modification Handling of events Now comes the second part how events are handled. The class FontCanvas listens to the event of pressing the two action buttons left and right, the center game key button and the up and down arrows. When these events occur, the repaint method of FontTestlet is called after modifying the variables which remember the current screen and current selected item. When the center game button is pressed from the last screen, a new thread is started to send the SMS string.

50 Section 3 Middleware 47 SECTION 3 MIDDLEWARE A Detailed Description of the Middleware

51 Section 3 Middleware 48 Middleware 3.1 Introduction Middleware is software enterprise application integration. In simpler terms, it is a piece of software that connects the software components of an application. The software consists of a set of services that allow multiple processes running or one or more machines to interact across a network. This technology provides for interoperability which forms the basis of coherent distributed architectures, which are used most often to support and simplify complex, distributed applications. Middleware is similar to the middle layer of a three-tier single system architecture, except that it is stretched across multiple systems or applications. Our application is a context-aware one which leverages on a reflective middleware. Reflective Middleware is a term that describes the application of reflection to the engineering of middleware systems in order to achieve openness, configurability and re-configurability. Reflection is the capability of a system to reason about and act upon itself. A reflective system contains a representation of its own behaviour, amenable to examination and change, and which is causally connected to the behaviour it describes."causally-connected" means that changes made to the system's self-representation are immediately reflected in its actual state and behavior, and vice-versa. The use of reflective middleware serves three distinct purposes: 1) The reflective middleware, being aware of the context of application, can decide upon the appropriate actions itself, thus incorporating dynamism and flexibility. 2) The use of a reflective middleware takes much load off the client module,thus enabling the use of a thin client (i.e. the client contains only the interface and need not take care of the application logic.) 3) In a similar manner, the middleware also allows the server to store no more than the minimum amount of data required to provide the services, thus relieving the server of the task of handling the application context.

52 Section 3 Middleware 49 In short, the reflective middleware segregates the application context module from both the client and the server. This enables us to provide the server and the client with minimum requisites whereas the entire application logic is taken care of in the middleware. 3.2 Overview The middleware acts as an interface between the client and the server. Its role in the application is twofold:- 1) Message parsing and query generation:- The SMS generated by the user is received via a GSM modem. The received SMS is parsed to check whether it is in a valid format. If not, then an error message is sent to the client. If the format of the message is valid, then it is passed to the query generation module which converts the message into a proper SQL query. Thereafter this query is forwarded to the server in order to retrieve a reply. 2) Generation of reply which is to be sent to the client:- This is the most crucial stage of the application because it manifests the contextawareness of the system. This stage is responsible for converting the resultset obtained from the server into an elaborate, comprehensive reply easily understandable by the user. More importantly, the reply is translated into the user s preferred language (user s preference is noted from the incoming SMS) and sent to the user in Unicode format. The reply generation involves two phases:- I. Construction of comprehensive reply in English language:- The result returned by the server is (often) too abbreviated to be comprehensive to the user. This necessitates the generation of a comprehensive reply from the Resultset retrieved from the server. The reply is constructed in English and is complete in itself. This reply can be sent to

53 Section 3 Middleware 50 the user, or can be passed to the translation module which translates it into the user s preferred language as explained below. II. The reply generated in English is passed to the translation module which performs the translation into the language of preference. The translation is done in 2 phases: a) The first phase rephrases the English sentence so that the arrangement of the parts of speech is in accordance with the chosen language. This module is specific to the language into which the translation is to be done. b) The next phase is a simple lookup procedure which converts the words of the rephrased sentence verbatim. The English words along with the translated words are stored in a language database. The resultant string is in Unicode format and this is the reply which is to be forwarded to the user. 3.3 Block diagram Figure 3.1: Block diagram of middleware showing the subcomponents

54 Section 3 Middleware Subcomponents of middleware Figure 3.2: Subcomponents of Middleware

55 Section 3 Middleware Receipt of SMS Receipt of the SMS is done with a GSM modem. A set of Java API s are used Communication API and Java SMS API to accomplish this task of reading the SMS. Some important components of the API are as follows:- SerialPort: Defines an RS-232 serial communications port describes the low-level interface to a serial communications port made available by the underlying system. SerialPortEvent: Indicates a Serial Port event such as reading from the port or writing to the port. SerialPortEventListener: Propagates Serial Port events. CommDriver (Interface): It is a loadable device driver interface. Application programs never use it directly. CommPort: Abstracts a communication Port. CommPortIdentifier: It is the central class for controlling access to communications ports and managing them. It includes methods for: Determining the communications ports made available by the driver. Opening communications ports for I/O operations. Determining port ownership. Resolving port ownership contention. Managing events that indicate changes inport ownership status. An application first uses methods in CommPortIdentifier to negotiate with the driver to discover which communication ports are available and then select a port for opening. It then uses methods in other classes like CommPort, and SerialPort to communicate through the port.

56 Section 3 Middleware JAVA SMS API The Java SMS API is a third party API, provided by Java-Systems ( The API has two main functional Classes: ComputeSmsData: This class provides methods for link level handling of SMS data, for example: determining coding scheme of data, coding of data, setting time stamp, SMSC number and various other framing attributes. This is the class that directly interacts with a SerialPort or CommPort object and is responsible for sending and receiving data through the ports. SerialToGsm: Provides application level methods for exchange of data between GSM modem and Program. Uses the methods implemented by ComputeSmsData to accomplish this. Naïve users will just call methods from this class to get their job done thus, this class is responsible for making the lower level intricacies transparent to the user. The actual data transfer takes place as follows:- When a user sends an SMS, he sends it to the SIM card resident in the GSM Modem; the modem is connected to the middleware server through the RS-232 serial interface. The server hosts an application, which reads the SMSs from the SIM memory one-byone, passes the message content to the Parser application (described above) for verification, and deletes the message from SIM memory. The APIs we have used provide a very simple methodology to read the SMS from the SIM. They facilitate the various methods provided by Java s input/output classesclasses contained in the java.io package.

57 Section 3 Middleware 54 The SMS reading program is initialized to the Communication Port 1 or COM1 port, which it listens to. This is the port where the GSM Modem is connected to the Server. This port is then represented as a SerialPort object- defined in the javax.comm package of the communication API- to facilitate information exchange between the Modem and the Server. The effect of this abstraction is that all data to be transferred to the Serial Port can now be sent to the newly created object. In other words, the object works as an alias for the port. Then, an inputstream and an outputstream are created for the object to receive and send data from/to the modem. These two streams are used afterwards to exchange AT commands between the modem and the port. AT Commands are written to the port using the write method of the outputstream object. In case of a received SMS, the API decodes the PDU and extracts the encoded message body. Thereafter, the 7-bit representation of 8-bit data is decoded to yield the ASCII codes corresponding to the message body. Thus, the message is obtained for further processing. For sending an SMS through the GSM modem, the API first encodes the message, provided in form of a Java String, and then writes the message along with necessary AT command in the outputstream of the serial port.

58 Section 3 Middleware Description of the classes used The various classes constituting the middleware are as follows:- 1) ComputeSmsData This class provides methods to calculate the metadata of the SMS to be sent and used by the driver of the GSM modem. It is a part of Java SMS API. Some important methods are:- a) txttosmspdu encodes text message in 7 bit GSM standard b) setasciitxt calls txttosmspdu to encode the message c) encodetelnum Encode destination telephone number in standard GSM format. d) computercvdpdu decodes received pdu message e) getrcvdsendernumber to obtain the sender number 2) GsmTest This class runs the infinite loop which performs the following operations: a) poll the GSM modem for new SMS b) if SMS found: get SMS info uses smsparser object to check if SMS format is right (this eliminates other SMS s) send the query to the server. receive the reply from the server. parse & convert the English answer to local language specified. send the local language SMS to user.

59 Section 3 Middleware 56 The SMS information is obtained by obtaining a reference to a driver object. After successful parsing of the SMS, it generates the query using an SQLRetiever object. Sends the query to the server using a networkinterface object. Converts the retrieved resultset to a comprehensible English reply using a ReplyGenerator object. Uses a parser object to convert the English reply to regional language. Send the final reply to the user using a driver object. 3) Driver This is a part of Java SMS API. This class is the driver of the GSM modem. It provides methods to initialize the modem, check for new SMS, deletes the SMS after it has been read. Deletion is required because the SMS is read from the topmost SMS stack. Changing the metadata field of the SMS enables us to send messages in local language. Some of the important methods are:- a) sendandrcv resets the modem and cleans serial ports input buffer b) sendsms sends the message to the destination number by obtaining using a ComputeSmsData object. 4) SMSParser This class provides methods to parse a given string of the format <string1>.<string2>.<string3>.<string4> where string1 stands for service request string2 stands for crop_id string3 stands for the secondary_service or option string4 stands for language

60 Section 3 Middleware 57 If the string is not in a valid format a parsing error is generated. Important methods are:- a) parse tokenizes the SMS string to obtain the service request, crop_id, secondary_service (or option) and the language preference of the user. b) getcropname returns the extracted crop_id c) getspecifier returns the requested service d) getoptions returns the options specified by user e) getlang returns the specified language 5) SQLRetriever This class generates the sql query from the received SMS so that the query can be forwarded to the server. The important methods are:- SQLquerygenerator (<string>) tokenizes the message, identifies the request and options, and then constructs a query accordingly. 6) NetInterface This class is used to send the query to the server and receive the resultset. It connects to the server, forwards the query and receives the resultset. The query is sent as a part of the URL which specifies the servlet responsible for interacting with the middleware.

61 Section 3 Middleware 58 An important method is:- connect it is an important method of this class which is responsible for connecting to the server, forwarding the query and receiving the resultset. 7) ReplyGenerator This class constructs the English reply from the query result. The format of the reply depends on the resultset. If the reply is related to the weather, then the weather database in the middleware is used to retrieve elaborate weather forecasts corresponding to the field values in the resultset. The generatereply method uses a rigorous switch-case to convert the resultset to an English reply. 8) Parser This class converts the English reply (from ReplyGenerator) to a string in the regional language (Bengali in this case). Two important methods are:- a) retbengstring it rephrases the English string to match the grammar of regional language. b) parse tokenizes the string and converts the English words to Bengali words verbatim.

62 Section 3 Middleware Weather database One particular case of reply generation arises when we encounter results pertaining to weather. The weather service provides weather forecasts (for a given number of days) to the client. The forecasts generally comprise of simple phrases such as cloudy, light rain, drizzle, thunderstorm etc. There might be more than one case e.g.:- cloudy with light rain. For convenience of database updating in the server, these forecasts are represented by integer keys in the server database. These keys are appended to the resultset sent from the server. The reply generation module refers to the weather database in the middleware to transform these keys to appropriate strings. The structure of the weather database is as follows:- Phrase (varchar) Code (int) Table 3.1: Structure of the weather database A sample instance of the weather database is as follows:- Phrase Code sunny 01 cloudy 02 light rain 03 heavy rain 04 foggy 05 snowfall 11 hail 12 thunderstorm 13 Table 3.2: Sample instance of the weather database

63 Section 3 Middleware Message Parsing One of the most important roles of middleware in this application is the parsing of the message received from the user.the objective of parsing is to detect messages which are in invalid format,rendering them impossible for subsequent query procesing Parsing of incoming message One of the crucial components of the middleware is the parsing of incoming message. This serves two purposes:- 1) Validation of format:- For proper functioning of the application it is necessary that the message format is correct. Otherwise the queries will not be correctly constructed which will lead to runtime exceptions. Hence at the very beginning the message format needs to be checked. If the format is correct, then the message is accepted for further processing. Otherwise an invalid message format notification is sent to the user, and message is discarded. 2) Tokenizing message string:- The SMS string needs to be tokenized to extract the choices (of options, services, local language etc.) of the user. This is done by processing the string to obtain the option names Description of the SMS string The SMS string sent by the user consists of no more than 4 tokens separated by. (delimiter). The number of tokens may be less but should be at least 2 (depending on the nature of service solicited by user).

64 Section 3 Middleware 61 The structure of the message is as follows:- (please refer to the description of user GUI for further details) Figure 3.3: Format of the SMS string showing tokens

65 Section 3 Middleware Method of parsing Parsing is done by an smsparser object. We assume that the local language is Bengali; so the 4 th token is implicit and not considered to be part of the SMS). If the length of message (length of message is the number of tokens in the message) is 2 then the service has to be fertilizer or soil or weather and if the length is 3 then the service has to be disease or crops. Procedure:- initalize specifier,option, crop_id,lang to empty string initialize format to valid if no. of tokens >3 or <2 format= invalid else specifier=token1 if the 1 st token is not a service format= invalid else if length=2 if (specifier = weather or soil or fertilizer) option=token2 else format =invalid end if else if length=3 if(specifier = crops or disease) crop_id=token2 option=token3 else format=invalid end if end if end if return format

66 Section 3 Middleware Examples Example 1:- incoming message:- disease.crop1.sym1 (lang=beng is implicit) length=3 hence length is within valid range. First token is disease which is a service. Again the length is 3 and the first token is disesase, so the structure of message tallies with the length. Hence we set crop_id=crop1 and option=sym1. We conclude that the message is valid. Example 2:- incoming message:- soil.soil2 length=2 hence length is within valid range. First token is soil which is a service. Again the length is 2 and the first token is soil, so the structure of message tallies with the length. Hence we set option=soil2. We conclude that the message is valid. Example 3:- incoming message:- disease.crop3 length=2 hence length is within valid range. First token is disease which is a service. But, the length is 2 and the first token is disease, so the structure of message does not tally with the length. We conclude that the message is invalid

67 Section 3 Middleware Query generation Generating the SQL Query After validation of the incoming message the next task is to generate the query from it. The query construction is handled by the method SQLquerygenerator (<string>) of the class SQLRetriever. The query generation module needs to know the name of the tables in the server database so that the query can be correctly directed.therefore, a list of the table names corresponding to the service names is placed at the beginning of the query generation module. The following cases need be handled:- Case 1:- The message does not contain request for weather forecast.then, only the type of service is determined so that the proper table name can be used in the query. Case 2:- The message contains request for weather forecast. In this case, the following actions are taken:- 1) The options token is evaluated to ascertain the number of days for which forecast is required. 2) Depending on the number of days, the appropriate range of dates is inserted in the query. For convenience, the database tables have the same name as the name of services. The names of services (as well as the tables ) are:- disease weather crops soil fertilizer The query generation process parses the message to obtain the service name, which is the first token. This service name determines the table name to be inserted in the query. Depending on the service, the module also determines the options(soil_id/fertilizer_id/symptom_id/price,availability/advice/days) and/or crop_id which are to be inserted into the query.

68 Section 3 Middleware Examples We now use some examples to illustrate how the query is generated from an SMS string in a valid format. Example l :- Let the SMS be disease.crop1.sym1 This message is in a valid format and hence accepted by the smsparser. It is forwarded to the query generation module. In the query generation module,the message is parsed to obtain the first token,which is the service(disease in this case). Hence the name of the table in the query is disease. Then the options and crop_id are extracted from the message,and they are used to construct the query. The query is:- select remedy from disease where crop_id=crop1 and symptom_id=sym1 Example 2:- Incoming message: weather.day2 Message format is valid and so it is eligible for query generation. The service name is weather which is also the name of the table. The date needs to be inserted into the query. The generated query is :- select forecast from weather where idate between curdate() and date_add(curdate(),interval 2 day) Example 3:- Incoming message: crops.crop2.availability Message format is valid and so it is eligible for query generation. The service name is crops which is also the name of the table. query: select availability from crops where crop_id=crop2

69 Section 3 Middleware 66 Example 4:- Incoming message:- soil.soil1 Message format is valid and so it is eligible for query generation. The service name is soil which is also the name of the table. query: select soil_type from soil where soil_id=soil1 Example 5:- Incoming message:- fertilizer.fertilizer1 Message format is valid and so it is eligible for query generation. The service name is fertilizer which is also the name of the table. query: select price,availability from fertilizer where fertilizer_id=fertilizer1 Note: The query generation module does not consider the possibility that the crop_id, fertilizer_id, symptom_id etc. can go beyond the range of data actually stored in the server tables. eg.:- The query generation module will not generate any warning for the message disease.crop60.sym65 although no entry exists for crop60 or sym65 in the server databse. This query,when sent to the database will result in an exception which will be converted to a failure message to be sent to the user Flexible design The check (to ascertain if the ids are within range) has deliberately been avoided in middleware to facilitate the flexibility on the server side. More entries corresponding to new crops, soils and fertilizers may be added to the server database without having to recompile the query generation module.

70 Section 3 Middleware Sending the query to the server and receiving the result After the query is constructed by the query generation module,it is sent to the server. A NetInterface object is used to send the query to the server and receive the resultset. It connects to the server, forwards the query and receives the resultset. The query is sent as a part of the URL which specifies the servlet responsible for interacting with the middleware. More specifically the connect (<String>) method of this class is used to initiate a connection to the server for query purposes. The string argument denotes the query to be sent to server. To simplify, we have used a hard-coded URL to connect to the server. The url is: FarmerServlet is the servlet with which we intend to connect. As we can see the query is appended to the end of the URL. This is an example of a GET request where the parameters are passed as a part of the URL rather than the body of the request. If there is an error connecting to the server, then an exception is reported; and we have to try to reconnect. Figure 3.4: The stages of processing in the middleware

71 Section 3 Middleware Generation of reply from the retrieved resultset After the NetInterface object receives the resultset, the resultset is to be converted into a comprehensible English reply---this reply can be directly returned to the user, or may be sent to the translation module to generate a reply in the user s local language. The construction of reply from the resultset is handled by a ReplyGenerator object. The generatereply() method of the ReplyGenerator class is responsible for construction of the reply. This method is passed four arguments:- 1) resultset retrieved from server 2) service 3) crop name 4) option As discussed earlier, we have already obtained the service name, crop name and the option while parsing the incoming message from the user. Depending on the name of the service, appropriate words are inserted into the reply so that a comprehensible English sentence is formed. In case of a resultset pertaining to weather, the reply generation module refers to the weather database in the middleware to transform keys (denoting forecasts) to appropriate strings. The forecast pertaining to each day are added to the reply separately.

72 Section 3 Middleware Algorithm for reply generation procedure generatereply (query-result, service, crop-name, option) { string reply; if service = crops if option = availability if query-result = 1 reply = available else reply = not available end if else if option = costprice reply = cost-price is + query-result else if option = sale-price reply = sale-price is + query-result else if option = advice reply = query-result end if else if service = disease or soil reply = query-result else if service = fertilizer if query-result.part1 = 0 reply = not available else reply = available, price is + query-result.part0 end if else if service = weather split query-result into tokens each of which represent one day s forecast for each day i reply = \n + day i : for each forecast j in day i reply = reply + < string corresponding to forecast j > +, end for end if end for return reply }

73 Section 3 Middleware Examples Let us elaborate with some examples. Example 1:- query-result = Rs. 12/kg service = crops crop-name = crop1 option = sale-price The reply generated is :- cost-price is Rs. 12/kg Example 2:- query-result = prune affected parts service = crops crop-name = crop1 option = sale-price The reply generated is :- prune affected parts Example 3:- query-result = cloudy with light rain $ heavy rain service = weather option = day 2 The generated reply is:- day 1: cloudy with light rain day 2: heavy rain

74 Section 3 Middleware Translation Conversion of English reply to reply in local language The key characteristic of the middleware for this application is that it is contextaware. The context here refers to the location of the user accessing the service. It is to be kept in mind that our application aims at providing location specific agricultural information to mobile clients. Therefore, it can be assumed that a significant portion of the users would belong to the farmer community. The application will be useful to them only if they benefit from the information provided by the service. For the convenience of the users, we have constructed the middleware in such a manner that it returns the reply in the user s local language. The local language can either be the most common language of the user s locality or the mother-tongue of the user. This local language is specified in the message string which arrives from the user. As discussed in the GUI part, this (the local-language) specification depends on the user interface module provided to the user when he registers for the service. In our case, we have implemented the modules necessary for translation of the reply into Bengali. As we will shortly see, translation to any other language can be done by implementing only the modules necessary to rephrase the English query to match the grammar of that particular language. Conversion of the English reply to the local-language reply takes place in 2 stages:- 1. Rephrasing:- This stage rephrases the English reply to match the grammar of the regional language. This module identifies the parts of parts of speech in the English sentence and rearranges the words according to an algorithm specifically designed for the local language. 2. Word-by-word translation:- After having rephrased the English sentence, we simply convert each word into the corresponding word(s) in the target language. This mapping is done by consulting a

75 Section 3 Middleware 72 database (named Language). This database contains a table named LANGUAGE_CONVERSION which stores the English string and the local language string for a particular language. This single table can handle multiple languages because <English-string>,<local-language-string>,<local-language> are stored as a tuple. The local-language word is stored in the Unicode format. The locallanguage word is retrieved by specifying the English string and the target language. After the translation of all the words in the sentence is done, the resultant string is a local-language reply comprehensible to the user Rephrasing of English sentence To rephrase the English sentence, we need to identify its structure by looking at the different parts of speech present in it. Once we have done so, we rearrange the words so that the structure of the modified sentence matches the Bengali grammar. It is to be noted here that an extensive translation is unnecessary because the sentences in our application are simple, short and can be classified into no more than 10 categories based on their structure. Therefore, we consider reduced grammars both for English (the source language) and Bengali (the target language) English grammar The English grammar (more precisely, the grammar governing the structure of English sentences relevant to our application) is as follows:- Compound_sentence Simple_sentence punctuation Simple_sentence Simple_sentence Simple_sentence Noun-phrase Verb-phrase Noun-phrase Noun-phrase Verb-phrase Verb-phrase Noun-phrase Simple_sentence Adverb-phrase Noun-phrase noun adjective noun pronoun adjective pronoun noun connective noun Verb-phrase pronoun connective verb verb Adverb-phrase adverb number adverb Connectives denote words such as of, for, at, in etc.

76 Section 3 Middleware 73 Example Eg:- Let us consider the sentence: apply fertilizer regularly apply is a verb fertilizer is a noun regularly is an adverb Parse tree is as follows:- Figure 3.5: Parse tree for the English sentence apply fertilizer regularly according to English grammar After having parsed the English sentence, we now rephrase it to match the grammar of the Bengali language.

77 Section 3 Middleware Bengali grammar A simplified grammar of the Bengali language is as follows:- Simple-sentence Noun-phrase Verb-phrase Adverb-phrase Simple-sentence Verb-phrase Verb-phrase Noun-phrase Modifier adjective noun Modifier noun Modifier pronoun article noun article pronoun Verb-phrase verb pronoun connective verb pronoun connective noun connective verb Adverb-phrase adverb num adverb Modifier noun connective pronoun connective Example Let us consider the Bengali equivalent of the sentence apply fertilizer regularly. The Bengali equivalent is niyomito shaar proyog korun (regularly fertilizer apply) As before, apply is a verb fertilizer is a noun regularly is an adverb The parse tree is as follows:- Figure 3.6: Parse tree for the sentence regularly fertilizer apply according to Bengali grammar

78 Section 3 Middleware 75 Evidently, once we have rephrased the English sentence to the above form, we can perform word-by-word mapping of the English words to equivalent Bengali words. Thus we have a grammatically correct Bengali sentence Actual Translation Procedure Now we briefly discuss the algorithm to rephrase the English sentence. As evident from the grammars discussed above, the key difference between English and Bengali simple sentences is the relative positions of noun-phrase and verb-phrase. In most of the cases English sentences of the form <verb-phrase><noun-phrase> need to be rephrased to Bengali sentences of the form <noun-phrase><verb-phrase>. Position of adverb-phrase (if any) also needs to be changed. The rephrasing is handled by the retbengstring(<string>) method of the Parser class. The argument to the method is the string which needs to be rephrased. First, the string is tokenized to obtain each word and their parts of speech is identified with the help of the findcategory(<string>) method of dictionary class. Then the rearrangement of tokens is done using the following algorithm. procedure retbengstring(string sentence) for each noun-phrase in the sentence if noun-phrase begins with the send the to the position just after the noun in the noun-phrase end if end for if noun-phrase contains of ( or in or at ) move of ( or in or at ) to the end of its subject //eg:- of dry leaf dry leaf of end if if a verb-phrase precedes a noun-phrase send verb-phrase to the end of that noun-phrase disregard words such as is, are which are redundant in Bengali end if if an adverb-phrase occurs in the sentence bring the adverb-phrase to the beginning end if end procedure

79 Section 3 Middleware 76 After rephrasing is complete, the parse (<string>) method is called to convert the words in the rephrased sentence to corresponding Bengali words. The parse(), in turn, calls the translate(<string>) method of the dictionary class. Two cases may arise:- 1) token is non-numeric:- Then translation can be done as-is 2) token is numeric:- translation of each digit of the token is to be done separately. The second case arises in case of translation of numerical values such as cost-price, sale-price etc. We translate such token digit by digit. As stated earlier, this mapping is done by consulting the LANGUAGE_CONVERSION table of the Language database. Figure 3.7: Diagrammatic schematic of the Translation module showing the methods, dictionary and the language database

80 Section 3 Middleware 77 In table LANGUAGE_CONVERSION, EnglishString is the word(s) to be translated. LocalLangString specifies the target language (beng in our case). LocalLanguage is the local-language equivalent of the string to be translated. Category is defined as follows: Adjectives Articles Nouns Pronouns Verbs Connectives Punctuation Adverb Digits Examples Let us elaborate with some examples:- Example 1:- English sentence :- prune affected parts Rephrased English sentence: affected parts prune Bengali sentence :- স k মত a শ ক ট ন (shongkramito ongsho katun) Example 2:- English sentence:- cost-price is Rs. 12/kg Rephrased English sentence: cost-price Rs.12/kg Bengali sentence:- কন দ ম 12 ট ক / ক ল (kena daam 12 taka/kg)

81 Section 3 Middleware Location specific service Our application aims at providing location-specific services to mobile clients. Services such as prices and availability of crops, remedy for crop diseases, nature of soil, weather forecasts etc. are pertinent to the geographical location of the user. Every table in the server database has a column for area_code which signifies geographical regions. Each area code is mapped to a distinct geographical region so that user can access location-specific information. Hence it is necessary for the middleware (and also the server) to know where the user is situated geographically. This can be done in the following ways:- 1) GPS (global positioning system):- If the user mobile is GPS enabled, then the exact geographical position can be obtained by triangulation with satellites. However, it has its drawbacks:- i) GPS enabled mobiles are expensive. As the majority of our clientele comprises of farmers, it will be too optimistic to assume that all of them possess such devices. ii) GPS triangulation yields the exact location (latitude and longitude) of the device. This location needs to be mapped to a larger region, which requires further processing in the middleware. 2) Information from service providers:- The location of the user can be obtained from the corresponding (GSM or CDMA) service provider. However, this process is too cumbersome, expensive and will need the consent of the service provider to share the necessary information.

82 Section 3 Middleware 79 3) Registration:- A feasible alternative to the previous two approaches is to obtain the geographical location by the method of registration. In this approach, if an user wants to avail of the services, he needs to register himself to authorized sevice-offices by specifying his mobile number and the location from which he wants to access the service. His mobile number is entered into a database along with the area-code corresponding to his chosen location. This database resides in the middleware, and is consulted every time a message from the user arrives at the middleware. The area_code corresponding to the mobile number (if the user is registered) is obtained from the database and appended to query which is to be sent to the server. However, this approach assumes that an user always accesses the services from a fixed geographical region. Note:- The implementation of mobile number area code mapping being straightforward, we have omitted this part in the present version of our application. The mapping can easily be done by performing a database-lookup in the class GsmTest,and passing the obtained area-code to the query generation module after the format of the sms is validated.

83 Section 3 Middleware Updation of the LANGUAGE database in the middleware As discussed earlier, the mapping of an english word to its local language equivalent is done by consulting the LANGUAGE database.therefore,keeping this database sufficient enough for the application is crucial. For convenience of updation of the database we have designed a GUI which enables us to store the local language words(in Unicode format) along with the corresponding english words. A screenshot of the GUI is given below. Figure 3.8: Screenshot showing the GUI of the LANGUAGE database updation module

84 Section 3 Middleware 81 As seen in the above figure, there is a field for specifying the local language (beng, in our case). After specifying the local language we input the English string in the given textfield. Then we enter the local language string corresponding to the English string which has been given as input. We also mention the category of the string in the textfield supplied for the purpose. It is to be noted here that if no other method is available then we have to enter the local language string by specifying the Unicode for each of the characters which is both tedious and error prone. Therefore we have designed another GUI which enables us to type in local language characters by using an onscreen keyboard. A screenshot of the GUI is given below. Figure 3.9: Screenshot showing the GUI which empowers the database updater to type in local language using a phonetic Bengali keyboard

85 Section 3 Middleware 82 This is a phonetic keyboard which allows us to type the characters just as we pronounce them. Corresponding to each key in the keyboard there are three characters, any one of which can be selected by : 1. Simply hitting the key(this for the default(blue) character). 2. Hitting the Shift key alongwith.(this is for the green character). 3. Hitting the Ctrl key alongwith(this is for the red character). As we keep pressing the keys the word is generated on the TextArea above the keyboard. This word is copied by selecting the option copy-to-clipboard of the Edit menu; and thereafter pasted on the local language field(i.e. WORD IN LOCAL LANG) of the GUI of the previous page. Classes: The class corresponding to the GUI of the previous page is DBaseModify. The class corresponding to the GUI of this page is TextPad.

86 SECTION 4 SERVER Details of the Agricultural Database in the Back-end Server

87 Section 4 Server 84 SERVER 4.1 Introduction The most important part of this three-tier architecture is the server.as the name rightly suggests, it serves the clients and connects to the main agricultural database, retrieves the information as per query and retransmits the information to the client(through the middleware).so, any mishap/failure in the server would cripple the entire process. 4.2 Description Before moving deeper into the intricate details of how the server actually operates, some introductory notes are provided to explain some very useful terms and tools Apache Tomcat Apache Tomcat is an implementation of the Java Servlet and JavaServer Pages technologies. The Java Servlet and JavaServer Pages specifications are developed under the Java Community Process. Apache Tomcat is developed in an open and participatory environment and released under the Apache Software License. Apache Tomcat is intended to be a collaboration of the best-of-breed developers from around the world. Apache Tomcat powers numerous large-scale, mission-critical web applications across a diverse range of industries and organizations. The version used here is tomcat This is the top-level entry point of the documentation bundle for the Apache Tomcat Servlet/ JSP container. Apache Tomcat version 5.5 implements the Servlet 2.4 and JavaServer Pages 2.0 specifications from the Java Community Process, and includes many additional features that make it a useful platform for developing and deploying web applications and web services.

88 Section 4 Server MySQL 5.0 MySQL 5.0 is a very important tool that we used to store the database which is the central point of our server. MySQL is a relational database management system (RDBMS) which is owned and sponsored by a single for-profit firm, the Swedish companymysql AB, now a subsidiary of Sun Microsystems. MySQL offers MySQL 5.0 in two different variants: the MySQL Community Server and Enterprise.ServerThey have a common code base and include the following features: A broad subset of ANSI SQL 99, as well as extensions, Cross-platform support, Stored procedures; Triggers, Cursors, Updatable Views; True VARCHAR support ; INFORMATION_SCHEMA; Strict mode; X/Open XA distributed transaction processing (DTP) support; two phase commit as part of this, using Oracle's InnoDB engine Independent storage engines (MyISAM for read speed, InnoDB for transactions and referential integrity, MySQL Archive for storing historical data in little space) Transactions with the InnoDB, BDB and Cluster storage engines; savepoints with InnoDB SSL support, Query caching, Sub-SELECTs (i.e. nested SELECTs) Replication with one master per slave, many slaves per master, no automatic support for multiple masters per slave. Full-text indexing and searching using MyISAM engine Embedded database library,partial Unicode support ACID compliance using the InnoDB, BDB and Cluster engines; Sharednothing clustering through MySQL Cluster.

89 Section 4 Server JDBC (Java Database Connectivity) Short for Java Database Connectivity, a Java Application Programming Interface (API) that enables Java programs to execute SQL statements. This allows Java programs to interact with any SQL-compliant database. Since nearly all relational database management systems (DBMSs) support SQL, and because Java itself runs on most platforms, JDBC makes it possible to write a single database application that can run on different platforms and interact with different DBMSs. JDBC is similar to ODBC, but is designed specifically for Java programs, whereas ODBC is language-independent.jdbc was developed by JavaSoft, a subsidiary of Sun Microsystems. We used JDBC to connect to the back-end database from the servlet Servlet Servlets are Java programming language objects that dynamically process requests and construct responses. The Java Servlet API allows a software developer to add dynamic content to a Web server using the Java platform. The Servlet API, contained in the Java package hierarchy javax.servlet, defines the expected interactions of a Web container and a servlet. A Web container is essentially the component of a Web server that interacts with the servlets. The Web container is responsible for managing the lifecycle of servlets, mapping a URL to a particular servlet and ensuring that the URL requester has the correct access rights. From the standpoint of the kind of work it does, a servlet closely resembles a CGI (Common Gateway Interface) script. Like a CGI script, a servlet can respond to user input -- such as the clicking of a button on a form -- and can either collect information from the user or send information back to the user (or both), depending upon what kinds of actions are initiated by the form the user fills out. If a servlet is designed to provide information to the user, it can track down the information it needs in any number of ways -- by retrieving it from a database, for example. The servlet can then dynamically construct an HTML page containing the information it has collected, and can display that page in the user's browser.

90 Section 4 Server 87 The second function above is worth noticing as that is the exact functionality that our servlet delivers. The servlet in our application i.e. FarmerServlet.java implements the servlet functionality in the HTTP method doget() i.e. we have used the HTTP method GET to send the request to the servlet,a little detail about GET request is in order : Figure 4.1: HTTP GET request The above diagram shows an outline of what it happens on client end when client clicks on a link (i.e sends a GET request). The general form of the HTTP request method GET is shown next.

91 Section 4 Server 88 Figure 4.2: Anatomy of a HTTP GET request From the middleware a parameter is set in the URL itself (as is usual with GET requests). It is called "param1" which actually carries a middleware-generated query as par the request from the client. String parameter1=request.getparameter("param1"); This line shows how using the getparameter method(using servlet properties) we retrieve the parameter value i.e. the query. The result of executing the query is sent back as an HTTP response and so the next picture shows the details about a general HTTP response.

92 Section 4 Server 89 The following diagram shows the anatomy of an HTTP Response. Figure 4.3: Anatomy of a HTTP response The next picture shows an example in which the client send a GET request to a BEER application server and the BEER login page gets downloaded into the client machine.

93 Section 4 Server 90 Figure 4.4: HTTP request and response for a sample Beer application Like this though we do not send an HTML page as a response to the middleware's request we just simply write the answer to the query in the HTTP response using println method of a PrintWriter object and send it to middleware.

94 Section 4 Server Database The main agricultural information database which stores all information to be relayed to the farmer as per request comprises this layer and this resides in a remote back-end server which communicates with the middleware through the internet. The database has to be carefully designed because it contained the essence of the whole project. From this database the server retrieves the information (that is requested by the client) which is sent to the client in SMS form via the middleware. Our database contained five tables: Crops Fertilizer Weather Soil Disease The description of the tables is given in the following table. Disease Weather Crops Crops Soil Fertlizer Attributes Type Primary Key area_code integer(10) crop_id varchar(10) symptom_id varchar(10) remedy varchar(100) area_code idate forecast area_code crop_id costprice saleprice availability weekly_advice area_code crop_id costprice saleprice availability weekly_advice area_code soil_id soil_type area_code fertilizer_id price availability integer(10) date integer(10) integer(10) varchar(10) varchar(10) varchar(10) integer(1) varchar(50) integer(10) varchar(10) varchar(10) varchar(10) integer(1) varchar(50) integer(10) varchar(10) varchar(50) integer(10) varchar(10) varchar(10) integer(1) area_code,crop_id, symptom_id area_code,idate area_code,crop_id area_code,crop_id area_code,soil_id area_code,fertilizer_id Table 4.1: Details of the tables of the Agricultural Database

95 Section 4 Server 92 as follows: Some important points to be remembered while creating this database are mentioned The response of the system to a client has to be area-specific. Thus the area-code attribute is added to all of the tables in our database. The Disease table (in general) provides the remedies based on the crop-id & the symptom-id. The Weather table stores the area-specific weather forecast of the next 1-7 days and so the table has to be updated every day. The Crops table provides the available information like costprice, saleprice and availability of a particular crop. The weekly advice column has been also appended in this table for the simplicity of the design of the whole database. Similarly, the soil table provides necessary information of different types of soils. The fertilizer table stores the price and availability of different types of fertilizers. Finally, though the database is not explicitly designed as a relational one, relations can be found based on the area-code attributes in each table or crop-id in table disease and crops. Updation: A very important part of maintaining any database is populating it while maintaining its consistency with the real world. In this application we have to be more careful about the words we enter in our database because our final goal is to send the reply to the client after translating the English sentence in "local language". The database which has the English words and their corresponding "local language" equivalent resides in the middleware. So, when the reply comes back from server to middleware in a string, it must contain the exact words which have a database entry in the middleware or else there will be an error. For example, the word "Kg." has an entry in the database in the middleware; hence we can use the word in our server database tables too. But the word "kilogram" is

96 Section 4 Server 93 not in the middleware-database. So we have two choices either do not use this word in the server database or update it in the middleware database and then use it in the server database. Another point worth mentioning would be to leave (at least)a space between 2 tokens(/words).a person does not generally makes a mistake like that while entering a sentence like "It is raining". But while entering something like "the price of rice is Rs. 12 / Kg. " it is very easy to make a mistake and write it like "Rs. 12/Kg." or "Rs.12/Kg." which obviously would invoke an error while translating (i.e. precisely while looking up the local language equivalent of a token like "12/Kg."). The reason is obvious. Using the space as a separator we would get words which do not have an entry in the middleware-database. 4.4 How it Works The part of the three-tier interactive process that takes place in the server is very simple. This simplicity makes it more manageable and as the server can be considered as the central point of the whole application - so its simplicity & manageability adds to the robustness of the architecture. Thus, what follows is a very simple but informative description of how server works. Our servlet class extends HttpServlet class and implements its doget() method. It first gets the parameters passed to it(passed by NetInterface). The SMS sent by the client is converted in a query in the middleware and GSMTest.java sends the query via the internet to this servlet which consults the database "agri" and retrieves the information. The information is stored in a string object and then returned to the middleware.

97 Section 4 Server Test Case The contents at a point of time in the database are shown next. Tables_in_agro crops disease fertilizer soil weather Table 4.2: Tables of the Agricultural Database area_code crop_id costprice saleprice availability advice 1 crop1 Rs. 12 / Kg Rs. 19 / Kg 1 Apply water regularly 1 crop2 Rs. 14/ Kg Rs. 18 / Kg 1 Apply water regularly 1 crop3 Rs. 14 / Kg Rs. 18 / Kg 1 Apply water regularly 1 crop4 Rs. 4 / Kg Rs. 8 / Kg 1 Apply water regularly 1 crop5 Rs. 12 / Kg Rs. 19 / Kg 1 Apply water regularly Table 4.3: The Crops Table

98 Section 4 Server 95 area_code crop_id symptom_id remedy 1 crop1 sym1 Apply insecticide ( DDT ) 2 times a day 1 crop1 sym2 prune affected part 1 crop1 sym3 provide sufficient sunlight 1 crop1 sym4 apply fertilizer 1 crop1 sym5 use better quality seeds 1 crop2 sym1 Apply insecticide ( DDT ) 2 times a day 1 crop2 sym2 prune affected part 1 crop2 sym3 provide sufficient sunlight 1 crop2 sym4 apply fertilizer 1 crop2 sym5 use better quality seeds 1 crop3 sym1 Apply insecticide ( DDT ) 2 times a day 1 crop3 sym2 prune affected part 1 crop3 sym3 provide sufficient sunlight 1 crop3 sym4 apply fertilizer 1 crop3 sym5 use better quality seeds 1 crop4 sym1 Apply insecticide ( DDT ) 2 times a day 1 crop4 sym2 prune affected part 1 crop4 sym3 provide sufficient sunlight 1 crop4 sym4 apply fertilizer 1 crop4 sym5 use better quality seeds 1 crop5 sym1 Apply insecticide ( DDT ) 2 times a day 1 crop5 sym2 prune affected part 1 crop5 sym3 provide sufficient sunlight 1 crop5 sym4 apply fertilizer 1 crop5 sym5 use better quality seeds Table 4.4: The Diseases Table

99 Section 4 Server 96 area_code idate forecast Table 4.5: The Weather Table area_code fertilizer_id price availability 1 fertilizer1 Rs. 25 / Kg 1 1 fertilizer2 Rs. 35 / Kg 1 1 fertilizer3 Rs. 35 / Kg 1 1 fertilizer4 Rs. 30 / Kg 1 1 fertilizer5 Rs. 25 / Kg 0 1 fertilizer6 Rs. 12 / Kg 0 1 fertilizer7 Rs. 10 / Kg 0 Table 4.6: The Fertilizers Table

100 Section 4 Server 97 area_code soil_id soil_type 1 default red soil 1 soil1 Sandy soil 1 soil2 clayey soil 1 soil3 muddy soil 1 soil4 lava soil 1 soil5 red soil 1 soil6 alluvial soil 1 soil7 saline soil 1 soil8 black soil Table 4.7: The Soils Table

101 SECTION 5 PERFORMANCE ANALYSIS An Analysis of Response Times by Real-world Experimentation

102 Section 5 Performance Analysis 99 Performance Analysis A quick response by the entire system is necessary for efficient dispensing of information to the requesting client. For this some random simulations of the entire cyclic process (client request as SMS to middleware middleware request as query to back-end server server reply as information to middleware middleware reply as SMS in local language back to mobile client) were done and the results tabulated. 5.1 Analysis Methodology For calculating the time required to execute different parts of the application, we considered the following time parameters: Calculated at middleware: t 1 = time calculated from the point of receiving the SMS at the middleware up to sending of the query to the server t 2 = time calculated from the point of sending the query to the server up to the receiving the reply from the server t 3 = total time of all operations at the middleware ie. time calculated from the point of receiving the SMS upto the end of sending of the SMS to mobile phone Calculated at server: t 4 = time calculated from the point of receiving the query up to sending of the answer back All time durations are calculated in milliseconds. The server and middleware were connected through wireless local area network. Two scenarios were considered as described next. For each scenario a set of sample response times were taken and tabulated; the values of t 1, t 2, t 3 and t 4 indicate the performance of the system as a whole.

103 Section 5 Performance Analysis Scenario 1 The first scenario is the one when everything works normally; the middleware and server are working; all links are up and all connections are active. In scenario 1 the client gets the info he/she requested normally. Table 5.1 depicts the results at normal conditions when all links are up and running (i.e. the client gets the info requested). Obs. No. t 1 t 2 t 3 t 4 (msecs) (msecs) (msecs) (msecs) Table 5.1: Response times in normal conditions

104 Section 5 Performance Analysis Scenario 2 This scenario is the one when the tests are performed with the server disconnected from the middleware i.e. the server-middleware link is dropped, in concurrence with the realworld scenario when there is network failure or server is down. In this case the query request to the server is timed out after an interval and the sender gets a reply in the tune of Error connecting to server Try again later. Table 5.2 shows the results obtained for scenario 2. Obs. No. t 1 t 2 t 3 t 4 (msecs) (msecs) (msecs) (msecs) Table 5.2: Response times with server disconnected from middleware and/or server down

105 Section 5 Performance Analysis Discussions The cardinal parameter here is t 3 which determines the total back-end processing time inside the middleware and server as viewed from the front-end mobile client. As evident from tables 1 and 2, t 3 varies from 6110 ms i.e. 6.1 s to ms i.e s. Average t 3 is under 15 seconds and this denotes the total delay inside the processing system (middleware and backend server) which is quite acceptable. Figure 5.1 shows the values of t 3 taken over 15 different observations of scenario 1 and also the average t 3 over those instances 11.2 seconds. Response Time in seconds Observation no. Response Times Average Response Time Figure 5.1: Values of t 3 and average t 3 over 15 different observations of scenario 1 The total response time as viewed from the mobile client is the time from sending of request until the receiving of the reply SMS and that includes the response time t 3 in addition to the total transmission time of the SMS through the GSM network. The latter varies largely due to conditions like network congestion, traffic, handoff delay, propagation delay etc. which are not within the control of the system.

106 SECTION 6 INSTALLATION How to set up, install, configure and use the system

107 Section 6 Installation 104 Installation and Configuration 6.1 Client/Customer Side Introduction This phase of installation is done at the client/customer side. The device for installation is the mobile device of the user who in this case is the farmer Minimum requirements A mobile handset device with: Java application support i.e. J2ME support Two action soft keys (right and left) One center game action key MIDP 1.0/2.0 CLDC 1.0/ kilobytes of user memory SMS sending/receiving capability This system has been tried successfully for the following devices: Nokia: 3110, 3210, 3230, 3600, 5130, 5220, 5230, 5310, 6270, 6300, 6600i, 7210, 7310, N70, N72, N73, N77, N79, N85, N82, N95 Sony Ericsson: C510, G502, G705, K750i, K770i, K790i, K800i, K810i, K850i, W350i, W550i, W580i, W700i, W800i, W810i, W890i, W900i HP: ipaq h6320

108 Section 6 Installation Installation Procedure Step 1: Send the application provided (e-krishi.jar) to the handset. This can be done in four ways: Transfer by Bluetooth Transfer through data cable Directly install in the device from PC/notebook using utility software like PC Suite. Download from the internet using GPRS/EDGE/3G data connection Step 2: Install the application. (a) (b) Figure 6.1: Installing e-krishi: (a) Start the installation process by selecting Yes from the installation screen, (b) installation preparation starts

109 Section 6 Installation 106 (a) (b) (d) Figure 6.2: Installing e-krishi: (a) App details are shown, proceed by selecting Continue, (b) Select a location for installing, (c) Security warning shown confirm by selecting Continue, (d) installation starts (c)

110 Section 6 Installation Configuration (a) (b) (d) (c) Figure 6.3: Configuring e-krishi: (a) Go to applications menu, (b) Select Change Number from the menu, (c) Enter the number of the SIM card installed in the GSM modem in middleware, (d) select Save from options

111 Section 6 Installation How to use For starting the service, run the e-farming application and follow the options. For example, let us consider that we want to know the remedy to rotting of coffee plant. (a) (b) Figure 6.4: Using e-krishi: (a) Go to applications menu, (b) Select e-krishi from the menu to launch the application

112 Section 6 Installation 109 (a) (b) (d) (c) Figure 6.5: Using e-krishi: (a) Select র গ (disease) from Home Screen, (b) Select ক ফ (coffee) from crops screen, (c) Select পচন (rotting) from Symptoms screen, (d) allow SMS to be sent by the application by selecting Yes

113 Section 6 Installation 110 The reply will come as a service SMS. (a) (b) Figure 6.6: Using e-krishi: (a) SMS received, (b) SMS is opened by selecting Read and the reply is seen

114 Section 6 Installation Middleware Installation Introduction This installation is to be done on a work-station. The main purpose of the middleware is to receive the SMS, parse the query, retrieve the required information from the database in the server, compile and send the reply SMS Requirements Software requirements: Sun Java SDK 1.6 Windows xp/vista /linux MySql MySql-JDBC connector Hardware requirements: GSM Modem RAM-128 MB or more Intel Motherboard Pentium 4 processor or higher (This system has been tried using J2SE 1.6 and GDM 6002D GSM Data Module.) Procedure The steps to be taken for the installation of the middleware are described as follows: I. We first start by configuring the GSM modem. A valid SIM is inserted in the correct slot in the GSM modem and the modem is then connected to the workstation(i.e. where the middleware resides) II. We need a JDK so that we can edit and compile the codes and also a JRE to run the java codes.thus the next step is to install JDK & JRE both of which can downloaded for free from III. Third step pf the installation procedure is to install Java Communication API.As,we have tested our application in Windows,here is a trick to install the Java Communications API correctly on a Windows system Machine. The following files

115 Section 6 Installation 112 are the core of JAVA Communiccation API, and they are very important to have them installed on the system for a proper operation: comm.jar win32com.dll javax.comm.properties For the JDK (Java Developnment Kit) to recognize the serial ports on your machine, it is important to properly place these files in the right folders on your local machine: %Java_HOME% = the location of your jdk directory. To find your JDK directory, Use the Following steps: 1. Click on Start 2. Click on Search 3. Click on For Files or Folders 4. In the Left hand Side, Click on All Files and Folders 5. Type in jdk* in the textbox under All or part of the file name: 6. Click Search 7. Look for yellow icon that looks like a folder 8. Double Click on the folder to open the jdk folder comm.jar should be placed in: %JAVA_HOME%/lib %JAVA_HOME%/jre/lib/ext win32com.dll should be placed in: %JAVA_HOME%/bin %JAVA_HOME%/jre/bin %windir%system32 javax.comm.properties should be placed in: %JAVA_HOME%/lib %JAVA_HOME%/jre/lib

116 Section 6 Installation 113 IV. Copy the folder provided for middleware to the work-station used for middleware. Edit the file netinterface.java as follows: Enter the IP address of the server inside the file netinterface.java. In the code line: URL url=new URL(" Replace x s by the IP address the server. V. Compile the classes in the following order using Sun Java SDK: ComputeSmsData ComputeSmsData1 Driver SMSParser NetInterface SQLRetriever Dictionary Parser ReplyGenerator GSMtest.java MissingData MissingList Converter SendReplySMSInLocalLanguage DocumentSizeFilter DBaseModify The order has to be maintained because the objects of the classes which are earlier in the list are used in the classes those are latter in the list. We also have to remember that we cannot even declare a variable (i.e. even before actually creating an object) of an un-compiled class. V. Run the file GSMtest.class using "java GSMtest" in commandline or executing directly on Netbeans/JCreator.

117 Section 6 Installation 114 VI. Run the DBaseModify.class to update the Language database. N.B. The number of the sim card used in the GSM modem is to be given to the client for entry into the application Change Number Test case We had installed J2SE 1.6 and used JCreator 4 Pro as a GUI base environment for editing, compiling and executing the java files. Installation of Java: It was installed with the java installer. Environmental variable Classpath and Java_home was set to path/java/jdk This is also done to the machine running the server. The GSM modem used for testing was GDM 6002D GSM DATA MODULE with DCPS 14J REGULATED POWER SUPPLY. The modem was connected to the SERIAL/COM PORT of an hp laptop and the java files were kept in a folder on the desktop.

118 Section 6 Installation Server Side Introduction This stage is done in a work station running an HTTP server. The objective of the server is to get the query from the middleware, extract the appropriate data from the databases and return it to the middleware Minimum requirements An HTTP server (Apache Tomcat) An SQL based database system (MySQL) Sun Java SDK 1.6 (The system was tested with Apache Tomcat and MySQL 5.0) Installation Tomcat setup: Installing Tomcat on Windows can be done easily using the Windows installer. Its interface and functionality is similar to other wizard based installers, with only a few items of interest. Installation as a service: Tomcat will be installed as a Windows NT/2k/XP service no matter what setting is selected. Using the checkbox on the component page sets the service as "auto" startup, so that Tomcat is automatically started when Windows starts. For optimal security, the service should be run as a separate user, with reduced permissions (see the Windows Services administration tool and its documentation). Java location: The installer will use the registry or the JAVA_HOME environment variable to determine the base path of a J2SE 5 JRE.

119 Section 6 Installation 116 Tray icon: When Tomcat is run as a service, there will be a tray icon visible. Note that when choosing to run Tomcat at the end of installation, the tray icon will be loaded at the same time. The installer will create shortcuts allowing starting and configuring Tomcat. It is important to note that the Tomcat administration web application can only be used when Tomcat is running. If using a J2SE 1.4 JRE, the compatibility package must be downloaded and expanded inside the folder where Tomcat was installed. Installation of Apache Tomcat : By running the Apache Tomcat Setup Wizard, the software is installed into the folder path/apache Software Foundation. The port is 80. The environmental variable CATALINA_HOME was set to the value path/ apache-tomcat The file apache-tomcat /common/lib/servlet-api.jar is to be copied into the location path/java/jdk 1.6.0/jre/lib. Installation of MySQL 5.0: MySQL is to be installed into the computer into the folder by running the installation wizard. The Instance Configuration Wizard has to be run and a password has to be given. The MySQL control center should also be installed. It need not be used, and the database can be accessed from command line as Start MySQL MySQL Command Line Client. But databases created by Command Line Client usually cannot be copied from one computer to another. Hence Control Center is better.

120 Section 6 Installation Setup Step 1: The file FarmerServlet.java is to be placed in the folder containing the active servlets of the http server, and it has to be edited as follows. The username and password for the localhost of the database system has to be entered in the file mentioned above. In the code line: Connection con = DriverManager.getConnection("jdbc:mysql://localhost:3306/agri","uuu","ppp"); Replace the u s with the username and the p s with the password, and compile the java file. Compilation generates the class file FarmerServlet.class. Step 2: The file FarmerServlet.class has to be placed in the directory: C:\apache-tomcat \webapps\servlets-examples\WEB-INF\classes Step 3: Feed the agri.sql file into the database system i.e. the MySQL server. Run the file agri.sql at the command prompt: c:\mysql -u userid -ppassword < path\agri.sql Step 4: Start the HTTP server (The HTTP server must allow remote access of localhost.) The Apache Tomcat server is started using the startup file located in C:\apache-tomcat \bin

121 E KRISHI REFERENCES