Grid based market for agro-produce

Agro-marketing system

Marketing of agricultural produce is a complex task involving various stake holders, products, and business scenarios. In a developing country like India, this activity is influenced by local, socio-economic, and cultural characteristics. Evaluating the business processes at the regional or national scale reveals diversity in products, terminology and processes involved to perform complete business activities. While other complex but well-defined business processes are experiencing benefits of services driven e-Business; the ‘marketing of agricultural produce’ has remained untouched by this revolution. The government of India is now planning to introduce agricultural marketing reforms to streamline trading processes involved in all markets throughout the nation using proper IT infrastructure.

Problem definition

The software and hardware infrastructure at this scale cannot be expected to be homogeneous throughout. Proposed standards and specifications to develop an information system based on Service-oriented Architecture, are conflicting and immature. The consequence of this scenario introduces many difficult challenges. Resources for sellers and buyers located all over the country, are to be created. The main challenge is in creating a market service which matches seller and buyer preferences and instantiates trade between them. ‘Grid based Agro-Produce Marketing System’ will be able to inter-connect sellers and buyers located all over country to support various business transactions in the form of grid services. The proposed system can be developed based on the principles of Grid Computing and Service-Oriented Architecture.

System design

The Grid computing utilises the Service Oriented Architecture (SOA) to meet requirements of the Grid Business Process. The goal of SOA is to achieve loosely coupled interoperable integration among scattered and heterogeneous services and clients. Principles of SOA influence the business logic of services by encouraging modular design and component reuse through dynamic discovery of existing services. Web services have been established as a popular technology for design and implementing SOA based business processes. A web service has five essential attributes: it can be described using a standard service description language, Web Service Description Language (WSDL); it can be published to a registry of services, Universal Description, Discovery and Integration (UDDI) registry; it can be discovered by searching the service registry; it can be invoked, usually remotely, through a declared API; and, it can be composed with other Web services. The trade starts with the intention of the trader to sell a particular agricultural produce. The price is set by the auction or any other transparent system as defined in the Act. Once the agreed upon price is received, it is published for the traders.

Components

The case study is designed following the service-oriented grid architecture to provide state, notification, execution and monitoring, and scalability. The role of the targeted system is to automate the business process with interoperable integration of scattered services. The design is upon various WS (www.oasis-open.org) specifications, specifically the set of WSRF and WS-Notification (WSN) specifications to achieve required compliance. The distributed architecture implemented in the use case comprises of various components and resources;  some of the role of these resources and components of the system are as follows:

Grid manager: The service is an implementation of the Factory/Instance Collection Pattern. It initiates different type of resources i.e. Seller, Buyer, Crop and Market according to the client request; hosted by different Grid Nodes. The Grid Manager orchestrates different components of the system in a predefined manner for the smooth working of the whole application. The Grid Manager is the first point of the contact with the system.

Grid nodes: They creates a hosting environment which hosts different vanilla or stateful Web Services. The services hosted on different nodes are used in various combinations to capture the requirement of the application. Each initialised WS-Resource has End Point Reference (EPR) attached to it, which identifies the resource itself and the URL of the managing Instance Service. Ideally these Grid Nodes should be geographically dispersed across various enterprises.

Grid registry: It is a special Service based on the WS-ServiceGroup specification, which keeps track of various resources initialised during the course of application. The Grid Client can update and query the Grid Registry to search appropriate resources.

Grid client:  It is an external application which either requests for initialisation of the resource/s or interacts with the existing resource/s to query, destroy or modify them. The client adheres with the WSA specification to work with WS-Resources and corresponding services through their EPR.  In this case study the Grid Client has three flavors, for buyers, sellers and administrator which instantiate the market instance for the trade.

Instantiation and interaction with the seller entity: The first interaction of the seller with the system results in the creation of the new seller WS-Resource. This resource captures all details of the specific seller and is used for the future interaction with that seller.

Instantiation and interaction with the buyer entity: Similarly the first interaction of the buyer with the system results in the creation of the new buyer WS-Resource. This resource captures all details of the specific buyer and is used for the future interaction with that seller.

Market Service for direct/indirect trading: This system matches resources for different sellers and buyers which are trading in the same location. Once any such match is found then it means that there is atleast one buyer interested in the produce of a seller. To simulate the successful trade the resource properties for seller and buyers are updated.  In the case of indirect trading, the initial matching of seller and buyer resources in the market is followed by invoking operations for the services specific to it.

Web services developed

In the agro-marketing case, along with discussed components, different stake holders are also involved such as the buyer, seller, market etc. These components and stake holders are implemented  either as stateful Web services, or as simple stateless Web services, based on its role in the overall functioning of the application. Below is the list of different Web services with their role and responsibilities, developed during the prototype:

Seller service: The service implements the business logic necessary for the seller. This service exposes different operations related to the seller resource such as instantiation of seller resources, monitoring and modification of different properties for seller resources. These operations are either executed manually by the seller or invoked automatically by other components during the course of the application.

Buyer service: This service is the implementation of the buyer. It instantiates the resource for a buyer, and provides different operations on the buyer resources. Instantiation of a buyer resource result in the registration of the Buyer with the system for future interactions. The service, after receiving the preferences instantiates a new resource instance for the buyer. The service also registers these preferences with the DefaultIndexService of Globus Toolkit 4 and provides operations to be invoked on this resource instance.

Market service: This service acts as an intermediary between buyers and sellers. The role of the Market Service is more or less like a broker service among different stake holders. It queries the Grid Registry (i.e. Index Service provided by the Globus Toolkit) to obtain the list sellers and buyers trading in the same city/market and continuously monitors the trading preferences of buyers and sellers to perform trade. The Market Service instantiates the new trade and transaction once it successfully matches the seller and buyer preferences. Initiation of the trade triggers the sequence of events which results in the update of buyer and seller resources involved in the trade and notification to interested parties. Grid Manager service: This service acts as a common factory service to instantiate different resources involved in the case study. The Grid Manager Service is implemented according to the Factory/Instance Collection Pattern and Master/Slave Pattern. The Grid Manager Service instantiate different resources through the specific service i.e. seller resource is instantiated through Seller Service.

Vehicle Fee service: This service is responsible for calculating any transportation charges incurred in case of indirect trade. The transportation charges are deducted from the final selling price and are paid by the seller.

Crop Price Service: This service is used for retrieving the current market price of the crop involved in the trade. The CropPrice Service calculates the price of the crop based on different factors such as the type of the crop, season, its availability in the market, and its demand etc. This service is only invoked when the mode of trade is indirect.

Marketing Fee Service: This service is used for deducting any marketing fee incurred during the course of indirect trade. Similar to the transportation charges, marketing fee is deducted from the final selling price and is paid by the seller.

Execution scenario

In this section the trading process is displayed by the execution of various services as indicated by a client.

Seller Grid Service: When the GridManagerClient is executed for each of the above given entities to perform trade, the following situation will emerge-By looking at the data above it can be inferred that for direct trade, seller and buyers interested in trading in a location will trade with each other. Similarly, trading will take place for sellers interested in indirect trading irrespective of location of their trading.

A seller expresses his intention to offer his crop for sale by running the client programme, Client.java by providing command line arguments. These arguments are in the following order:

URL of the GridManager service
seller: This word is provided to indicate client wants to have an instance of a seller service
Crop Name: The crop seller wishes to sell
Crop Quantity: The quantity of a crop, which seller is interested in selling
Crop Variety: The variety of a crop
Trade Location: The location where the seller wishes to trade
Expected Price/Kg.: The amount which a seller wishes to obtain per kg. of a crop
Trade Mode: If seller directly wants to sell directly to a buyer then direct mode is adopted, else indirect mode is adopted.

Buyer grid service
Similarly a buyer can express his intention to purchase crop by running Client.java but with a different set of command line arguments:

URL of the GridManager service
buyer: This word is provided to indicate that a client would like to have an instance of a buyer service
Crop name: The crop the buyer wishes to buy
Crop quantity: The crop quantity buyer is interested in purchasing
Crop variety: The variety of the crop
Trade location: The location where the buyer wishes to trade
Offered price/kg.: The amount which a buyer would like to obtain for every kilogram of a crop

Market grid service
Whenever the buyers and sellers express their intentions to trade, their resource instances are also registered with the  DefaultIndexService.

When MarketService start its operations, it will query  the DefaultIndexService to obtain the buyers and sellers interested in trading. The Client.java program is executed with a different set of command line arguments.

URL of the GridManager service.
Market: This word is provided to indicate that the client would like to have an instance of a market service.
Trade location: The location of a market where the actual trade will occur.

Once the market service of a particular location starts executing, it tries to match potential buyers and sellers. If an appropriate buyer is found for a seller, appropriate notification is sent to both of them to inform them about success of entering into a trade deal. Otherwise both of them will wait for a potential purchaser of a crop. In case of indirect trade mode, the seller receives various types of notifications, which are computed for this trade.

Notification to seller service

After the initiation of a market service for a location, matching will be performed for buyer(s) and seller(s) having preference
for that location. Based on the match found for a seller and a buyer for wheat, the following notification will be generated for a seller service:

  • A new notification has arrived
  • Your crop sold till now is 10.0Kg
  • A new notification has arrived
  • Your crop has been sold recently
  • A new notification has arrived
  • Your crop quantity still remaining to be sold is:40.0Kg
  • A new notification has arrived
  • Amount Offered to you per Kg is Rs70.0
  • A new notification has arrived
  • Crop Quantity Which will be purchased by a buyer is 10.0Kg
  • A new notification has arrived
  • Your Earning is Rs700.0
  • Waiting for notification. Ctrl-C to end.

Notification to a buyer service
Following types of notifications will be generated for a buyer service:

  • A new notification has arrived
  • The Crop Quantity which you will purchase from a seller is 10.0Kg
  • A new notification has arrived
  • Amount Offered by you per Kg is:Rs70.0
  • A new notification has arrived
  • Amount spent by you in current purchase is Rs700.0

Conclusions and future work

Business processes of large enterprise systems interact with various stake holders i.e. business partners and customers to integrate distributed heterogeneous services. The focus is on the utilisation and integration of the existing technologies to achieve loosely coupled integration of services having support for state, notification, execution monitoring and scalability. Principles of Grid computing utilising the Service Oriented Architecture (SOA) are followed and implemented to satisfy the requirements of the business process.

To achieve these objectives, WS-RF, WSN, and relevant specifications and standards in this area are followed here. The future work is diverted into several paths: implementation of policy, agreement, negotiation and use of semantic web to provide meaningful integration and co-ordination of resources in a grid environment. 

"Exciting news! Elets eGov is now on WhatsApp Channels 🚀 Subscribe today by clicking the link and stay updated with the latest insights!" Click here!
Be a part of Elets Collaborative Initiatives. Join Us for Upcoming Events and explore business opportunities. Like us on Facebook , connect with us on LinkedIn and follow us on Twitter , Instagram.