Figure 5: All messages between an interagent and its customer are encapsulated as either requests or responses of the SHIP protocol.
The extenSible and Hierarchical Interaction Protocol (SHIP) offers a layered approach to support all levels of agent interaction (a layer per level introduced in Section 1). Each layer groups a set of protocols with similar functionality together, and provides an abstract interface to higher layers that hides the details related to the particular protocol in use. For instance, two agents can exchange utterances without worrying about the underlying communication mechanism --message passing, tuple-space or remote procedure call. In addition to this, the hierarchical structure of SHIP allows agents to choose their interaction level. This involves the use of the sub-hierarchy of SHIP represented by the chosen layer and the layers below, but not higher layers, e.g. an agent may decide to use the transport layer and the lower levels (the connection layer in this case) but not the higher layers of SHIP. Lastly, SHIP is extensible, in the sense that it permits the incorporation (plug-in) of new protocols into each layer.
SHIP is a request/response protocol which distinguishes two roles: client and server. An interagent may play both roles at the same time, e.g. it can act as a server for its customer, and as a client for another interagent. In a typical message flow a client sends a request to the server, and this sends a response back to the client. All messages exchanged between a client and a server are encapsulated as either requests or responses of the SHIP protocol as depicted by Figure 5. Observe that both requests and responses are represented as XML messages that nest the information corresponding to each level of interaction. On the sender side, messages to be sent are wrapped at each layer and passed down till getting to the communication layer responsible for the sending. Upon reception, on the receiver side, messages are unwrapped at each layer and passed up to higher layers till the message arrives at the layer chosen by the agent for interacting.
SHIP has been built upon the following hierarchy of layers (from top to bottom): content, agent communication, conversation,transport and connection. In what follows we describe the functionality of each one of these layers taken as example the SHIP request in Figure 5 corresponding to a request for bidding of a buyer agent.
The content layer is concerned with the language for representing the information exchanged between agents. Such information refers to terms of a specific vocabulary of an application domain (ontology ). For example, a piece of information at this level might be the predicate codified in the FM language using the ontology Fishmarket.
The intentional layer codifies and de-codifies performatives in a given ACL. For example, a performative requesting for bidding at this level wraps the predicate received from the content layer with the illocution REQUEST of the Basic ACL (Basil) whose performatives are shown in Table 1.
The conversational layer is in charge of providing the necessary mechanisms for the negotiation, instantiation, and management of CPs as explained in depth in Section 3. Following the example above, the performative is wrapped with the information related to the context in which it is uttered (conversation protocol in use, sender, receiver, etc.).
The transport layer is concerned with the transport of utterances. For this purpose, we have devised the Inter-Agent Protocol (IAP), an extensible application-level protocol based on the Hypertext Transfer Protocol (HTTP). IAP constrains the body of a message to be an utterance. Moreover IAP overrides the set of request methods provided by HTTP. For instance, on the one hand the POST method is used to indicate that the utterance enclosed in the message body must be addressed to the receiver specified in the context. On the other hand, the GET method is used to retrieve the utterance accepted by an interagent that matches the pattern of utterance enclosed in the message body. Furthermore, a new addressing scheme has been introduced (iap://) and a new default port (2112).
IAP allows messages to be tagged with different headers to specify their lifetime:
We have introduced IAP due to the lack of an adequate transport protocol for agents' communicative acts. Currently, most ACLs such as FIPA ACL or KQML only define minimal message transport mechanisms --in FIPA ACL terms ``a textual form delivered over a simple byte stream''. As an alternative to simple TCP/IP sockets, other transport protocols such as HTTP, SMTP or even GSM have been proposed. However, on the one hand these protocols offer many unnecessary features for this task, and on the other hand they lack many desirable features. Hence the convenience of designing IAP as a specialized protocol for the transport of utterances.
The connection layer occupies the lowest level of the SHIP protocol. It is responsible for the creation of connections for SHIP requests. We consider a connection as a virtual circuit established between two agents for the purpose of communication. Different network protocols can be employed to establish such connections. Currently, JIM interagents support a wide variety of network protocols: memory I/O streams, (TCP/IP) stream sockets, and SSL sockets; others like RMI and IIOP will be supported in the near future.
As a final remark, notice that SHIP has required the introduction of several MIME (Multipurpose Internet Mail Extensions) types for declaring the types of conversation protocol (e.g. CP/DBP), of ACL (e.g. text/basil, text/kqml, text/fipaacl, etc.), etc.