D OMAIN R EPRESENTATIVE A GENT - BUSINESS PROCESS MANAGEMENT

CHAPTER 8: BUSINESS PROCESS MANAGEMENT

8.3 D OMAIN R EPRESENTATIVE A GENT

: XML Parser : TCP/IP server : Decision

Manager

: Active User Repository

: Message composer

: Communication Manager

: ACL Parser

informUser( )

parse ACL( ) parse XML( )

checkMessage( ) getActiveUser( )

updateProcessStatus( )

compose inform message( )

Figure 51: Process Instance Completes Sequence Diagram

In the following section, details about the functionality and internal modules of the DR agent and how it operates to perform its key operations are provided.

The DR agent always checks the identity of the requesting agents and authorizes or not the execution of the process. In the first case, i.e. when the request is coming from the PUA, the authorization of the user is performed by the PUA and thus, no extra authorization is performed.

The PUA agent considered by the DR a trusted agent. In the second case, i.e. when a remote WPA requests the execution of a business process, the DR always checks whether this agent has the right to access this process. This performed by conducting the Contract Repository.

The Contract Repository maintains a list of contracts that have been established with remote domains. Every contract is a result of a successful negotiation process between a remote requestor domain and this domain. The meaning of the contract is strictly technically and not legal¹⁴. The existence of a contract concerning a particular local process means that a specific WPA agent from a specific remote domain can access this process. The contract has a limited duration and lasts only during the execution of the local process. When the requested local process has been completed, then the contract and its corresponding id is deleted. In that way, processes that are heavily requested by remote domains can be provided with different pricing schemes while processes that have not been requested can be provided with better prices.

In general, a contract has always a unique id, the date of issue, is characterized as remote or local and contains data related to both domains. A contract is characterized local when the domain should provide the process to another domain. On the contrary, a contract is characterized remote when the domain deploys the business process from another domain. Additionally, the information stored for every domain can be categorized in three sections, namely the technical, the administrative and the pricing¹⁵ section. In the technical section, the name of the agents involved in the provision and management of the process, i.e. the DR and WPA agents, the FIPA address of these agents (see GUID in chapter 4), the ontology used, i.e. the inter-domain ontology, and the protocol used, i.e. the FIPA compliant Request-Response protocol, are stored.

In the administrative section, the name of the domains, the physical addresses, the name, telephone, fax and e-mail address of the administrative person, etc. In the pricing section, the price agreed, the payment method, the payment deadline, and the bank ids, are stored.

The following XML-DTD specification determines the format of a legitimate contract that can be established among two VE partners.

<!ELEMENT contract (Contract_ID, DateOfIssue, IsRemote, RequestorSection, SupplierSection)>

<!ELEMENT Contract_ID (#PCDATA)>

<!ELEMENT DateOfIssue (day_entity)

<!ELEMENT day_entity (day, month, year)>

<!ELEMENT day (#PCDATA)>

14 The interesting reader might get more information about the legal aspects of contracts in the following reference:

Directive 95/46/EC of the European Parliament and of the Council of 24 October 1995 on the protection of individuals with regard to the processing of personal data and on the free movement of such data, OJEC L 281 of 23 November 1995 and European Directive EC/97/7 of the European Parliament and the Council of 20 May 1997 on the protection of consumers in respect of distance contracts, OJEC L 144 of 4 June 1997, and on COM (97) 503

"Towards A European Framework for Digital Signatures And Encryption, available on http://www.ispo.cec.be/eif/policy/97503.html

15 Accounting mechanisms for inter-domain usage of services is out of the scope of this thesis. However, the interesting reader can have more information about that on “Introduction to Accounting Management” by B. Aboba, J.

Arkko, D. Harrington in the following IETF draft-ietf-aaa-acct-03.txt, 02-May-00

<!ELEMENT month (#PCDATA)>

<!ELEMENT year (#PCDATA)>

<!ELEMENT IsRemote(#PCDATA)>

<!ELEMENT RequestorSection (Technical_Section, Administrative_Section, Pricing_Section)>

<!ELEMENT Supplier Section (Technical_Section, Administrative_Section, Pricing_Section)>

<!ELEMENT Technical_Section (agentName, FIPA_Address, Ontology, Protocol)>

<!ELEMENT agentName (#PCDATA)>

<!ELEMENT FIPA_Address (#PCDATA)>

<!ATTLIST Technical_Section Ontology (Inter-Domain | Intra-Domain ) 'Inter-Domain' #REQUIRED>>

<!ATTLIST Technical_Section Protocol (Request-Response | Query-Response | Contrat-Net) 'Request-Response' #REQUIRED>>

<!ELEMENT Administrative_Section (DomainName, Address, telephone, fax, e_mail)>

<!ELEMENT DomainName (#PCDATA)>

<!ELEMENT Address (address_entity)>

<!ELEMENT address_entity (street, city, zipcode, country)

<!ELEMENT street (#PCDATA)>

<!ELEMENT city (#PCDATA)>

<!ELEMENT zipcode (#PCDATA)>

<!ELEMENT country (#PCDATA)>

<!ELEMENT telephone (#PCDATA)>

<!ELEMENT fax (#PCDATA)>

<!ELEMENT e-mail (#PCDATA)>

<!ELEMENT Pricing_Section (price, paymentMethod, paymentDateline, BankZIp)>

<!ELEMENT price (#PCDATA)>

<!ATTLIST pricing_Section paymentMethod (visa | eu-card | bank-transfer) 'visa'

#REQUIRED>>

<!ELEMENT paymentDateline (day_entity)>

<!ELEMENT BankZip (#PCDATA)>

All the contracts are stored in a conventional file system as ASCII XML files that follow the previously mentioned format. In addition to that, a configuration file called contract_repository.xml maintains all the existing contracts, i.e. the names of the contract files.

The main operations that the contract repository provides are to create a new contract and to delete an existing one. Modification of the contract is not allowed as soon as a contract has been created. The main reason is that existing contracts have been agreed on during negotiation and of course can not be changed individually by one domain without prior knowledge of the other. In the following Figure 52 the class model, the key entities and the relationships of the Contract Repository are depicted.

T e c h n i c a l S e c t i o n g e t A g e n t N a m e ( ) s e t A g e n t N a m e ( ) g e t F I P A A d d r e s s ( ) s e t F I P A A d d r e s s ( ) g e t O n t o l o g y ( ) s e t O n t o l o g y ( ) g e t P r o t o c o l ( ) s e t P r o t o c o l ( ) o p n a m e ( ) C o n t r a c t R e p o s i t o r y

g e t C o n t r a c t ( ) s e t C o n t r a c t ( ) d e l e t e C o n t r a c t ( )

C o n t r a c t g e t I d ( ) s e t I d ( )

g e t R e q u e s t o r S e c t i o n ( ) s e t R e q u e s t o r S e c t i o n ( ) g e t S u p p l i e r S e c t i o n ( ) s e t S u p p l i e r S e c t i o n ( ) 0 . . *

1 0 . . *

R e q u e s t o r S e c t i o n g e t T e c h n i c a l S e c t i o n ( ) s e t T e c h n i c a l S e c t i o n ( ) g e t A d m i n i s t r a t i v e S e c t i o n ( ) s e t A d m i n i s t r a t i v e S e c t i o n ( ) g e t P r i c i n g S e c t i o n ( ) s e t P r i c i n g S e c t i o n ( )

1 1 1

1 1

A d m i n i s t r a t i v e S e c t i o n g e t D o m a i n N a m e : r e t u r n ( ) s e t D o m a i n N a m e ( ) g e t A d d r e s s ( ) s e t A d d r e s s ( ) g e t T e l e p h o n e ( ) s e t T e l e p h o n e ( ) g e t F a x ( ) s e t F a x ( ) g e t E m a i l ( ) s e t E m a i l ( ) g e t P e r s o n N a m e ( ) s e t P e r s o n N a m e ( ) 1

S u p p l i e r S e c t i o n g e t T e c h n i c a l S e c t i o n ( ) s e t T e c h n i c a l S e c t i o n ( ) g e t A d m i n i s t r a t i v e S e c t i o n ( ) s e t A d m i n i s t r a t i v e S e c t i o n ( ) g e t P r i c i n g S e c t i o n ( ) s e t P r i c i n g S e c t i o n ( )

1 1

P r i c i n g S e c t i o n g e t P r i c e ( ) s e t P r i c e ( )

g e t P a y m e n t M e t h o d ( ) s e t P a y m e n t M e t h o d ( ) g e t P a y m e n t D e a d l i n e ( ) s e t P a y m e n t D e a d l i n e ( ) g e t B a n k I d ( )

s e t B a n k I d ( ) 1

1 1 1

1 1

Figure 52: Contract Repository Class Diagram

The Contract Repository used by the Provider Negotiation Agent (PNA) when a successful negotiation process has been performed. In that case, when the negotiation completes successfully, the PNA creates a new contract XML file, stores it into the file system and updates the contract_repository.xml configuration file about the new contract. In the sequel, when a request about a process execution arrives from a remote domain, the DR retrieves the corresponding contract, checks the contract id and the name of the requesting agent, and enables the execution or not of the requested process. In such a way, access control and authentication is performed.

When the DR gets a request from the PUA or from a remote WPA it functions in the following way: if the request is to start a process, the DR instantiates a new WPA agent and forwards to him the request. The request contains the name of the process, the process instance, the contract id, and the input parameters and values. From now on, the newly created WPA is responsible for the execution of the requested process. If the request is to suspend, to resume, or terminate a process, the DR locates the corresponding WPA agent for this process and forwards the request to him.

In order the DR to perform the mapping between the running process instances and the corresponding WPA agents executing these instances, the DR maintains a List of Active Processes (LAP). Whenever a new instance is instantiated, a new entry is created on the LAP.

Whenever an instance terminates, completes, or aborts the DR deletes the corresponding entry from the LAP. The LAP entries are actually records containing the process name, the instance

id, the contract id, the name of the WPA agent, and the name of the agent that initially requested to start the instance of the process.

Whenever a process instance changes status, it informs the initial requestor agent of this instance. This means that the responsible for this instance WPA, informs the DR about the status change by sending a FIPA ACL/XML message following the intra-domain ontology. The DR checks on the LAP to find the initial requestor agent, constructs a legitimate ACL/XML message, and forwards it to the related agent. It should be noted that responses about status changes are performed after corresponding requests have been issued. This means that a process instance will send a suspend status message only after getting a request to suspend. The only case that responses are generated without prior requests is when a process completes or when a process aborts. In that case, the process instance changes automatically status and informs the other agents about the change.

In addition to the key entities of a FIPA compliant agent, the DR agent contains the following modules:

• INDO XML Parser: responsible for parsing the content of the FIPA ACL messages based on the intra-inter domain ontology,

• INDO Message composer: responsible for composing the appropriate response FIPA ACL-XML messages related to the local WPA, PUA and remote WPA agent. The structure of the messages is based on the inter-intra domain ontology,

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

• List of Active Processes (LAP): responsible for maintaining all the active local processes running on this domain.

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

ACL Parser INDO

XML Parser

Decision Manager

Contract Repository

INDO Message Composer

Domain Representative

Agent

Communication

Manager Java Invocations

FIPA ACL/XML

LAP

Figure 53: Domain Representative Agent Internal Architecture

In the following sequence diagram, the internal steps that the DR agent follows to serve a request for a new process instance are provided. Initially, the DR gets an ACL/XML message from a remote WPA. It first parses the message using the ACL and the inter-domain XML

parsers. In the sequel, the DR checks the type of the request, i.e. start new process instance, and conducts the Contract Repository to check if there is an existing contract with this remote WPA agent. If a contract already exists, the DR creates a WPA agent using the native commands of the agent platform, i.e. the Grasshopper, updates the List of Active Processes and composes an ACL/XML message. The request message for the creation of new process instance is send to the newly created WPA. The message contains the name of the process, the instance id assigned to this process instance, the input parameters and the values for each one of them. Requests for the creation of new process instance coming from the PUA are served in a similar way. The only difference is that the contract repository is not involved since the PUA agent is considered a trusted agent.

: Decision Manager : Communication

Manager

: ACL Parser : XML Parser : Contract Repository

: LAP : message composer forward message( )

parse ACL( ) parse XML( )

getContract( )

checkContract( )

createWPA( )

createLAPEntry( )

composeStartProcessRequest( )

send message( )

Figure 54: Start Process Sequence Diagram

In the following sequence diagram, the internal steps that the DR agent follows to serve a response coming for an existing process instance and should be forwarded to the initial requestor agent, i.e. the PUA or the WPA discussed. Initially the DR gets an ACL/XML response message from one of its local WPA, parses it with the ACL and XML parser, and then checks the LAP. If the response message is terminated, aborted, or completed, the DR deletes the corresponding entry from the LAP. In addition to that, in case that the process has been completed, the corresponding contract has been fulfilled and thus, should be deleted from the contract repository, i.e. the contract_repository.xml. Access to this local process by this remote WPA is not valid any more unless a new contract will be established. In the sequel, the DR agent creates a legitimate response ACL/XML message and forwards it to the agent that started the process.

: ACL Parser : Communication

Manager

: Decision Manager

: XML Parser : LAP : message

composer forward message( )

send message( )

parse ACL( ) parse XML( )

checkLAPEntry( )

composeStartProcessRequest( )

Figure 55: Response Sequence Diagram

In the following section the key operations of the WPA agent are provided and certain details about the internal architecture, as well as, the modules are provided.

Im Dokument An Agent-Based Platform for the Management of Dynamic Virtual Enterprises (Seite 178-184)