Deliverable 2.3: Agentcities Network Architecture. Agentcities.RTD

Transcription

1 Deliverable 2.3: Agentcities Network Architecture Agentcities.RTD Motorola Associação para o Desenvolvimento das Telecomunicações e Técnicas de Informática AEGIS Agentscape AG Broadcom Éireann Research BTexact Technologies Communication Technologies Deutsches Forschungszentrum fuer Kuenstliche Intelligenz GmbH Ecole Polytechnique Federale de Lausanne Fujitsu Imperial College of Science, Technology and Medicine Queen Mary, University of London Universitat Politècnica de Catalunya Universita` degli Studi di Parma Telecom Italia Lab Project reference: IST

2 AGENTCITIES.RTD AGENTCITIES NETWORK ARCHITECTURE Del. no: D2.3 IST Version: Final /06/03 Deliverable type: Report Classification: FP5. Work package and task: WP2 Responsibility: EPFL Editor Ion Constantinescu (EPFL) Major contributions to this document from: Ion Constantinescu (EPFL) Steven Willmott (UPC) Jonathan Dale (Fujitsu) Input from: All participants of Paris and Ipswich WP2 meetings. Executive summary: This document provides a description of the Agentcities Network Architecture that was developed during the Agentcities.RTD project. It describes a technical framework describing a number of abstract concepts relevant to the network architecture, then a reification of that framework using the technologies evaluated during the Agentcities project and finally details on how the reification is instantiated in the network. Project no: IST /06/03

3 Contents 1.1. Relationship to other Agentcities Core Frameworks Existing Standards & Other Starting Points Contributions to the State of the Art How to Read this document How this document can change Abstractions Core Elements Functional Elements Supporting Elements Element Definitions Actors Services Domains Directories Directory Services Communication Mechanisms Specific Domains Canonical Network Example Network Architecture Properties Future Developments Actors Services Domains Directories Directory Services Protocols Communication Language Content Language Ontologies Communication Mechanisms Specific Domains Root Domains Actor Domains (Agent Domains) Service Domains Directory Service Domains Platform Domains FIPA Specifications in Use Actors Project no: IST /06/03

4 4.2. Services Domains Directories Directory Services Protocols Communication Language Content Language Ontologies Communication Mechanisms Specific Domains Actor Domains Service Domains Directory Service Domains FIPA Specifications in Use Managing Reifications Planned Reifications Bridges between systems using different reifications Constraints, Requirements and Objectives Reifications Used Instance/Deployment Overview Accessing the deployed Network Communication Mechanisms Specific Domains Root Domain Actor Domain (Agent Domain) Service Domain Directory Service Domain Agent Platform Domain Additional Definitions Ping Service Definition Interacting with the Agent Platform Directory Requirements and Objectives Actors Services Domains Specific Domains Directories Project no: IST /06/03

5 7.7. Directory Services Hidden DS...56 Top DSs...56 Normal DS Example Operations of the Network Scalable Query Scalable Registration Robust client interactions Joining the network Robust internal nodes Managing Instances Planned Instance Descriptions Bridges between different system instances Project no: IST /06/03

6 Table of Figures Figure 1 Component Specifications in this document Figure 2: The Restaurants Directory is recursively supported by the Members Directory Figure 3: Directory Services can apply different policies for each operation type / domain name. The topology of the network emerges from different policy combinations at the nodes Figure 4: Canonical Network Representation...22 Figure 5: Nodes in the network can play three roles: Hidden DS, Top DSs and Normal DSs Figure 6: Scalable query...58 Figure 7: Scalable entry registration...59 Figure 8: Robust client interaction...60 Figure 9: Robust node handling...60 Figure 10: Joining the network...61 Figure 11: Robust internal nodes...62 Project no: IST /06/03

7 References [AAP] April Agent Platform, Fujitsu Laboratories of America, [ac-test-suite] Agentcities Platform Interoperability Test Suite, version 1.1. D. Bonneyfoy, S. Willmott, N. Lhuillier, I. Constantinescu, J. Picault and Y. Camenen, Ecole Polytechnique Fédérale de Lausanne Department D Informatique Technical Report No 01/361, April, [actf-rec-00002] ACTF Connecting to the Agentcities Network Recommendation. I. Constantinescu, J. Dale, and S. Willmott, Agentcities Task Force, [AgentscapeAP] Agentscape Agent Platform, Agentscape AG, [AgentworksAP] Agentworks Agent Platform, AEGIS, [ATOMIK] Agent Ontology Manipulation Kernel, EPFL, [ComtecAP] Comtec Agent Platform, Communication Technologies, [FIPA00001I] [FIPA00008G] [FIPA00023H] [FIPA00061E] [FIPA00067D] [FIPA00070G] [FIPA00075E] [FIPA00084D] [FIPA00085H] FIPA Abstract Architecture Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00001, FIPA SL Content Language Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00008, FIPA Agent Management Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00023, FIPA ACL Message Structure Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00061, FIPA Message Transport Service Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00067, FIPA ACL Message Representation in String Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00070, FIPA Agent Message Transport Protocol for IIOP Specification, Foundation for Intelligent Physical Agents Experimental Specification FIPA00075, FIPA Agent Message Transport Protocol for HTTP Specification, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00084, FIPA Agent Message Transport Envelope Representation in XML, Foundation for Intelligent Physical Agents Experimental Specification, FIPA00085, [FIPAOS] FIPA-OS Agent Platform, Emorphia, [GnuJSP] GNU Java Server Pages, GNU Organisation, [JADE] Java Agent Development Environment, TI Laboratories, [JAKARTA] Jakarta Tomcat Reference Implementation, Apache Organisation, [JAMR] Java Agent Message Router, EPFL, [Jserv] Apache Java Server, Apache Organisation, Project no: IST /06/03

8 [JSP] Java Server Pages, JavaSoft, [LEAP] Lightweight Extensible Agent Platform, Leap Consortium, [MYSQL] MySQL Open Source SQL Database. [Network] Agentcities Network Services, Agentcities.RTD IST 5th Framework Project, [ZEUS] ZEUS Agent Platform, BT Exact Technologies, [SOAREQ] [DNS] [WSARCH] [OGSA] [ebxml] [ROSETTA] Network Architecture Requirements and Technologies (To be published as an ACTF recommendation). Agentcities.RTD IST 5th Framework Project, The Domain Name System. Internet Engineering Task Force (IETF) Request for Comments (RFC). RFC1033, RFC1034, RFC1035, RFC1982, RFC1995, RFC2136, RFC2181, RFC2182, RFC2535 Web Services Architecture, World Wide Web Consortium, The Physiology of the Grid An Open Grid Services Architecture for Distributed Systems Integration. Ian Foster, Carl Kesselman, Jeffrey M. Nick, Steven Tuecke. Electronic Business using extensible Markup Language (ebxml), Rosetta Net Project no: IST /06/03

9 PART I: OVERVIEW AND ABSTRACT MODEL 1. Overview and Context The Agentcities Network Architecture defines an architectural model for the development and deployment of large-scale networks of autonomous service components. The descriptions are intended as models both for the deployed Agentcities network ( and to be more generally useful in open environments using a range of technologies such as Web and GRID services. The network architecture is divided into three levels: A high level description of the key elements and structures to be found in the open service networks (Part I of this document, Sections ) Reifications of these high level models to a number of technology sets and particular interface definitions (Part II of this document, Sections ) Specification of deployed instances of networks including operational policies, structural descriptions and bindings to particular service instances (Part III, Sections ). The long term aims of the models presented here are to: - Provide a reference model for heterogeneous service environment where services are provided by different types of entity (from FIPA style Agents to Java Beans, CORBA objects or simple scripts) and rely on diverse implementation technologies. - Focus on the description and specification of the structures and relationships between entities deployed in the environment rather than description of the entities themselves. - Act as a complement to existing technology standards developed by bodies such as FIPA and the W3C by describing how networks of different types of technology components can be deployed and used. To date the architecture can only really claim significant progress towards the latter two goals since the almost all experimentation which has taken place in the Agentcities testbed to date has been based FIPA 2000 style agents. However the hope is that future versions of this architecture will include the results of ongoing activities involving Web Services and GRID bindings Relationship to other Agentcities Core Frameworks This document should be read in conjunction with the following two Agentcities.RTD deliverables: D3.3 Dynamic Value Creation Framework : describing models for dynamic coordination of activities between actors in open environments. D4.3 Service Interoperability Framework : describing models for actor-actor communication in open environments. Together with these two documents the Network Architecture is intended to provide a holistic first cut view of how open service environments can be developed, deployed and operated Existing Standards & Other Starting Points There are now a very large number of existing standards and frameworks related to network architecture [SOAREQ]. The architecture described here aims as much as possible to build on this previous work, reference it and reuse it and avoid new development where possible. The most influential frameworks in this process to date have been: The FIPA Abstract Architecture Specification [FIPA00001]: providing models abstracts elements and relationships necessary for interoperability between agent systems. In particular it defines the notions of agents, (infrastructural) services and the elements necessary to enable Project no: IST /06/03

10 agents to handle multiple message transport systems, agent languages and other components. The Abstract Architecture therefore provides an important blueprint for: o How systems (agents and platforms) deployed in the Agentcities network might be architected and how they might interact o How systems needing to handle multiple reifications might be built. The FIPA2000 set of Agent Management [FIPA00023] and Message Transport [FIPA00067] specifications: defining Agent and Agent platform architectures and interfaces for basic management of agent systems. These standards were adopted directly to develop the first generation Agentcities network deployment and hence many of the important concepts in the specifications influence this architecture: o Definition of management interfaces in terms of standard languages and separate management ontologies. o Asynchronous, message passing style environment o The primary types of domain required: platforms, agents and services also derive from a FIPA style model. DNS [DNS]: defining interfaces and techniques for the development of large-scale (global) directory structures. The DNS specifications were influential in the following way: o Reinforcing the importance of being able to build hierarchical / recursive directory structures. o Reinforcing the utility of explicit domain and subdomain structures instantiated by directories in organising large-scale network systems. Web Services Architecture [WSARCH]: relevant to the model used in this document (see Figure 4: Canonical Network Representation). The Agentcities architecture draws upon the above and aims to describe notions necessary at the network level i.e. how to link autonomous software components (which could be FIPA AA, FIP2000 Agents, Web Services or something else) into coherent clusters to achieve some purpose. While there are differences from the previous models (for example the FIPA AA notion of a service is different) the aim has been to take the level of abstraction of description of linking elements such as agent or service above that used in other specifications to stay orthogonal to them and allow systems described w.r.t. the other frameworks to act as actors within Agentcities networks. Finally, from a structural perspective, the FIPA AA/FIPA 2000 split is also an important prior example of the separation of complex standards into different levels abstraction. Also important have been: Open Grid Services Architecture [OGSA], EbXML Reference Architecture [ebxml] and the RosettaNet RNIF Reference Architecture [ROSETTA]: each of which now includes variations on the following themes: o Message driven (and possibly asynchronous) service interactions o Service components owned by different organisations o Registries and directory service to store and retrieve service meta-data The FIPA Policy working document [FIPA00089]: although not complete to work carried out on domains and policies within FIPA is captured in document. The document describes: o An introduction to the idea and utility of policy driven agent systems. o o A series of policy use-cases. A presentation of operational elements needed to implement policy use (languages, libraries and interpretation mechanisms). In the case of the first set of inspirations the network architecture as it stands has not been proven applicable to these technology sets since no reifications have been developed. However during the development of the architecture there have been efforts to restrict choice as little as possible to make it easier to create such reifications. For the policies area, policy use in the Agentcities Network Architecture is very simple and intentionally orthogonal to the FIPA Policies work: It is used primarily at the system design level and not at run-time by actors in the system. Operationalisation and machine interpretation of policies is not covered (however the assignment of policies to all operational components is intended as a precursor to this). Project no: IST /06/03

11 Domains are explicitly created through directories, providing an anchor point for policy application. Finally the following important standards have been used in the development of reifications, implementations and deployments of various parts of the network HTTP v1.0/1.1: Used throughout current reifications for message transport (context FIPA Agent Message Transport Specifications) XML: used throughout the message transport and message exchange systems (context FIPA Agent Message Transport Specifications and elsewhere) DAML-OIL [DAML-OIL]: Ontologies described in the reification sections are also available encoded in the DAML-OIL Ontology Language Contributions to the State of the Art The Architecture presented here extends the state of the Art in the domain with the following main contributions: The architecture represents the first comprehensive description of how to build large-scale network environments for autonomous service components. As described above many other frameworks provide parts of the puzzle (FIPA Agent and platform architectures, Web Services directory and messaging interfaces, DNS directory structures and so forth) however this description integrates what appear to be the important core concepts and maps them to possible deployment environments. The description abstracts from individual implementation technologies making it in principle extensible via different reifications & instances to different target environments. The architecture captures a live, deployed network environment and is the result of experience gained in a real deployment of a significant scale. Finally it is important to note that the architecture was also developed to integrate with the needs of the other 2 Agentcities Frameworks (see Section 1.1) How to Read this document The current specification parts currently in the architecture are shown below in Figure 1 Component Specifications in this document. Figure 1 Component Specifications in this document. Project no: IST /06/03

12 If you are looking for: Fundamental concepts underpinning the network (including the communication and value creation frameworks) read Part I. A description of service APIs for particular technologies read the specific reification given in Part II. A description of one of the described deployed sets of network services the select the particular description in Part III. o Section 6 describes the original Agentcities network environment using the restricted FIPA 2000 reification that is currently still being used by most network participants. o Section 7 described the second generation decentralised network based on the full reification of the abstract model described in Part I How this document can change The structure by levels and components is intended to allow easy extension of the architecture for future iterations: New Reifications can be added by creating a new Section in Part II (see Section 5). New Instances can be added by creating a new Section in Part III (see Section 8). If the number of these components grows significantly and versioning is required between them the document could easily be split up into its constituent components and different elements versioned separately. Revision of contents (particularly in part I) are welcome but should be through consensus within the testbed community. Project no: IST /06/03

13 2. Abstract Network Architecture Model The Abstract Network Architecture Model defines the main elements found in the network environment and how they relate to one another. The description is structured as follows: Abstractions (Section 2.1): Terms of reference and overview of key elements. Element Definitions (Section 2.2): Definitions of each of the elements. Canonical Network Example (Section 2.3): Example illustrating how network elements relate to one another. A short description of the properties of the network architecture and motivations for choices is given in section Abstractions It is useful to describe systems and architectures in the abstract to allow their details and relationships to be identified without the complexities of implementation. The intention of the abstract network architecture is to describe the various programmatic and data entities in the environment and also describe their function and relationship. We split the design of the abstract network architecture into three compositional layers described in the following sections Core Elements Core elements represent the fundamental entities in the abstract network architecture. Actor: A peer entity in the network that can perform actions and can act as a service provider, service consumer or both. Service: An action performed by a service provider on behalf of a service consumer. Domains: An extensional set of elements that are grouped together in an explicit manner Functional Elements Directories: A set of structured objects (see below) and the Directory Services (actors and services) which control/represent them. A directory instantiates (or creates) a domain through its data contents and the real world elements (actors, objects and so for which the data contents corresponds to). Directory Services: Actors which control descriptions in a directory relevant to a particular domain, using policies to control access to and from a domain Supporting Elements Supporting elements are the statements, definitions or data that are used to define core and structural elements. 2 Structured Objects. Data published in a directory is in the form of structured objects (e.g. XML, RDF, S-Expressions, SOAP XML encoding). The format of those objects can be system dependent (e.g. actor descriptions - white pages, service descriptions - yellow pages) or application dependent (e.g. car descriptions). Collections of structured objects can be searched such that sub-sets of objects with particular features are selected. Actions: A change in the world brought about by an Actor. Policies: A statement of the conditions about interactions that an actor may or may not have. Directory Service Profiles: Details of the capabilities of a directory service. 1 Intensional domains are currently not considered. 2 Note that Contract and Goal are not currently used. Project no: IST /06/03

14 Communication Mechanisms: infrastructural mechanisms which enable interactions between actors in the network. Contracts: A mutually agreed set of rules and conditions, which govern actor interactions. Goals: Explicit or implicit statements of intentions of actors Element Definitions This section defines each of the elements listed in the previous section in more detail. In the current version only core and functional elements are further defined. For the meaning of supporting elements please refer to the definitions given in Section Note that the EBNF descriptions given in this document are abstract, that is, they do not describe concrete syntax like terminal symbols Actors Actors are instantiated as software processes which are able to carry out actions in the network or the world. An actor may have: - Goals. - Structured objects. Furthermore an actor may carry out actions and enter into contracts with other actors Services Services are actions performed by one actor on behalf of another and service descriptions are used to promote or advertise the actions that may be performed. Services may have: - Policies - Structured objects. Furthermore, Services may be the subject of contracts between two or more actors Domains A domain is instantiated by a directory that in turn is supported by one or more directory services and is populated by zero or more data elements. The members of a domain are the entities in the world (data items, objects or actors) which are referenced in the directory Directories A directory is managed by a collection of one or more directory services which work together in the context of an arbitrary organisational structure (peer-to-peer, hierarchy etc.). In particular: A directory can contain other directories A directory is supported by one or more directory services Directories are therefore characterised by two different types of interactions: 1. Client-Directory interactions: in which actors registering, deregistering, and querying the directory interact with directory services representing the directory. They may or may not have any idea about the internals of the directory. 2. Directory directory interactions: in which directory services supporting the directories interact with one another to perform the internal management of the directory (data propagation, federated queries, managing the membership of the directory service group managing the directory). Project no: IST /06/03

15 search Italian restaurants Members Domain Directory Service Top1 Members Directory DS-A, DS-B, Top 1 registers Sun's Gate registers Mama Mia Directory Service DS-A Restaurants Directory Mama Mia, Pasta e Basta Sun's Gate, Red Dragon Directory Service DS-B registers Red Dragon registers Pasta e Basta Restaurants Domain Figure 2: The Restaurants Directory is recursively supported by the Members Directory. The first interaction style (client - directory service) is part of the base for the creation and maintenance of a domain. The second interaction style (directory service directory service) is the base for the creation and maintenance of a directory. As directories can be used to support other directories they are seen as organisational structures. In Figure 2 the directory services DS-A and DS-B in the Restaurants Directory interact with one another in the context of another directory ( Members Directory ) which describes/controls the organisational relationships between the directory services. Given this organisation DS-A and DS-B are then able to jointly provide the Restaurants Directory service. In turn in the context of a domain ( Restaurants Domain ) the directory services provide the desired directory to clients. The Top1 directory service supports the Members Directory, DS-A and DS-B together support the Restaurants Directory Directory Services Directory services are Actors that act as support for one or more directories. The directory service allows actors to register, deregister, modify and search registrations in its repository, such as, actor descriptions, service descriptions, directory service profiles, references to objects etc. Project no: IST /06/03

16 Directory services are policy and domain oriented (see below Figure 3) - a policy can be assigned for each combination of directory name / operation, for example: The tuple members (the directory name) / register (operation name) / child-sibling (policy name). (These are reactive policies.) Polices may be established regarding the number of times per hour data is propagated within the directory, old entries are removed etc. (These are proactive policies.) Policies can also be applied to the default directory named * which matches all directories that don t have a policy explicitly assigned. node policies (directory, operation, name) restos : search : secauth members : register : child members : search : name3 * (default) : register : name4 Directory Service register modify search deregister get-profile. (dot) restos Mama Mia Pasta e Basta member s top-level node policies members : register : child-sibling members : modify : child members : search : default members : deregister : child * : register : default * : modify : default * : search : child-sibling * : deregister : default * : get-profile : default Members: DS-A, DS-B DS-A Members: DS-G DS-B Members: DS-C, DS-D DS-C Members: DS-E, DS-F DS-D DS-E members : register : child members : modify : child members : search : default members : deregister : child * : register : default * : modify : default * : search : default * : deregister : default * : get-profile : default DS-F internal node policies DS-G Figure 3: Directory Services can apply different policies for each operation type / domain name. The topology of the network emerges from different policy combinations at the nodes. Thus the overall behaviour and in particular the topology of the directory (and domain) emerges from the application of different policies by different directory-service nodes. For the next definitions of Actions and Objects we will use a BNF-like notation where: - x? - means that element x can occur 0 or 1 times - x* - means that element x can occur 0 or more times - x+ - means that element x can occur 1 or more times Project no: IST /06/03

17 Actions This section defines the standard actions which can be performed by a directory service. The actions are available to both end-clients (in the case of the Restaurants Directory ) or peer directory service components (in the case of DS-A / DS-B or DS-A / Top1 in the Members Directory ). Note however that any given directory will impose policies on how these actions are carried out by directory services (e.g. registration criteria may be different). register (identity-info, directory-id, directory-token?, structured-object, lease-time) ->okay (directory-id, directory-token, structured-object, lease-time) fail (failure-reason) redirect (directory-service-profile) deregister (identity-info, directory-id, directory-token) -> okay (directory-id, directory-token) fail (failure-reason) modify (identity-info, directory-id, directory-token, structured-object, lease-time) -> okay (directory-id, directory-token, structured-object, lease-time) fail (failure-reason) search (identity-info, directory-id, structured-object, search-constraints) -> okay (set (structured-object)) fail (failure-reason) get-profile (identity-info) -> okay (directory-service-profile) fail (failure-reason) Register The register action causes the directory service to register a structured object entry into a directory for a time period given by the lease-time parameter. If a directory-token is specified when the operation is requested then the directory should try to register the new entry using the key specified in the directory-token. Upon successful registration the directory service returns an ok message containing either a new directory-token or the original directory-token if it was specified by the user together with a lease-time possibly different than the one originally requested (either shorter or longer). If the structured object could not be registered (e.g. due to the fact that the directory didn t supported user specified directory-tokens) the directory service will return a failure message containing the failure reason. The directory-service can also return a redirect message pointing to another directory where the client could try to register its structured object. The detailed semantics of the redirect message are dependent on the policies governing the directory for which the redirect was issued. Deregister The deregister action causes the directory service to de-register a structured object previously registered. The entry containing the structured object is referred trough the respective directory-token. Upon successful de-registration the directory service returns an ok message with a directory token. If the structured object could not be deregistered (e.g. because it was not registered or because it was already de-registered) a failure message containing the failure reason will be returned. Modify The modify action causes the directory service to modify an existing entry of the directory service. The modification can be related to the structured object itself or to parameters of the entry such as the leasetime. Upon successful modification the directory service returns an ok message containing the Project no: IST /06/03

18 directory-token and possibly a new value for the lease-time parameter. If the entry could not be modified the directory service will return a failure message containing the failure reason. Search The search action causes the directory service to search for entries that match a given template specified as a structured-object (possibly by searching in turn other directory services). Upon successfully completing the search request an ok message containing a set of structured objects is returned. If the search request could not be fulfilled a failure message containing a failure reason is returned. Get-Profile The get-profile action is used for requesting meta-information regarding the directory service. Upon successfully completing the request an ok message containing a directory-service-profile object is returned. If the information could not be obtained the directory service will return a failure message containing the failure reason. Objects We will define next the objects used in the action specifications above. Identity-info The identity-info element is to be used for providing identification information regarding the invoker of a given operation in the form of an actor-identifier. This object can contain also a structured object providing credentials information that can be relevant to some form of authentication (e.g. a password, a X.509 certificate or some more sophisticated session key). identity-info ::= actor-identifier credentials? Directory-id The directory-id is a string that uniquely identifies a directory in the frame of a given directory service. It can include the names of other directories if the Directory Service uses a path like scheme for identifying nested directories. Directory Token A directory-token refers to an entry registered within the directory and can be used to identify the registration entry for subsequent deregister and modify actions. Some Directory Services might allow for user-specified directory tokens to be used in the register action. A directory-token contains a key (string) that uniquely identifies a particular entry in a given directory. The directory service usually generates these keys but some directories may support the registration of entries under keys specified by the client of the directory service. directory-token ::= key Structured Object Project no: IST /06/03

19 structured-object(s) are the data elements stored in the directory which are subsequently available for search. The only assumption about structured objects is that they have a frame-like structure similar to RDF, the SOAP XML encoding or FIPA SL0. There are no restrictions on the content of the data of the structured objects. Individual directories or directory services are likely to specifically restrict the form of structured objects they can accept. Lease-time lease-time(s) can be specified for the register and modify operations. They can be in absolute or relative date/time format. Robust servers should be able to deal with both forms. Servers and clients should prefer the relative form due to the fact that absolute form must assume that clocks in the network are synchronized which is not usually the case. The actual representation of this datatype is specific to each reification. Search constraints search-constraints can be specified as an argument to the search actions. This construct can specify a max-time (date/time), max-depth (integer), max-results (integer) and a query-id (string). search-constraints ::= max-time? max-depth? max-results? query-id The max-time specifies a deadline by which the constrained search should return the results. If it is in relative time format then nodes might decrement it with an estimate of the duration of subsequent searches of child nodes. If it is not specified then this constraint is to be considered the default unbounded or a given value if the directory has a policy regulating this. It also indirectly defines the time to live of a query in the network. The max-depth the maximum depth of propagation of the search to federated directories. When forwarding a query to other directory services this value is decremented by 1. If the value is negative or not specified then this constraint is considered to be the default unbounded or a given value if the directory has a policy regulating this. If the value is 0 the directory service MUST not forward the query anymore. The max-results element specifies the maximum number of results to be returned. When returning results the directory service should not return more than the max-results value. Some directory services MAY decrement this value by the number of local results when forwarding queries. If the value is negative or not specified then this constraint is considered to be the default unbounded or a given value if the directory has a policy regulating this. If the value is 0 then the directory service should not return any more results. Query-id The query-id element specifies a tag that should be unique at the creator of the query. Any directory service forwarding the query MUST not modify this value. Directory services should keep track of the query-ids of received and forwarded queries for a time of max-time. If during this time a query with the same query-id is received it MUST be discarded. Property A property contains a symbolic name and possibly a value as a structured object. It is used for describing directory/policy specific features of directory-description(s) (e.g. access rights, etc.) and directory-service-profile(s) (e.g. node performance metrics, number of children directory-services etc). Project no: IST /06/03

20 property ::= property-name property-value? Directory-description A directory-description is an extended structured-object that specifies information regarding a given directory like the name, the directory service(s) that support this directory and zero or more specific properties of the directory. If not specified the supporting directory-service is implicitly the current directory-service. If the directory is supported by other directory-services then this is specified trough the supporting-directory field that contains a directory-description. In turn the referred directory must contain a collection of directory-service-profiles. It has to be noted that for defining directories a form of recursivity exists but this applies only to supporting directories (directories of directory-serviceprofiles). structured-object directory-description ::= directory-description ::= directory-name supporting-directory? property* Directory-Service-profile The directory-service-profile specifies information like the name of the directory, the operations of the directory service interface, the policies governing the operation of the directory, optionally a summary of the content that this directory service is responsible for (content that can be local or can possibly be distributed at other directory-services) and zero or more specific properties. directory-service-profile directory-service-interface directory-service-policies directory-service-policy directory-service-summary ::= directory-service-actor-id directory-service-interface directory-service-policies directory-service-summary? property* ::= register-action? deregister-action? modify-action? search-action? get-profile-action? ::= directory-service-policy+ ::= directory-id operation-id policy-id ::= structured-object+ Policies can be applied for any combination of directory-id and operation-id. Default policies (that apply to all directories names for which no other policies exists) are specified by using the wildcard directory-id *. Default policies which apply to all operations in one directory (including proactive policies) are specified using a * in the operation-id field. The directory-service-summary contains a summary of the content that the current directory-service is responsible for. The format, the way of generating this summary and the semantics of the data are closely related with the policies governing the directory. Project no: IST /06/03

21 Some of the entries in the directory might be of the directory type (the equivalent of the directoryprofile described in the abstract section). A directory entry contains a slot specifying it s name and if the directory is supported by another directory it contains also the name of the supporting directory. directory ::= directory-name directory? Communication Mechanisms Communication mechanisms in the network are necessary to enable interaction between actors, including those acting as: Directory service clients (interacting with directory services) Directory Services (interacting with other directory services) Service providers (interacting with service consumers) A particular network may use several different communication mechanisms but will in general need to specify at least one which communication mechanisms can be used to access core network services such as directory services. Particular communication mechanisms may be specified in domain or directory service policies Specific Domains A number of specific domains are very useful in most reifications of the network architecture. Root Domains These domains can be used as a starting point when browsing the content of a directory service. Actor Domains Used to find descriptions of Actors in the Environment. In this case the structured object is specialized to be an actor description. structured-object ::= actor-description Service Domains Used to find descriptions of Services provided by Actors in the environment. In this case the structured object is specialized to be a service description. structured-object ::= service-description Directory Service Domains Used to find descriptions of Directory Services. In this case the structured object is specialized to be a directory service profile: structured-object ::= directory-service-profile 2.3. Canonical Network Example Figure 4: Canonical Network Representation shows a simple network environment described in terms of the definitions made in the previous sections. It is important to not in particular how the various elements involved relate to one another: Actors provide services to one another Actors and other referencable entities are grouped into domains Project no: IST /06/03

22 Domains are instantiated by directories Directories themselves are supported by actors providing directory services The constructions of directories is recursive with directory services themselves using a directory structure to organise the collaborations Communication occurs via one or more communication mechanisms which enable actors to access the interfaces of others. Actor interactions (including directory services) can be governed by polices and contracts. Actors A, B members of Domain X Actor, Service DS1 member of Domain X Actor S not member of Domain X register Domain X register Directory Service DS1 Directory X query DS1 supports Directory X Directory X supports Directory Y Actor / Service Level Directory Y Structured Object b Directory = X Structured Object a Directory = X Directory Content Information Level Actor Domain Directory Service Directory Structured Object Directory Content Figure 4: Canonical Network Representation 2.4. Network Architecture Properties The network architecture as described here has the following important properties: In principle the roles defined within it can be filled by actors defined in different technical frameworks (e.g. FIPA Abstract Architecture, FIPA2000, Web Services components, JXTA peers etc.) but the common references of their relationships in the network should be retained. The core network services are described in terms of the notions of actors and services meaning that they could also be implemented using different technological components. The domain and directory structures provide a flexible mechanism for generating and maintaining dynamic references to actors and entities in the world. It should therefore be possible to use them to construct services such as: o Naming services for actors o o Service advertisement mechanisms Referencing systems for communication resources such as ontologies, object instances or even real world objects (e.g. services holding vehicle registration data). Project no: IST /06/03

23 The domain and directory structures are recursive allowing directories to be constructed from other directories. Actor interactions and particular directories and domains are policy driven making explicit the assumptions underlying the behaviour of each of the systems and in principle allowing a wide range of network instances to be specified on the basis of this abstract description. Weaknesses in the current model include: More instantiations to other technologies are needed before the claims of utility in heterogeneous technology environments can be validated. All notions of domain are currently predicted on explicit listings in directories (they are extensional) however applications may often need to reference members of intesional domains ( all things blue, all numbers greater than 35 ) which may not be explicitly represented (or indeed explicitly representable). While policies have been used in parts II and III of the document to articulate the behaviour of certain services no formal language has been adopted hence it remains to be validated if policies can eventually be articulated and used in a machine processable way for the requirements defined here. Important contributions here could come from adoption of models from the FIPA Policies Specification [FIPA00089] Future Developments This section lists a number of possible future additions and issues related to the network architecture. (Please note that this list should in no way be considered complete!) Possible additions: - Cursors and result sets clients should be able to pull the results of a search query in given chunks not only in one single bundle. This would be especially useful for queries that could have large number of results. - Batch operations due to efficiency reasons the directory should be able to perform the same operation (e.g. registration, modify, deregister) for large number of entries. It is anticipated that this might be particularly useful for clients that have to maintain large numbers or entries and as such need to do periodically perform re-leasing modify operations. - Redirect in modify modify operations should also support redirect responses. The current version doesn t support this since the semantics of such operations in a dynamic environment are much more complex. - Rich query languages including and/or/not operators and possibly other predicates. - Other specific domains for ontologies, interaction protocols, content languages, service types. Moreover we are considering the development of a number of additional services trough a separate process (e.g. a Network Services document): - Subscription service - actors could express their interest to be notified when DirectoryDescriptions matching a particular query are registered, modified or deregistered from the directory. - Indexing service - the content of particular DirectoryService structure could be indexed by a third party services in order to speed-up search query time. - Time service - a good number of application services rely on the fact that computers in the network have synchronized time. Time protocols exists for UNIX systems but due to the heterogeneous nature of the current network and to connectivity issues (e.g. firewalls) there is a potential need for a network specific protocol. Project no: IST /06/03

24 PART II: REIFICATIONS 3. FIPA2000 Reification This reification maps the abstract model presented in Part I of this document into an environment populated by FIPA Agents and uses only the currently specified FIPA 2000 Agent Management Components and Ontologies. The objective of the mapping is to provide a network description useful for an environment in which only current FIPA platform implemented interfaces are available. The mapping is restricted from the Abstract model and is not exact in places since the FIPA2000 interfaces do not provide all the features envisaged in the abstract model Actors Actors are FIPA2000 FIPA Agents as defined in the FIPA Agent Management Specification [FIPA00023] Services Services are actions carried out by FIPA agents on behalf of one another Domains This model defines interfaces and data models for three specific types of domains: - Agent Domains (mapping from Actor Domains) using AMSAgentDescriptions. - Service Domains (mapping from Service Domains) using DFAgentDescriptions. - Platform Domains (mapping from Directory Service Domains) using APDescriptions These domains are created by a number of directories each represented by a number of directory services implementing interfaces defined in the next section and using one of the appropriate datamodels defined in Section Each of the datamodels refered to above is defined in [FIPA00023] Directories Directories are made of one or more directory services implementing the interfaces defined in Section Directory Services The directory services available are: Agent Directory (for the Agent Domain) using FIPA AMS components. Service Directory (for the Service Domain) using FIPA DF components. Platform Directories (for the Platforms Domain) using either dedicated platform directory components or the FIPA-AMS platform information facility [FIPA00023]. In this section directory descriptions are given for the Agent and Service directories only (on the basis of the FIPA-AMS and FIPA-DF). It is assumed that other directories in the environment will take the same form as the FIPA-DF in terms of actions and interactions although likely modifying the data model Protocols In this Directory Structure, Each DS must support following protocols for its interaction with end user and the other child DS. Register action: FIPA Request Interaction Protocol Project no: IST /06/03