FIPA Abstract Architecture

1
FIPA Abstract Architecture

• London FIPA meeting
• January 24-29, 2000
• from TC-A members

2
Overview

• Introduction
• Describe the architecture
• Interoperability
• Next steps

3
Goals of abstract architecture

• Provide end-to-end message interoperability
• Where there may be heterogeneous systems
• Describe common elements and relationships
• Do this without linking to a particular
  implementation

4
Other Goals

• Model work on common distributed computing
  systems
• Java, CORBA
• Facilitate re-use of existing systems
• Previous FIPA work, existing directory,
  management, transport and security systems
• For info on Goals, see Appendix A- D of the
  Architecture Document

5
Mapping Abstract to Concrete

• Abstract architecture moves to realized
  implementations

6
Abstract to Concrete

• Whole set or one element
• Promote reusability
• Add elements needed to for that particular
  concrete version

7
Abstracting one element

• A concrete version of directory services shared
  by several implementations

8
Mandatory and Optional

• If an element is mandatory at the abstract level,
  it must be included at the concrete level
• If an element is optional at the abstract level,
  it can be mandatory at the concrete level
• At the concrete level, the authors can add new
  mandatory and optional elements

9
Abstract architecture cant do it all!

• Some things cannot be modeled abstractly
• Management and Lifecycle
• Much of security
• Mobility
• Some things need more work
• Gateways, domains and policy
• Conversation policy

10
Relationship to current FIPA specs

• Very close to FIPA 99 work
• Some differences with FIPA 97 work - see doc for
  details
• Doesnt cover the application domain specs

11
FIPA Abstract Architecture

• Agents and directory
• Message Message Encoding
• Transport
• Platforms Services
• Interoperability

12
Agents directory

• Agents have agent-directory-entries
• Agent-directory-entries registered with
  directory-services
• Agent descriptions include
• Agent-name
• Locator (contains transport info)
• Agent-attributes
• Search directory-services for interesting agents

13
Agents directory
14
Key differences

• Agent-name separated from addressing
• Gives us transport independence
• Directory service
• Simpler than current FIPA model - suggest that
  there are two types
• Quick lookup
• Extensive search

15
FIPA-Message

• Expressed in Agent Communication Language
• Has content
• Content is expressed in a content language, may
  reference ontologies
• Very similar to existing models

16
Message Encoding

• Encoding of a message happens at several levels
• Message content
• FIPA-message
• Transport-level
• FIPA-messages are transformed to
  transport-message prior to transport
• FIPA-messages can contain FIPA-messages

17
Message Transformation
18
Message Transform

• Within FIPA-message, sender receiver are always
  agent-names
• FIPA-messages can be transformed to transport
  appropriate representations
• Envelope can have transport-descriptions and
  other attributes
• Message authentication and encryption can be
  handled this way

19
Transport

• Assume agents can be communicated w/ using
  multiple transports
• Transport-description holds transport info
• Locator can hold multiple transport descriptions
• Locator is part of agent-description in the
  directory-service

20
Multiple Transports
21
Transport Description

• Transport-description contains
• Transport-type SMTP, IIOP, HTTP, etc.
• Transport-specific-address
• Transport-specific-properties
• FIPA will maintain a standard set of these, but
  they can be extended

22
Key Differences

• Transport address is separated from agent-name
• Message-transport-service is optional, not
  mandatory
• Extensible model for expanding transports,
  transport properties
• Though most systems will probably implement it

23
Platforms and Services

• Agent-platform is a collection of services
• Agent-Platform is optional, not mandatory
• Basic services
• Directory-service
• Message-transport-service
• Though most systems will probably implement it

24
Interoperability

• Details still in discussion
• Basic model is via gateways
• Gateways can do logical transforms
• From one representation to another
• Java objects -gt IDL
• XML -gt tag/string
• Gateways can do transport transforms

25
Gateways

• Can be standalone, or part of other elements in
  system
• Can be addressable or hidden

26
Interoperability

• As realizations of the architecture occur, need
  to create interoperability profiles
• what can the system interoperate with
• under what conditions

27
Next Steps

• Review of Abstract Architecture
• Incorporate comments
• Go to draft status
• Add gateway work
• Write Interoperability Guidelines
• Write workplans for concrete instantiations

28
Summary

• Abstract architecture designed for end to end
  messaging interoperability
• Compatible with FIPA 99 work
• Must be mapped to concrete specifications
• Concrete specification will contain elements that
  could not be modeled abstractly
• Ready to start creating concrete specifications