CHAPTER 6: VIRTUAL MARKETPLACES
6.1 I NTRODUCTION
A Virtual Marketplace is a third party administrative domain that provides matchmaking services to the VE partners. The Virtual marketplace enables VE candidate partners to register and administer service offers in relation to certain service types and VE representatives to search for potential partners that can provide particular business processes associated with existing service types.
Every business process registered in the virtual marketplace is associated with a service type. In general, service types describe in a consistent way the interface of business processes. Service types mainly managed by the virtual marketplace administrator. The service type management includes creation, deletion, modification and retrieval of service types.
VE candidate partners that want to register their process offerings in the marketplace should always create a service offer in association with an existing service type and register it to the virtual marketplace. A service offer is actually an instance of a service type where certain properties have given certain values. Service offers are managed individually from each domain in a private manner. The management of service offers includes the registration of an offer, the withdrawal, the listing of offers and the modification of an offer.
Finally, VE representatives or partners that want to find suitable partners that can provide a particular process retrieve from the marketplace all the registered offers that satisfy certain constraints. The service offer retrieval management process actually includes the retrieval of offers that satisfy certain constraints.
Therefore, the basic services provided by the marketplace are service type management, service offer management, and service offer retrieval management. Each one of these services are provided by individual FIPA compliant agents, namely the:
• Service Type Agent (STA) responsible for the management of service types and more specifically for the addition, removal, listing, and modification of service types,
• Service Offer Agent (SOA) responsible for the management of service offers and more specifically for the registration, withdrawal, description, and modification of service offers,
• Service Offer Retrieval Agent (SOR) responsible for the retrieval of offers associated with a service type based on some constraints.
These three agents are FIPA compliant agent, i.e. they communicate with other agents by exchanging standard FIPA ACL/XML messages. The content of these messages is described in XML and it follows the Virtual Marketplace Ontology. The Virtual Marketplace Ontology describes the set of input and output messages that the marketplace agents can exchange with other agents. The whole specification of the Virtual Marketplace Ontology is given at the end of the thesis in Annex. Agents that want to communicate with the STA, SOA, or SOR agents should formulate and understand messages based on this ontology.
The layered reference architecture of the virtual marketplace is depicted in the following figure.
It is actually the specialisation of the overall reference architecture described in previous chapters for the virtual marketplace.
Distributed Processing Environment Corba/IIOP
Agent Platform &
Supporting Services
Grasshopper Mobile Agent Platform
SOA
STR SOR
OMG Trader
FIPA Add On
ACL/XML
Administration GUI SOR
STA
Distributed Processing Environment
ACC
AMS DF X
M L
Figure 20: Virtual Marketplace Reference Architecture
The key design principles of the agent-based Virtual Marketplaces are being influenced by the corresponding concepts of the OMG Trader. This is actually the objective of the thesis, i.e. to develop an agent-based virtual marketplace by integrating a standard OMG Trader. For that reason, a standard OMG Trader, as a basis for the development and testing of the virtual marketplace, has been used. In principle, the OMG-Trader is a CORBA object and could not be used directly by the different FIPA compliant agents in an autonomous and message-based way.
Due to this reason, the specialised STA, SOA, and SOR FIPA agents, as well as, the virtual marketplace ontology have been specified and developed. These agents are actually offering the basic functionality of the OMG-Trader in a FIPA compliant way to other agents.
The general format of a standard FIPA ACL/XML request based on the virtual marketplace ontology is the following:
(request
:sender Provider Negotiation Agent :receiver STA or SOA
:content ( <VMPMessage> // this is a VMP message
<STAMessage or SOAMessage> //this is a message for the STA agent
<STARequest or SOARequest RequestId="abc"> // id of the request <command type> // the command requested;
……. / /
</command type>//
</STARequest or SOARequest>
</STAMessage or SOAMessage>
</VMPMessage>
)
:protocol fipa-request :reply-with inform )
The general format of a standard FIPA ACL/XML inform response to a particular request is the following:
(inform
:sender STA or SOA
:receiver Provider Negotiation Agent
:content ( <VMPMessage> // this is a VMP message
<STAMessage or SOAMessage > //this is a message for the STA agent
<STAResonse or SOAResonse RequestId="abc"> // id of the request <command type> // the command requested;
……. / /
</command type>//close everything according to the DTD file </STARequest or SOARequest >
</STAMessage or SOAMessage >
</VMPMessage>
)
:protocol fipa-request :reply-with inform
)
In general, VE candidate partners that want to create or administer new service types in the marketplace should always refer to the appropriate service type name. In that case, a suitable agent migrates to the virtual marketplace, composes a FIPA ACL/XML request, and sends it to the STA agent. The communication protocol among the agents is based on the standard FIPA-Request-Response protocol (FIPA98). The STA receives the request, parses it from the ACL and XML parser, checks the type of the request and decides which action is required. In the sequel, the STA performs the request by deploying the Service Type Repository, generates an ACL/XML inform message and sends it to the requestor agent. The requestor agent, upon receipt of the message, parses it first from the ACL and XML parser, checks the response and migrates back to the VE candidate domain to inform its domain.
In a similar way, VE candidate partners willing to register new service offers in the marketplace or administer them should always refer to the appropriate service type name. In that case, in a similar manner like the STA agent, an instance of a suitable agent migrates to the marketplace, composes a FIPA ACL/XML request and sends it to the SOA agent. In the sequel, the SOA receives the message, parses it from the ACL and XML parser, checks the type of the request and decides which action is required. Afterwards, the SOA performs the request, by deploying
the Service Offer Repository, composes an ACL/XML inform message and sends it back to the requestor agent. The requestor agent receives the message, parses it first from the ACL and XML parser, checks the reply of the SOA and migrates back to the VE candidate partner to inform its domain.
In addition to the generic entities that a FIPA compliant agent has, the internal architecture of a virtual marketplace agent consists of the following key components:
• VMP XML Parser: responsible for parsing the content of the FIPA ACL messages based on the virtual marketplace ontology,
• VMP Message composer: responsible for composing the appropriate response FIPA ACL-XML messages that will be sent back to the requestor agents. The structure of the message is based on the marketplace ontology,
• Decision manager: responsible for controlling the basic operations of the agent, communicating with the STR, SOA and the OMG-Trader. According to whether the agent is STA, SOA or SOR this module is different in order to perform the appropria te operations.
ACL Parser
VMP XML Parser
Decision Manager
OMG Trader
VMP Message Composer
Generic VMP Agent Architecture
Communication
Manager CORBA IIOP
STR
SOR FIPA ACL/XML
Figure 21: Generic Virtual Marketplace Agent Internal Architecture
In the following sections, the STA, SOA, and SOR agents are further analyzed and more details about their functionality and structure are provided.