S ERVICE T YPE M ANAGEMENT - VIRTUAL MARKETPLACES

CHAPTER 6: VIRTUAL MARKETPLACES

6.2 S ERVICE T YPE M ANAGEMENT

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.

Service types can also be derived from other service types. A service type that inherits existing service types inherits also the properties specified for these super types. The concept of the inheritance is exactly the same like the one used in the object oriented systems. In such a way, value added service types can be created. The main reason for the inheritance concept is the re-usability and enhancement of existing service types.

According to previous descriptions, a service type has a name, a set of zero or more property descriptions, and a set of zero or more super types from which it inherits its extra common properties. A property description has a property name, a status, a type, e.g.. string, integer, or sequence of strings or integers. A super type is the name of an existing service type. Service Types can be created and managed either by the administrator of the marketplace or by the Provider Negotiation Agent (PNA). The following definitions can easily translated into the following DTD format of a service type.

<!ELEMENT Service Type (type, propdescs, super_types)>

<!ELEMENT type (#PCDATA)>

<!ELEMENT if_name (#PCDATA)>

<!ELEMENT propdescs (propdesc*)>

<!ELEMENT prop_name (#PCDATA)>

<!ELEMENT normal EMPTY>

<!ELEMENT readonly EMPTY>

<!ELEMENT mandatory EMPTY>

<!ELEMENT readonly_mandatory EMPTY>

<!ELEMENT super_types (super_type*)>

<!ELEMENT super_type (#PCDATA)>

Service Types are stored and maintained by the Service Type Repository (STR), which is located inside the marketplace domain. For every virtual marketplace only one STR exists. The main reason fro that is that the services types managed and administered by this marketplace should be stored in a central storage system for data consistency purposes. For every service type a service type object is created and stored into the STR. A service type object is actually an abstraction, in object oriented terms, of a service type that provides certain operations to access the information stored inside the object. Every service type and, consequently a service type object, is identified inside the STR by a unique service type name. All these objects are stored into and maintained by the STR. Using the service type name as a unique key to retrieve the service type, retrieval of service type objects is performed easily and effectively. The class model and the basic operations of the STR is depicted in the following Figure 22. The main operations of the STR are to create a new service type object, to delete it, and to modify it. The entity that deploys these operations is the Service Type Agent (STA).

STR getTypes() setTypes() deleteType() listTypes()

Service Type Object getProperties() setProperties() getName() setName() getSuperTypes() setSuperTypes() 0..*

1 0..*

Properties getname() setName() getValue() setValue() getMode() setMode() 0..*

1 0..*

Figure 22: Service Type Repository Class Model

The STA agent is responsible for the management of service types and the main operations that this agent provides are:

• addition of a service type to the STR,

• removal of a service type from the STR,

• listing of existing service types from the STR,

• description of a service type from the STR,

When the STA agent gets an ACL/XML request for an addition of new service type, it first parses the content of the incoming message from the ACL and XML parser and checks the type of the request. Since the request is the creation of a new service type, the Decision Manager requests from the STR to create a new service type object. Then, the Decision Manager inserts the information included in the message and requests from the STR to store it internally. As soon as the request has been fulfilled, the agent composes a response ACL/XML message and sends it back to the requestor. An example of the content of the FIPA ACL/XML message concerning service type addition is the following.

<type> testType1 </type>

<if_name> testTypeIf1 </if_name>

<prop_name> testprop1 </prop_name>

</propdesc>

<prop_name> testprop2 </prop_name>

</propdesc>

</propdescs>

<super_types>

</super_types>

</AddType>

</STARequest>

</STAMessage>

</VMPMessage>

The previously described steps are further explained in the following sequence diagram.

: message composer : Provider

Negotiation Agent

: Communication Manager

: ACL Parser : XML Parser : Service Type Repository : Decision

Manager add service type( )

forward message( )

parse ACL( ) parse XML( )

check request( )

create new service type object( )

compose inform message( ) send message( )

send ACL/XML response( )

Figure 23: Add Service Type Sequence Diagram

In a similar way like the creation of a new service type, when the STA agent gets an ACL/XML request for the deletion of an existing service type, it first parses the content of the incoming message from the ACL and XML parser and checks the type of the request. Since the request is the deletion of an existing service type, the Decision Manager requests from the STR to locate the corresponding service type object and then to delete it. As soon as the request for the deletion of an existing service type has been fulfilled, the agent composes a response ACL/XML message and sends it back to the requestor. An example of the content of the FIPA ACL/XML message concerning service type removal is the following.

<type> testType1 </type>

</RemoveType>

</STARequest>

</STAMessage>

</VMPMessage>

The previously described steps are further explained in the following sequence diagram.

: Provider Negotiation Agent

: Communication Manager

: Decision Manager

: ACL Parser : XML Parser : Service Type Repository

: message composer remove service type( )

forward message( )

parse ACL( ) parse XML( ) check request( )

delete service type object( ) compose inform message( ) send message( )

send ACL/XML response( )

Figure 24: Remove Service Type Sequence Diagram

When a VE candidate partner wants to get the list of existing service types stored into the marketplace, a request for list of existing service types is generated. In that case, the STA agent parses the incoming message and checks the request. Since the request is to list all the existing service types, the Decision Manager conducts the STR and asks from it to return the whole list of the existing service types. In the sequel, the agent composes the appropriate ACL/XML message based on the virtual marketplace ontology and sends it back to the requestor. An example of the content of the FIPA ACL/XML message concerning list service type operation is the following.

<all/>

</ListTypes>

</STARequest>

</STAMessage>

</VMPMessage>

The previously described steps are further explained in the following sequence diagram.

: Provider Negotiation Agent

: Communication Manager

: Decision Manager

: ACL Parser : XML Parser : Service Type Repository

: message composer list service types( )

send ACL/XML response( )

forward message( )

check request( )

send message( )

parse ACL( ) parse XML( )

list service type objects( ) compose inform message( )

Figure 25: List Service Types Sequence Diagram

Finally, when VE candidate partners want to get all the information, namely service type name and a set of named properties about an existing service stored into the marketplace, they should generate a request for describe service type. In that case, the STA agent parses the incoming message and checks the request. Since the request is to describe an existing service type, the Decision Manager conducts the STR and gets the corresponding service type object. In the sequel, the Decision Manager gets the information stored into the object and composes the appropriate ACL/XML message based on the virtual marketplace ontology and sends it back to the requestor. An example of the content of the FIPA ACL/XML message concerning describe service type operation is the following.

<type> testType1 </type>

</DescribeType>

</STARequest>

</STAMessage>

</VMPMessage>

The previously described steps are further explained in the following sequence diagram.

: Provider Negotiation Agent

: Communication Manager

: Decision Manager

: ACL Parser : XML Parser : Service Type Repository

: message composer list service types( )

send ACL/XML response( )

forward message( )

check request( )

send message( )

parse ACL( ) parse XML( )

list service type objects( )

compose inform message( )

Figure 26. Describe Service Type Sequence Diagram

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