A Freight Brokering System Architecture Based on ...

Florin Leon, Costin Badica (2016) A Freight Brokering System Architecture Based on Web Services and Agents Proceedings of the 7th International Conference IESS 2016, Bucharest, Romania, Lecture Notes in Business Information Processing, vol. 247, pp. 537-546, Springer International Publishing Switzerland, doi: 10.1007/978-3-319-32689-4_41

A Freight Brokering System Architecture Based on Web Services and Agents Florin Leon1 and Costin Bădică2 1

Technical University “Gheorghe Asachi” of Iaşi, Romania [email protected] 2 University of Craiova, Romania [email protected]

Abstract. The aim of this paper is to introduce the architecture of a system that combines the strengths of agents and web services to address the practical application of freight brokering. This is an important real-life business problem which aims to provide matchmaking services that facilitate the connection of the owners of goods with the freight transportation providers. The paper presents the general architecture of the system including agents and web services, as well as the use cases and the details of its main operations. Our system can be beneficial to logistics companies by increasing the quality of provided services and by reducing costs. Keywords: web services, agents, architecture, freight brokering.

1 Introduction The integration of web services and agents tries to combine the strengths of both techniques. On the one hand, web services have the advantages of interoperability, flexibility in heterogeneous systems and the ability to automate service discovery and invocation with appropriate service description. On the other hand, agents are capable of autonomous and intelligent behaviour in order to represent the interests of their human users in an appropriate way [1]. In this paper, we aim to present the architecture of a system that combines these two computing paradigms. As a practical application, we address freight brokering, which is an important real-life business problem. The cargo owners and the providers of freight transportation services are continuously seeking new transport opportunities. This has led to the emergence of a new business model of freight transportation exchanges, which includes matchmaking services that facilitate the connection of the owners of goods with the freight transportation providers, in addition to online announcement and appropriate contracting. There are many virtual logistics platforms that operate in the domain of freight transport, exploiting the prospects provided by the requirements of goods that need to be transported, as well as of the availability of free vehicles, e.g. www.eurofreightexchange.com, www.bursadetransporturi.ro, www.europeancargo.ro, www.easycargo.ro, ro.trans.eu, www.timocom.com. The users are invited to register and post their offers in public directories. Then, potential customers can easily

browse, search and manually inspect these directories in order to determine appropriate offers that suit their business needs. The available information contains real-time transport and goods postings in many, diverse fields of activity [2]. The main contribution of the present paper is the architecture of a brokering system for the delivery of smart logistics services, which integrates the concepts of web services and agents. We organize it as follows. Section 2 presents some previous research in the field of intelligent brokering solutions. Section 3 describes the proposed architecture of the system. Section 4 contains the conclusions of our work and some ideas for future investigations.

2 Related Work A freight broker coordinates transportation arrangements between transport customers, usually shippers and consignees, and transport resource providers or carriers. Their revenue model is based on transaction fees or commissions. For a successful, sustainable operation, freight brokers create and manage a vast network of customers. The goal is a convenient, efficient matchmaking of freight and transport availability according to various customer specifications, which allows customers to find the best terms and conditions for fulfilling their specific needs, including e.g. price, loading and unloading points, duration and safety [3]. This logistic problem has been addressed by means of web services, e.g. a freight transportation systems based on SOAP web services [4], a service-oriented architecture for long distance logistics and supply chain management [5] or a semantic web service discovery and selection system for the logistic operators domain [6]. There is also a quite rich research literature on the use of multiagent systems for modelling and development of domain-independent or domain-specific brokering services, as well as for the design of e-business applications in the logistics sector. A sound taxonomy of domain-independent middle-agents based on formal modelling using process algebras and temporal logic is proposed in [7]. In particular, the formal details of a domain-independent broker agent are presented and its differences from matchmaker and front-agent types of middle-agents are highlighted. An agent-based domain-independent brokering service is presented in [8], where the focus of the research is set on the semantic capabilities of the broker using rules and ontologies, rather than on its formal behavioural features. Domain-specific semantics in the logistics sector are described in [9]. A new agent and cloud-based model for the logistics chain is proposed in [10], where the SMART cooperation model is introduced, which allows companies to collaborate during the logistics process, thus improving the overall system intelligence. Another study that suggests the use of agent-based negotiation for logistics management systems is [11], where the focus is on the whole supply chain, rather than on brokering of logistics services. The use of multiagent systems is motivated by the interactivity, responsiveness and social characteristics of this domain.

The integration of agents and web services has been investigated e.g. by [12], with the aim of reusing agent-based reasoning capabilities by making them available for invocation as web services. The EMERALD framework [13] for agent-based reasoning interoperability in the semantic web was extended with a web service interface. In the context of semantic web, ontologies for the freight transportation brokering domain have also been proposed [14] and evaluated with prototypical use case scenarios [15].

3 The Proposed Architecture A key feature of a freight broker is the ability to negotiate with both transport providers and customers to efficiently choose among the many delivery segments that define a certain transport task such that each segment is covered and the vehicles do not travel without cargo on the delivery segments. A delivery segment is defined as the distance travelled by the vehicles of a transport provider between two locations in order to deliver the goods from one place to another. Typically, a freight broker acquires an address on the Internet and sets up a web application, i.e. an e-marketplace, to communicate more effectively with transportation providers and customers. This e-marketplace allows the registration of actors that represent legal persons or individuals. Each actor may subsequently register the availability of certain vehicles or certain transport applications, respectively. The goal of the broker is the efficient automation of allocating freight requests to transport resources. Transport providers can register for the e-marketplace with several transport vehicles. A transport request is allocated to a transport vehicle owned by a specific transport provider. While the e-marketplace is mainly perceived as a user-friendly interface by the clients, the actual functionality behind this interface is provided by our proposed system. An intelligent service is able to create an optimal transport route such that a vehicle does not move without cargo or, at least, that the movement without cargo is kept at a minimum on the road segments between two loading points. The actual implementation of the designed system can benefit from existing mathematical optimization methods developed for the freight brokerage industry [16]. In a previous study [2], an agent-based freight brokering system was proposed. In the present paper, we extend this model by describing an architecture which integrates both agents, as representatives of customers and of transport providers, and RESTful web services for a more efficient, scalable solution that can handle a large number of requests. The general architecture of the system is presented in Fig. 1. The agents represent both individual clients and individual transport providers. They connect to specific web services in order to interact with the matchmaking system. It is important to distinguish between the agents and the service they use in the first step of interaction. That is why we named the agents Clients and the web service Customer for the beneficiary part, and we named the agents Transporters and the web service Provider for the supplier part, respectively.

Fig. 1. The general architecture of the freight brokering system

The Customer and the Provider web services further send the requests and offers of the Clients and Transporters to the Broker web service, which acts as a mediator. It is here that the requests and offers are matched and a tentative schedule is computed. The results must be communicated to the Clients and Transporters. This is made by email notification, with the help of an Email web service and an EmailNotifier agent which sends direct messages to the Clients and Transporters agents. Both Clients and Transporters can accept or reject a solution proposed by the Broker. Also, after a task has been completed, a Client may optionally assess the quality of the transportation. All this information is communicated to the Statistics web service, which aggregates it in an appropriate way.

The Broker eventually receives the transport requests from the Customer (including vehicle description and points of loading and unloading) and the list of available vehicles that are capable to perform the transport requests from the Provider (including vehicle description as well as location and date of availability) and has to establish convenient terms and conditions for the tasks, e.g. a lower price and/or a convenient date and time. The Broker determines the list of potential freight providers matching a given transport request or a list of potential travel requests matching a given freight transport resource provision and proposes convenient matches for both parties. The Statistics web service collects the data about past transactions and satisfaction reports and performs a post-action analysis that can be used to improve the decision making process. Finally, when a Client must pay for the transportation service, it accomplishes this by using a third-party, secure Payment web service. The Transporter receives the payment and the brokering system receives a fee for matching offers and scheduling tasks. 3.1. Integrating Web Services and Agents The integration of web services and agents is an active area of research. One of the most popular middleware frameworks for the development of multiagent systems is JADE [17]. It has the capability of defining services provided by agents, listed in a “yellow pages”-like directory called Directory Facilitator (DF). There are several ways in which these agent-based services can be exposed as actual web services. Also, it is important to enable the agents to access external web services. One method is to use Web Services Integration Gateway (WSIG), proposed by the creators of JADE [18]. Its objective is to expose services provided by agents and published in the JADE DF as web services with no or minimal additional effort from the part of developers. The process involves: the generation of a suitable Web Service Definition Language (WSDL) file that represents the interface of each service registered with the DF, and possibly the publication of the exposed services in a Universal Description, Discovery, and Integration (UDDI) registry. Another method is WS2JADE [19], a two-layer architecture composed of a dynamic interconnection layer containing web service agents (WSA), capable of communicating with web services and offering web services as their own, and a static management layer responsible for active service discovery and registration. Both these methods are based on a service-oriented architecture and technically use SOAP web services. However, JADE agents can be also integrated with RESTful web services, which are simpler in terms of implementation and resource addressing. One example of a specific integration of agents with RESTful web services is presented in [20]. In this case, the architecture of the REST publisher is more complex than the WSDL publisher. The authors suggest the use of an automatic generator for simple services and the use of a dedicated, manually created mapping for more complicated services. In order to use external web services from within the agent middleware, a wrapper component can be used, which mimics the original

service interface and also complies with the asynchronous requirements of the middleware. The implementation of the provided service is represented by a specific forward mechanism that dispatches the call to the external web service. Due to the overall simplicity and scalability of RESTful web services, this is the approach we adopted for our system. 3.2. The Broker Unlike the previous approach [2] that relies on direct agent negotiation to obtain a solution, in this paper we assume a centralized matchmaking process encapsulated in the Broker web service. The centralized approach has the main disadvantage of complexity, but the clear advantage of more accurate solutions. The negotiation with the agents is still present in the form of accepting or rejecting solutions, as presented in section 3.3. Regarding the internal functionality of the Broker, a combination of heuristics and optimization by linear programming can be used, adapted from the methodology described in [16]. The first heuristic step is to eliminate the invalid pairings between clients and transporters: 1) pairings with conflicting shipping dates and times; 2) pairings with conflicting requirements, i.e. the trucks which do not match the necessary equipment for a particular load; 3) pairings in which the load origin and the empty location of a truck are too far away, i.e. when a truck needs to come empty from a long distance, e.g. 500km, in order to pick up a load; 4) pairings in which the empty time and location of a truck preclude its ability to arrive at the client by the specified time, considering e.g. an average speed of 60 km/h and a minimum of 2 hours to load the freight. The second step is to add a “phantom” pairing for each load with a non-existing, very expensive truck. The purpose of these pairings is to guarantee a feasible solution to the optimization problem. The third step is to express the matchmaking as a zero-one linear programming optimization problem and solve it using for example one of many tools freely available, e.g. lpsolve [21]. The optimization problem can be expressed as follows:

Min c j x j jP

(1)

such that:

x 

j

 1, i  L

(2)

j j k

 1, k  T

(3)

j i

jP

x  jP

x j ,  i j ,  kj {0, 1}, j  P, i  L, k  T

(4)

where L is the set of all loads, T is the set of all trucks, P is the set of all possible pairings and c j is the cost of pairing j. x j is 1 if pairing j is selected and 0 otherwise.

 i j is 1 if load i is part of pairing j and 0 otherwise.  kj is 1 if truck k is part of pairing j and 0 otherwise. Equation 2 guarantees that each load is part of one and only one pairing and equation 3 guarantees that each truck is used at most once in the set of pairings. 3.3. Use Cases for Agents as User Representatives We assume that the Customer provides the following services to a Client: 1) register or deregister; 2) send or update requests; 3) accept or reject a schedule solution; 4) send satisfaction report. Also, the Client can make payments using the Payment web service. Fig. 2 presents an UML use case diagram for these operations.

Fig. 2. Use case diagram for the customers

When a Client sends or updates a request, the call to the web service also includes possible limits for the acceptable price range or a minimum required level of reputation for the transporter. The EmailNotifier, which informs a Client that the Broker has proposed a solution, is also an actor. A Client agent needs information from the user that describes his/her request of a transport service, including: date of request, point of dispatch, point of destination, proposed date of loading, proposed date of unloading, weight, volume, special

transport constraints, lifetime. The interaction with the Broker is performed exclusively through the Customer web service. In the end, possibly after several rounds of proposals from the Broker, sent by means of notifications by the EmailNotifier agent, the Client agent may succeed or fail in finding an appropriate transport deal for its user. If successful, it will present its user with a suitable transport deal including negotiated dates of loading and unloading, as well as other specific details, depending on the request. A similar diagram is presented in Fig. 3 for a Transporter, which can interact with the Provider web service in the following ways: 1) register or deregister; 2) send or update the list of available vehicles; 3) accept or reject a schedule solution; 4) only view information about its reputation, based on the satisfaction reports sent by the Clients.

Fig. 3. Use case diagram for the freight transport providers

The EmailNotifier informs a Transporter that the Broker has proposed a solution. Regarding the list of available vehicles, since its size can be large, we consider that it should be sent as an XML attachment. A Transport agent needs information from its user about the vehicle description, including: type of vehicle (e.g. regular truck, tanker truck, van), vehicle dedicated for a special type of freight (e.g. regular cargo, logs, cars, animals, etc.), type of fuel (e.g. petrol, diesel), carrying capacity, length, width, height, as well as special characteristics such as: canvas vehicle, hydraulic tailgate vehicle (hydraulic lift). It also needs information about the transport resource availability, including location, date and time. Like in the Client case, the interaction with the Broker is performed exclusively through the Provider web service, and it is notified by the EmailNotifier agent about the proposals of the Broker. Finally, it will present the possible solution to its user.

3.4. Details of the Main Operations In this section, we describe the main operations in more detail. Regarding the process where the system receives requests/offers and searches for matches between them, the Clients and Transporters can access their corresponding contact points, Customer and Provider, respectively, at any time. The two web services work in parallel and notify the Broker that updates have been performed. The Broker accesses the actual data through some file links, because the volume of information may be too high to be sent directly. After the Broker has solved the optimization problem given the current constraints, it informs the Email web service, which sends email messages to the involved parties. This process is facilitated by the EmailNotifier agent. Another important process is the way in which the agents, as user representatives, decide whether a proposed solution is acceptable. This is also performed in an asynchronous way. Both a Client and a Transporter must accept a solution in order for a contract to be established. Since the system is based on email notifications, and many users can be present in the system while some users/agents may simply give up a previous request or offer without explicitly informing the brokering system, a timeout is introduced, such as if the two parties do not confirm their commitment in a predefined period of time, the solution is considered to be automatically rejected. After a contract has been established, the client must pay. The payment method is not enforced by our architecture, because it may depend on the parties: some may require advanced payment while others may accept payment after the service has been successfully completed, or even payment into an escrow account may be used.

4 Conclusions In this paper we described the architecture of a freight brokering system that integrates the use of web services and agents. Such a system can be beneficial to logistics companies by increasing the quality of provided services and by reducing costs. As future directions of investigation, we aim at specifying additional details about the information required by each component of the system which will help the implementation of the system and its use for real-world transportation case studies.

References 1. Betz, T., Cabac, L., Wester-Ebbinghaus, M.: Gateway Architecture for Web-Based Agent Services. Lecture Notes in Computer Science, vol. 6973, pp. 165--172, MATES 2011. Springer Verlag (2011) 2. Luncean, L., Bădică, C., Bădică, A.: Agent-Based System for Brokering of Logistics Services -- Initial Report. In: Nguyen, N.T., Attachoo, B., Trawinski, B., Somboonviwat, K. (eds.) Intelligent Information and Database Systems: 6th Asian Conference, ACIIDS 2014, LNCS, vol. 8398, Part II, pp. 485--494. Springer International Publishing, Cham, Switzerland (2014) 3. Bowersox, D.J., Closs, D.J.: Logistical Management: The Integrated Supply Chain Process. McGraw-Hill (1996)

4. Ji, C., Li, M., Li, L.: Freight transportation system based on Web service. Proceedings of the 2004 IEEE International Conference on Services Computing, pp. 567--570 (2004) 5. Cho, H., Woo, J., Ivezik, N., Jones, A., Denno, P., Peng, Y.: An Integration Technology for Long Distance Logistics and Supply Chain Management. Proceedings of the 18th International Conference on Management of Technology (2009), http://ebiquity.umbc.edu/ _file_directory_/papers/559.pdf 6. Carenini, A., Cerizza, D., Comerio, M., Della Valle, E., De Paoli, F., Maurino, A., Palmonari, M., Sassi, M., Turati, A.: Semantic Web Service Discovery and Selection: a Test Bed Scenario. Proceedings of the 6th International Workshop on Evaluation of Ontology-based Tools and the Semantic Web Service Challenge, CEUR Workshop Proceedings, vol. 359, paper no. 3 (2008), http://ceur-ws.org/Vol-359/Paper-3.pdf 7. Bădică, A., Bădică, C.: FSP and FLTL framework for specification and verification of middle-agents. Applied Mathematics and Computer Science, 21(1), 9--25 (2011) 8. Antoniou, G., Skylogiannis, T., Bikakis, A., Doerr, M., Bassiliades, N.: Dr-brokering: A semantic brokering system. Knowledge-Based Systems, 20(1), 61--72 (2007) 9. Scheuermann, A., Hoxha, J.: Ontologies for intelligent provision of logistics services. Proceedings of the Seventh International Conference on Internet and Web Applications and Services, ICIW 2012, pp. 106--111 (2012) 10. Kawa, A.: Smart logistics chain. Lecture Notes in Computer Science, vol. 7196, Part I, pp. 432--438, ACIIDS 2012. Springer, Heidelberg (2012) 11. Guanghai, Z., Runhong, Y.: Multi-agent supply logistics intelligent management system based on negotiation. Computer Science Applications and Education, 3(1), 476--481 (2013) 12. Bădică, C., Bassiliades, N., Ilie, S., Kravari, K.: Agent Reasoning on the Web using Web Services. Computer Science and Information Systems, 11(2), 697--721 (2014) 13. Kravari, K., Kontopoulos, E., Bassiliades, N.: EMERALD: A Multi-Agent System for Knowledge-Based Reasoning Interoperability in the Semantic Web. Lecture Notes in Computer Science, vol. 6040, pp. 173--182, Artificial Intelligence: Theories, Models and Applications. Springer Berlin Heidelberg (2010) 14. Luncean, L., Bădică, C.: Semantic Modeling of Information for Freight Transportation Broker. Proceedings of the 2014 16th International Symposium on Symbolic and Numeric Algorithms for Scientific Computing, SYNASC, pp. 527--534 (2014) 15. Luncean, L., Becheru, A., Bădică, C.: Initial evaluation of an ontology for transport brokering. Proceedings of the 2015 IEEE 19th International Conference on Computer Supported Cooperative Work in Design, CSCWD, pp. 121--126 (2015) 16. Silver, J.L.: Optimization tools for the freight brokerage industry. Master’s thesis, Massachusetts Institute of Technology, Engineering Systems (2003), http://hdl.handle.net/1721.1/28574 17. Bellifemine, F. L., Caire, G., Greenwood, D: Developing Multi-Agent Systems with JADE. Wiley Series in Agent Technology (2007) 18. JADE Board: JADE Web Services Integration Gateway (WSIG) Guide. Telecom Italia (2008), http://jade.tilab.com/doc/tutorials/WSIG_Guide.pdf 19. Nguyen, X.T., Kowalczyk, R.: WS2JADE: Integrating Web Service with Jade Agents. Lecture Notes in Computer Science, vol. 4504, pp. 147--159, Service-Oriented Computing: Agents, Semantics, and Engineering. Springer Berlin Heidelberg (2007) 20. Braubach, L., Pokahr, A.: Conceptual Integration of Agents with WSDL and RESTful Web Services. Lecture Notes in Computer Science, vol. 7837, pp. 17--34, Programming MultiAgent Systems. Springer (2013) 21. Berkelaar, M., Eikland, K., Notebaert, P.: lpsolve, Open source (Mixed-Integer) Linear Programming system, http://sourceforge.net/projects/lpsolve/