Inglés (pdf)
Articulo en XML
Referencias del artículo
Traducción automática
Enviar articulo por email
Citado por SciELO 
Citado por Google 
Similares en
SciELO 
Similares en Google 
Permalink
INTRODUCTION
In agriculture, farmers are faced with several problems during the production of different crops [1] [2]. The diseases and pests can affect crops, decreasing the quality and quantity of production. Generally, their origin is due to the attack of fungi, bacteria, plagues, and other agents. The generation of diseases mainly depends on the physiological status of the crop, meteorological conditions, and production zones of the country, among others.
Over time, diseases have devastated crops throughout the world, causing epidemics and losses [3] [4] [5]. This implies that important measures must be taken to mitigate the effects and improve productivity through practices such as crop protection and clean technologies, among others. For this reason, different tools that allow the detection of different diseases for subsequent treatment are used. An early warning system (EWS) can perform this detection through monitoring and analysis of crops conditions, which allow to provide timely information to the farmers about possible natural, biotic, and physical threats in such a way that they can prepare and take the necessary measures according to the level of crop risk [6].
The EWSs are usually designed to inform a large number of users, e. g., a large population such as a country or a region, of any risk situation. In the agriculture, these alerts should be more specific, so that they include characteristics as the location of the crop, as well as some of its properties. Taking into account the above, an improved EWS for diseases in crops is proposed in this paper for the generation of alerts and their adaptation through the integration of an enterprise services bus (ESB) and complex events processing (CEP), according to the area in which the crop is located and its phenology.
This paper is organized as follows: section 1 contains the state of the art; section 2 describes the solution proposed from the integration of the ESB and CEP to the EWS; section 3 presents the case study; section 4 presents the evaluation of the solution through a case study; section 5 describes the results obtained, and section 6 relates the conclusions and future work.
1. STATE OF THE ART
This section provides relevant information about studies carried out in the development of EWSs in agriculture, and personalization and adaptation of web services.
The EWSs are widely used in different domains as the detection of diseases in crops. These include key elements such as knowledge and threat mapping, monitoring and forecasting of impending events, and diffusion of alerts [7]. The correct combination of these elements results in a complete and reliable system that provides timely and understandable information to the population. In addition, an EWS should be people-centered, allowing communities threatened by a phenomenon to be able to act in a timely and appropriate manner to reduce potential losses.
In [8], weather data is included within an EWS for late blight in potato crops. Eight experimental plots with weather monitoring were used. After the data were analyzed and processed, a fixed calendar was obtained, containing the alarm dates for the disease occurrence and treatments to be carried out in the crops. In [9], an EWS to mitigate the impact of cockcrowing on coffee crops is presented. This system is based on mathematical models that use meteorological data to predict the favorable conditions for the development of the disease, and recommend the fungicides application at the right time, thus preventing its development. On the other hand, weather data monitored in crops is used in [10] as support for decision making, helping producers to determine the right moment for disease control.
Some EWSs make use of web services to provide data to the user. Precisely, the web services personalization collects user information during its interaction with the system, so that it is used to provide adequate contents and services for each user, in order to improve the user experience [11]. The purpose of using web service personalization is to improve an EWS with relevant information of each user, allowing that its response can be delivered only to those potentially affected.
Furthermore, web services can be modified in such a way that they can be adjusted to different circumstances or conditions, either by the specific user needs or by the environment in which they are running [12]: this feature is called adaptation. In [13], an approach using the mediation characteristics of the ESB to provide a dynamic adaptation of the services is presented. In the same way, the research presented in [14] describes an ESB implementation using JBossESB, focused on the description of a services adaptation framework based on the ESB capabilities previously mentioned. The research described in [15] proposes a solution that uses the ESB mediation patterns to adapt the services to a context, making use of the CEP to analyze the events received from external resources, and to detect the relevant situations that require an adaptation.
The studies presented above address the mediation features provided by the ESB to perform the adaptation of services, and some use CEP to identify context events (e. g. climate) that are relevant to the user. Although they consider an integration with CEP, this is conceived as an external and additional component of the ESB. In fact, some studies propose the use of the ESB to integrate event-driven architectures using CEP [16].
Therefore, we propose to carry out the adaptation of web services based on an ESB-CEP integration, making use of the mediation capabilities of the ESB to combine services-oriented architectures (SOA) for the generation of intercommunicated services [17] and event-driven architectures (EDA) to design and implement applications based on events [18]. The combination of these architectures allows the integration of different applications in heterogeneous environments and, through ESB, these can be unified to operate in specific areas. For the same purpose, the CEP monitors relevant situations (events) according to the system requirements. Our approach proposes a system with the ability to react to environmental events (expected or unexpected), in order to ensure the proper operation of web services.
2. ESB - CEP INTEGRATION FOR WEB SERVICES ADAPTATION
Although in [14] and [15] an adaptation of the services using the mediation characteristics of the ESB is implemented, these proposals do not use CEP to detect relevant events that require adaptation. Our proposal is aimed at the web services adaptation around the monitoring component of an EWS, since these systems do not provide solutions for a dynamic and automatic adaptation at runtime based on users' needs [19]. This is addressed through the integration between ESB and CEP, acting as a mediator element through which all messages are transported and can be transformed, routed, and invoked, among others. Also, it provides the analysis, detection, and correlation of the messages that are exchanged by the system actors, in order to identify relevant events of interest in an application scenario.
Therefore, following the approach proposed in [14], where the adaptation is performed within the ESB using its mediation capabilities, we introduce the model presented in figure 1.
Figure 1 shows the ESB-CEP integration to perform the adaptation process, which contains the elements presented in the adaptation and monitoring framework proposed by the S-Cube project [20]. This framework was adjusted to include the CEP within the ESB. The components are presented below:
Monitoring mechanisms check if the current situation corresponds to the expected one. This component can be addressed through the complex event processing (CEP) in charge of monitoring the events of interest.
Monitored events provide relevant information on the execution, evolution, or context of the services, detected through the monitoring mechanisms. These events represent the difference in the status, functionality or expected environment.
Adaptation requirements represent the need to modify a service to eliminate the difference between the current and expected state. These may include requirements for reliability or functional accuracy, optimization, interoperability, and usability.
Adaptation mechanisms contain the techniques and facilities provided by the ESB to carry out strategies according to the adaptation requirements.
Adaptation strategies are alternatives to meet adaptation requirements according to the current situation, e. g., to invoke an equivalent operation that considers new parameters. Different strategies can be used for the same situation, which requires decision mechanisms to select the most appropriate.
The general process proposed in figure 1 is executed as follows: a) relevant information is collected through monitoring mechanisms; b) critical events are detected; c) the need for adaptation is identified; d) a strategy for adaptation is identified; and e) adaptation is executed using the available adaptation mechanisms [20].
The model of adaptation described above can be applied to any environment. We applied it for the generation of early warnings for crop diseases, taking as a particular case the Coffee Rust, which will be explained in the next section.
2. CASE STUDY: COFFEE RUST DETECTION IN COLOMBIAN CROPS
In this section, we present an application of the proposal mentioned above, describing the problem domain and the cases of study to apply our solution.
2.1 Application domain
Coffee Rust is the main high-impact phytosanitary problem for coffee cultivation, caused by the pathogen Hemileia vastratix [21], a fungus that develops only in the living tissue of its host plant (for this case, the coffee leaves). In Colombia, this disease affects more than one million families that depend on coffee production. The consequences related to the disease are mainly related to economic and quality losses for coffee farmers. There is, in fact, an urgent need to take preventive measures for reducing the losses caused by this disease.
Some proposals [22 - 28] have been made from the computer sciences related to the automatic identification of conditions conducive to this disease, making use of machine learning techniques. In these studies, the authors make use of the different variables involved in the development of coffee rust in crops, which have been monitored in them. In the particular case of [25], an induction of decision trees to generate a model that predicts an infection rate of coffee rust from monitored data in crops is presented. This rate indicates whether the infection level of the disease tends to remain stable or reduced, to increase moderately, or to accelerate. The results of this research can be used as the main element to alert coffee producers about favorable conditions (weather and agronomic properties) present in crops for the disease.
This last research is implemented within the AgroCloud project, which belongs to the Interinstitutional Network of Climate Change and Food Security of Colombia (RICCLISA). In this project, a web platform [29] that aims to provide monitoring services to warn users about threat situations for coffee crops located in the upper Cauca River basin has been developed. For this purpose, a set of services are deployed: Web services of climatic data (WSDClima), in charge of obtaining all the weather data that are monitored in different coffee production zones; web services for the calculation of the variables that describe the crop condition against the disease, generated from weather data (WS VClimaticas); and web services for alert management (WS Alertas), which perform the database management of generated alerts and allow for their search, update, and deletion.
However, these approximations do not consider the alert personalization, considering factors that determine how timely is its diffusion, given the different coffee production zones in the country, which have distinct production cycles, flowering and harvest dates. Thus, two case studies are presented for the personalization of early warnings by adapting web services. The first one takes the coffee crop location as an additional factor for the personalization, and the second one takes the flowering date for the same purpose.
2.2 Case 1: Coffee crop location
The first case is based on the generation of early warnings for coffee rust making use of weather data monitored in the area where a crop is located. From this location, a crop can be classified within a coffee zone. Additionally, the supply stores and experts available within the coffee zone are obtained.
In Colombia, there are three coffee zones divided by semesters where the main harvest is presented [30]:
Zone 1: main harvest in the second half of the year. It includes the departments of Guajira, Magdalena, Cesar, Norte de Santander, Santander, Antioquia, Caldas, Risaralda and Meta (Figure 2).
Zone 2: main harvest in the first half of the year. It includes the departments of Cauca and Narino (Figure 2).
Zone 3: main harvest in the two semesters. It includes the departments of Valle del Cauca, Huila, Tolima, Quindío, Cundinamarca and Boyacá (Figure 2).
2.3 Case 2: Coffee flowering date
The second case aims to generate early warnings for coffee rust based on weather data in the area where a crop is located, and its flowering dates are provided by the farmer. Additionally, information about the chemical control products that can be used for the proper management of the disease, as well as recommendations about the experts, are obtained. Flowering can be understood as a phenological state, directly associated with crop production [31]. Therefore, flowering periods in coffee are directly related to outbreaks of diseases. In the case of coffee rust, if the date of flowering is known, it is possible to identify the moment in which the crop is more prone to the disease, and from this, to establish the ideal dates to start the control process.
According to [30], knowing the quantity and concentration of flowering can establish the period where the application of fungicides is more effective. Figures 3, 4 and 5 show the map of the Colombian coffee zones and the phenological behavior of crops. According to the disease and crop production cycle, the controls for the disease are defined in [30]. Therefore, it is possible to customize the recommendation according to the flowering date.
The adaptation proposal for each case is presented in table 1.
3. AGROCLOUD: WSA
This section addresses the implementation of the proposed solution for the study cases mentioned above within the AgroCloud platform [29], specifying the technology and the architecture used.
3.2 Implementation of the Proposed Solution
The generation of early warnings for coffee rust is addressed from the case studies described above. The services were personalized by adapting them using the scheme proposed in figure 6, which contains the interaction of the elements related in section 2.
The components of the scheme are described below:
Web services: Facilities implemented by AgroCloud to detect the favorable weather conditions for the appearance of coffee rust, and to generate the disease alerts (WS_DClima, WS_VClimaticas, WS_Alertas).
GlassFish server: Contains all the services developed (weather information, alert management, database access, among others).
PostgreSQL server: Persistence of the data handled by services.
Mule ESB: Through this bus, all messages between services, servers, and applications are transported. Additionally, everything related to adaptation is developed in this element.
Esper: CEP Engine in charge of monitoring the relevant situations presented in the case studies, in order to find all events that require an adaptation, according to the information provided by the users and their needs.
Mechanisms of adaptation: Tasks available within the ESB that allow the adaptation.
Adaptation strategies: Procedures to satisfy the requirements of adaptation according to the current situation.
3.2.1 Case Adapted 1
In order to implement the personalization of services for Case 1 (described in section 2.2) the proposed execution flow is the following:
a) The user makes a query through the platform AgroCloud, and the location of the crop is requested or detected.
b) Monitoring mechanisms (located on Esper CEP) process the location and recognize it as an event of interest.
c) The need for adaptation is identified, and the mechanisms available in the ESB (content enrichment, aggregator) are determined.
e) The most appropriate adaptation strategy to meet the requirement is identified.
3.2.2 Case Adapted 2
In order to implement the personalization of services for case 2 (described in section 2.3) , the proposed execution flow is described as follows:
a) The user makes a query through the platform AgroCloud, and introduces the date where the crop flowering was presented.
b) Monitoring mechanisms (located on Esper CEP) process the date of flowering, and recognize it as an event of interest.
c) The need for adaptation is identified, and the mechanisms available in the ESB (content enrichment, aggregator) are determined.
d) The most appropriate adaptation strategy to meet the requirement is identified.
4. RESULTS
This section presents the tests performed on the proposed solution. We considered the response time of web services, the use of computational resources, the efficiency in the events of interest detection, and user acceptance testing. Each of the tests was performed considering situations with and without the proposed adaptation.
4.1 Use of Computational Resources and Response Time
In order to measure the use of computational resources (CPU and RAM) in the web services execution with and without performing the proposed adaptation, the VisualVM 1.3.9 tool was used. These services were deployed on a server with the following features: 16GB of RAM, Intel Xeon processor at 1.8 GHz, and Ubuntu 12.04 as operating system. The results are shown in table 2. The use of both CPU and RAM is low and very similar in all cases, indicating that the proposed solution does not generate an overload in computational resources. On the other side, in order to measure the response time of web services with and without performing the proposed adaptation process, the SoapUI tool 5.3.0 was used to invoke each of them. The results obtained, based on 1200 invocations for each of the different web services, are presented in table 2. According to [36], the values obtained are considered as acceptable, since average response times are below 200 milliseconds.
Table 2 Use of Computational Resources
| Web Service | Average percentage of CPU usage | Average RAM usage (MB) | Average time (ms) |
|---|---|---|---|
| WSJJbication | 1.58 | 53.20 | 9.97 |
| WS_Flowering | 1.72 | 45.28 | 33.07 |
| WS_TasaRoya | 1.55 | 50.43 | 8.77 |
| WS_Products | 1.40 | 40.27 | 7.8 |
| WS_Store | 1.50 | 37.3 | 7.4 |
| WS_Experts | 1.38 | 36.5 | 8.0 |
| WS_Adaptation Case 1 (adapted for Case 1) | 1.39 | 51.02 | 39.17 |
| WS_Adaptation Case 2 (adapted for Case 2) | 1.52 | 44.10 | 14.66 |
Source: Prepared by the authors.
4.2 Decision Effectiveness
In the test that was performed to the CEP to verify the effectiveness in the detection of interest events, ten cases were considered. First, 100 examples were generated, divided into true (events requiring adaptation) and negative instances (events that do not require adaptation). Subsequently, the number of instances correctly classified by CEP was observed, determining the true positives, false negatives, true negatives, and false positives. For the following cases, the number of examples was increased in 100 successively until obtaining 1000 with a random proportion of true/negative instances in each of them. As a result, the number of false negatives and false positives was zero in all cases, which means that the CEP was able to identify the need for adaptation in the instances for each of the cases tested. This indicates that the process of detecting events of interest carried out by the CEP is effective, and adequate for the proposed solution.
4.3 User Acceptance Testing
The user acceptance test (UAT) [37] methodology is intended to analyze the use of the solution by the user, detecting possible errors in the answers, usability, and in the entry forms, corresponding to the problem that must be solved. From the theoretical basis of UAT, the application of this methodology is presented below:
Type of test: To carry out the UAT methodology, a functional or "black box" test was carried out, in which the users interact with the inputs and outputs of the system, leaving aside the source code and internal flow of the system. This test was developed from meetings in which each user interacted with the system through a computer.
Users: Within the coffee production environment, three types of users were identified, related to the treatment and control of the crop. The UAT methodology was applied to 53 users, described below:
Producers: Small farmers of medium or large sizes, according to the level of production. 5 medium producers from CajiWo (Cauca), an association of organic coffee producers (Popayan) (12 producers), and an association of coffee producers from Los Andes - Corinto (Cauca) (Asproccan) (20 producers).
Agricultural extension officers (AEO): Staff with technical knowledge in coffee production (delegates from the Federation of Coffee Growers) to advise producers on different problems surrounding the process. A technical assistance group of the National Federation of Coffee Growers (Colombia) was interviewed (15 users).
Researchers: They are usually agronomists who study the phenomena that affect coffee production, and how to solve them. An agronomist was interviewed for UAT.
Business requirements provide additional recommendations from specific information entered by the user to the system, in such a way that, based on it, the user can suggest a control to be made from their location, the agricultural input stores within the location, the experts of the area, and the dates in which the control of the disease can be carried out from the date of flowering.
Test cases: As already mentioned in section 3, in this case two test cases were worked on. Based on them, the results are shown below:
o Test Case 1
- Identification of the coffee zone.
- Obtain recommendation from the supply stores available from the coffee zone.
- Obtain recommendations from experts from the coffee area in which it is located.
o Test Case 2
- Identify the critical periods for the beginning of the disease from the date of flowering.
- Obtain a recommendation of the products to be used from the date of flowering. In addition, four questions were applied to each test case:
Q1) Was the task completed successfully?
Q2) Did the user require assistance to complete the task successfully?
Q3) Were the information request forms satisfactorily understood?
Q4) Do users consider the tool useful?
The number of users who answered affirmatively is shown in table 3.
5. CONCLUSIONS
This paper presents an adaptation proposal for web services used in early warning systems for crops diseases through a CEP-ESB integration, based on the adaptation and monitoring framework proposed by the S-Cube project.
The main contribution of our proposal is the use of the mediation capabilities provided by the ESB to carry out the adaptation process, in addition to the use of the CEP as a component in charge of monitoring events of interest that may require such adaptation. The use of computational resources (CPU and RAM) produced by the solution in its execution is among the acceptable ranges. The tests carried out through the UAT allow us to know the level of satisfaction of the end user with the proposed system, as well as to improve the usability and interpretability of the response provided. The EWS proposed is aimed at the generation of coffee rust that considers local properties of crops. Precisely, as related in [38], to combat this disease, the systematization and dissemination of these type of computational tools should be considered from regional research platforms to producer farm levels.
As future work, it is proposed to address other adaptation requirements, as well as the implementation and testing of other ESB and CEP products. On the other hand, incorrect input data could be solved by handling exceptions in web services.
