Provider Negotiation Agent

The Provider Negotiation Agent (PNA) is responsible mainly for two key activities, namely for registering the local processes of an administrative domain into the virtual marketplaces, based on the values stored into the Offer Repository, and for negotiating with VE partners about certain local processes.

In the first case, the PNA retrieves all the local processes that have been specified in the Offer Repository, migrates to the virtual marketplace and starts communicating with the STA and SOA agents by exchanging FIPA compliant ACL/XML messages based on the Virtual marketplace ontology. The communication protocol for the exchange of messages is the standard FIPA request-response protocol. If a service type for a given local business process already exist, then the PNA registers an offer to the marketplace by sending a register service offer request message to the SOA agent. If a service type does not exist, then the PNA agent initially creates a new service type, by communicating with the STA agent, and then registers the service offer.

In the second case, if a VE partner needs to execute a remote process, it first conducts the virtual marketplace to find a set of VE candidate partners for this process and then starts to negotiate with them based on a standard negotiation protocol. The agent representing the requestor domain is the Requestor Negotiation Agent (RNA) (see RNA section) while the agent representing the VE candidate domain is the PNA. These two agents communicate by exchanging messages specified in FIPA compliant ACL/XML format using the negotiation ontology. The protocol used during the negotiation process is the standard FIPA Contract-Net. More details about the negotiation process and how the PNA communicates with the RNA are provided in the section related to the Requestor Negotiation Agent (see the related section to the RNA).

In both cases, the Provider Negotiation Agent should send, receive and parse incoming and outcoming ACL/XML messages by using both an ACL and an XML parser. The PNA should also support two different FIPA compliant communication protocols, namely the

Request-Response and the Contract-Net protocol. Finally, the PNA should also formulate outgoing ACL/XML messages accordingly and take decisions about the proposals that he should do during negotiation based on a well-defined but simple strategy. All the above stated operations are provided by specialized entities included into the PNA agent. In addition to the generic entities of a FIPA compliant agent, the internal architecture of the PNA agent contains the following modules:

• VMP and INDO XML Parser: responsible for parsing the content of the FIPA ACL messages based on the marketplace and the Inter-domain ontology,

• VMP and INDO Message composer: responsible for composing the appropriate response FIPA ACL-XML messages related either with the marketplace agents or the RNA The structure of the messages is based on both the virtual marketplace and the Inter-domain ontology,

• Decision manager: responsible for controlling the basic operations of the agent, communicating with the Offer Repository, the Strategy manager, and the other entities

• Strategy manager: responsible for providing proposals during the negotiation process and according to a well-defined strategy. In the context of this thesis¹², only a simple strategy algorithm has been implemented.

In the following picture the internal architecture of the PNA agent and the relationships among the basic modules is depicted.

ACL Parser

VMP & INDO XML Parser

Decision Manager

Offer Repository

Message Composer

Provider Negotiation

Agent

Communication

Manager Java Invocations

FIPA ACL/XML

Strategy Manager

Figure 40: Provider Negotiation Agent Internal Architecture

The PNA initially retrieves from the Offer Repository all the local process that have been specified. For that reason, the agent accesses the XML file of the Offer Repository and instantiates the Offer Repository object. In the sequel, for every local process specified in the Offer Repository, the agent retrieves the name of the process, the input, output and negotiation parameters and the values associated with them. As soon the retrieval of the data from the Offer Repository finished, the agent migrates to the virtual marketplace using the native migration services of the agent platform. Then, for the local processes specified in the Offer Repository

12 The strategy that can be followed during negotiation process is out of the scope of this thesis. However, the interesting reader can have a look on the following reference (Bichler 98)

performs the following operations. The PNA generates a service type registration message and sends it to the STA agent. The service type has as a name the name of the local process, and properties the names and values of the input, output and negotiation parameters. If there is no service type with such characteristics, then a new service type is created. As soon as a service type has been found or created, the PNA agent generates a service offer registration request message and sends it to the SOA agent. The message is a FIPA compliant ACL/XML message that follows the virtual marketplace ontology. Property values for the negotiation parameters are only the allowable values specified in the negotiation parameters, i.e. the negotiation parameters that have public mode. On the contrary, private property values that will influence the negotiation process are kept secret and are not included into the offer registration. When all the local processes have been successful registered into the marketplace, the PNA migrates back to the original domain using the migration services of the mobile agent platform. In the following Figure 41 the steps involved in the registration of the local business processes into the virtual marketplaces are depicted.

V i r t u a l M a r k e t P l a c e VE C andidate partner

1

4,5 3

2

G r a s s h o p p e r FIPA

D i s t r i b u t e d P r o c e s s i n g Environment O f f e r

R e p o s i t o r y

P N A

S T A

S O A P N A

J a v a I n v o c a t i o n F I P A A C L / X M L M i g r a t i o n

6

G r a s s h o p p e r FIPA

D i s t r i b u t e d P r o c e s s i n g Environment

Figure 41: Business Process Registration into the Virtual Marketplace

In the following sequence diagram, the internal steps that the PNA agent follows to create a service type based on the data stored into the Offer Repository in relation to the internal modules is depicted. When the PNA agent launched, it first parses the Offer Repository in XML and instantiates an Offer Repository object. In the sequel, the Decision Manager gets all the stored offers. For every Offer object, the Decision Manager retrieves the name of the local process, the input parameters, the output and the negotiation parameters. For each one of these objects, the agent retrieves the name of the parameter, value and the constraints specified for it. Based on these information, the agent with the help of the Message Composer creates a create service type request message, that complies with the virtual marketplace ontology, and sends it to the STA agent located in the virtual marketplace.

: D e c i s i o n M a n a g e r

: O f f e r R e p o s i t o r y

: O f f e r : m e s s a g e c o m p o s e r

: C o m m u n i c a t i o n M a n a g e r g e t O f f e r ( )

g e t I n p u t P a r a m e t e r s ( )

g e t O u t p u t P a r a m e t e r s ( )

g e t N e g o t i a t i o n P a r a m e t e r s ( ) i n s t a n t i a t e O f f e r ( )

c r e a t e R e g i s t e r S e r v i c e T y p e ( )

s e n d m e s s a g e ( )

Figure 42: PNA Service Type Generation Sequence Diagram

Furthermore, in the following sequence diagram, the internal steps that the PNA agent follows to create and register a service offer based on an existing service type in relation to internal modules is depicted. In similar way like in previous case, the Decision Manager gets all the stored offers and for every Offer object, the name of the local process, the input parameters, the output and the negotiation parameters are retrieved. Based on this information, the agent creates a register service offer request message, which complies with the virtual marketplace ontology, and sends it to the SOA agent located in the virtual marketplace.

: O f f e r R e p o s i t o r y : D e c i s i o n

M a n a g e r

: O f f e r : m e s s a g e c o m p o s e r

: C o m m u n i c a t i o n M a n a g e r g e t O f f e r ( )

g e t I n p u t P a r a m e t e r s ( ) g e t O u t p u t P a r a m e t e r s ( ) g e t N e g o t i a t i o n P a r a m e t e r s ( )

i n s t a n t i a t e O f f e r ( )

c r e a t e R e g i s t e r S e r v i c e T y p e ( )

s e n d m e s s a g e ( ) c h e c k N e g o t i a t i o n P a r a m e t e r M o d e ( )

Figure 43: PNA Service Offer Generation Sequence Diagram

Moreover, when the Business Process Analysts deletes or modifies an offer from the Offer Repository, the corresponding offer in the virtual marketplace should be deleted or modified. In both cases, the PNA agent is re-launched again. In principle the agent follows the same process as previously described. In more details, the agent retrieves from the Offer Repository the set of

offers that have been deleted and modified. The names of these offers are stored in individual lists maintained by the Offer Repository. In the case of the deleted ones, the PNA migrates to the virtual marketplace, creates a withdraw service offer request messages and sends them to the SOA agent. In the case of modified, the PNA retrieves from the Offer Repository the modified offers and creates corresponding modify service offer request messages and sends them to the SOA agent in the virtual marketplace. As soon this service offer update process has finished, the PNA migrates back to its original domain and deletes the list of deleted and modified offers maintained in its local Offer Repository. When new modifications to existing offers will be done, the PNA agent will perform in a similar way, i.e. by updating the services offers in virtual marketplace and thus, maintaining consistency wit h the offers stored into the local, domain specific Offer Repository.

Finally, the PNA agent is also responsible for negotiation process during partner selection. For that reason, the PNA negotiates with the Resource Negotiation Agents (RNAs) located in the VE partner domains by following a standard negotiation ontology and protocol. Details regarding how the PNA agent is functioning, the type of messages exchanged, and the protocol and ontology used will be provided in the section related to Resource Negotiation Agent.