Toward Virtual Marketplaces For E-Commerce Support

With the rapid development of the Internet, e-commerce is attracting the attention of several academic as well as industrial organizations. The main purpose of these organizations is to leverage the traditional relationships existing between sellers and buyers. To this end, new advanced technologies and techniques, such as software agents and strategies for negotiations that could support both sellers and buyers, are developed and experimented. In this “Technical Opinion,” we consider sellers as providers of services while buyers are considered as consumers of services.

In an environment that consists of several providers of services, potential consumers should be able to discover these providers and select the appropriate ones. The selection could be based on different criteria, such as reducing the use cost of services. Currently, the most common approach to connect consumers to providers and vice versa consists of inserting an intermediate layer between them. Generally, specific types of components, called brokers, are in charge of managing this layer. In fact, brokers receive from the providers their advertisements of services and from the consumers their requests of services. Subsequently, the broker matches these advertisements to appropriate requests. We assume all participants, namely providers, consumers, and brokers, use a common communication language. Minimal language includes offering services, responding to offers, negotiating, and invoking services.

Figure 1 presents a broker-based environment. The numbers correspond to the operations’ chronology. Despite its major role in receiving both advertisements and requests and matching them, the broker could become a bottleneck. In fact, the broker is involved in all the interactions leading to the identification of the providers according to the consumers’ requests. Therefore, consumers and providers rely heavily on the broker. In addition, certain drawbacks could be associated with the broker:

The broker may not be able to negotiate on behalf of all providers/consumers. Generally, each provider/consumer has its negotiation strategy that meets its needs and expectations. The burden of conducting all negotiations could overwhelm the broker very rapidly. In Figure 1, consumers are responsible for conducting negotiations with providers. In fact, the broker is only in charge of sending a list of potential providers to a consumer (Con_i). Next, this consumer sends remote messages, regarding its intention of negotiating, to all these providers (Negotiation(Con_i, Pro_j=1…n)). These exchanges of messages could “take time,” before the appropriate provider is identified and a service agreement is reached. Next, a request invoking this remote service is sent to the provider (Request-of-service(Con_i, Pro_j,Ser_k)).
The functioning of a broker-based environment depends mainly on the network’s state. Several remote messages, concerning advertisements, requests, and negotiations are needed before providers and consumers reach agreements. Therefore, the network has to be fully reliable and efficient.
Considering the number of messages that could be exchanged, security issues become a concern, especially during the negotiations phase. For instance, malicious providers may attempt to discover competitors’ offers.

In order to overcome the different drawbacks presented here, a novel solution consists of introducing a meeting infrastructure (MI) as a support middleware to the negotiations between providers and consumers. The MI can be seen as a virtual marketplace in which consumers and providers meet and exchange their messages locally. These exchanges should focus on services’ identification and negotiation. Acting as the gatekeeper of the MI, a specialized component named “supervisor” could be suggested. The supervisor monitors the interactions that take place within the MI and enforces the MI’s policies (such as security and access issues).

Figure 2 presents a meeting infrastructure-based environment. In order to be operational, this environment’s components, namely providers and consumers, have to move to the MI. Hence, they have to be embedded with mobility mechanisms. Instead of allowing consumers and providers to move, an alternative solution consists of creating agents that act on their behalf. Each agent is associated with either a consumer or a provider, called the agent’s owner. After their creation, the agents are shipped to the MI where the supervisor authenticates them. If these agents’ credentials are valid, the supervisor installs them and allows them to interact. Of course, a cost could be associated with the use of the MI.

In the MI-based environment, remote interactions for requesting services will only occur after reaching agreements between providers’ agents and consumers’ agents. Note that agents should inform their respective owners about these agreements through notification messages (see Figure 2). As long as it is needed and allowed by the supervisor, the agents could remain in the MI. However, their owners should update them regularly with diverse information, such as new needs to satisfy, new negotiation strategies to follow, new services to look for.

It is interesting to note that different types of interactions could happen in the MI. In addition to the provider-consumer interaction, two types of interactions exist, namely provider-provider and consumer-consumer (see Figure 3). In the provider-provider interaction, it could occur that different providers decide to constitute alliances in order to join forces and hence offer value-added services. To set up alliances, a pre-meeting stage is required. This stage allows the providers to find out with whom they have similar interests and then, to set up an alliance. In a provider alliance, sharing the gain among this alliance’s participants should be dealt with. Indeed, specific rules should regulate the internal functioning of an alliance. Such rules may allow, for instance, designating the alliance’s responsible as well as defining rewards. The consumer-consumer alliance occurs when several consumers decide to join for better conditions, such as service cost from providers. In this type of alliance, an interesting issue would be dealing with identifying the contribution rates of each participant. As with the provider alliances, internal rules should be set up.

Security is a key issue in a MI-based environment. Assuming consumers and providers interact locally within the MI, careful considerations should be taken into account at the MI boundaries where authentication and verification of consumers’ and providers’ credentials occur. Moreover, security problems can also arise within the MI. Agents misbehaving and unfair competition between providers are only two examples of several security threats. Working out strategies to reveal these threats is essential in the MI. Additional constraints that improve the infrastructure’s security could also be added, such as limiting the presence duration in the MI and defining opening and closing hours.

According to the work done in [1], setting up an alliance could be done either before (pre-) negotiation or after (post-) negotiation. In what follows, we focus on alliances of type customer. In pre-negotiated alliances, the leader of the future alliance negotiates a deal with providers. To this end, he or she has to estimate, for example, the alliance size and order volume. Once a deal is reached, the leader advertises the future creation of the alliance and solicits potential consumers to join. In post-negotiated alliances, it is set up first based on some criteria such as geographical proximity of members. Then, an alliance leader is designated in order to bear negotiation with providers.

One of the major differences between the two approaches is risk distribution among the alliance members. In pre-negotiation, the leader must estimate correctly the number of future members of the alliance. If the estimate is wrong, the leader must proceed consequently by absorbing the loss or increasing the contribution of members. In post-negotiation, alliance members must be able to trust their leader who will negotiate on their behalf. Therefore, selecting the appropriate leader remains a concern to the success of negotiation.

An implementation of the MI-based environment has been realized using the Java programming language. The meeting infrastructure uses Sun’s JavaSpaces technology to implement a repository that holds the providers’ services advertisement. Consumer and provider agents are implemented with Voyager ORB’s Agent mechanisms.

The prototype simulates how systems, playing both provider and consumer roles, advertise their services and look for services from other systems to satisfy their needs. Two agents represent a system: a consumer agent and a provider agent. Once they are provided with the system’s needs and available services, the agents are ordered to migrate to the MI. As soon as they arrive, provider agents advertise their services using JavaSpaces repository. Consumer agents check this repository, searching for the services that could satisfy their needs. The agents may ask JavaSpaces to notify them when needed services register in the repository. Once a match is realized, the agents involved notify their respective systems. Then, a service exchange takes places.

The prototype simulates how systems, playing both provider and consumer roles, advertise their services and look for services from other systems to satisfy their needs.

The meeting infrastructure has been implemented as a set of three modules:

Management and installation: Receives agents from their original systems and installs them. All the security operations are undertaken in this module.
Interaction: Supports the communications that take place between consumers’ agents and providers’ agents. These communications lead into contracts.
Advertisement and consulting: Supported by JavaSpaces, this module deals with advertising services and identifying the services required for satisfying specific needs. In addition, the advertisement and consulting module supports the subscription process to consumers’ agents. For instance, if an agent is interested in a specific event, then this agent could be notified when this event occurs. JavaSpaces allows this notification operation.

Figure 4 is the user interface of the meeting infrastructure. In the top portion of the interface (the interaction module), six agents, respectively, called Bob (C-P), Charli (C-P), and Alfred (C-P) are meeting. In the interface, P means “provider” while C means “consumer.” Consumer agents and provider agents are in red and blue, respectively. Agent status is represented in the bottom portion of the interface.

In this “Technical Opinion,” we described how the e-commerce field could be the object of further research efforts. For instance, the meeting infrastructure approach could be used to simulate financial marketplaces, such as Wall Street. We are aware that more work needs to be done, especially regarding security policies and negotiation strategies.