FIPA Abstract Architecture London FIPA meeting January 24-29, 2000 from: TC-A members
Overview b Introduction b Describe the architecture b Interoperability b Next steps
Goals of abstract architecture b Provide end-to-end message interoperability Where there may be heterogeneous systems b Describe common elements and relationships b Do this without linking to a particular implementation
Other Goals b Model work on common distributed computing systems Java, CORBA b Facilitate re-use of existing systems Previous FIPA work, existing directory, management, transport and security systems b For info on Goals, see Appendix A- D of the Architecture Document
Mapping Abstract to Concrete b Abstract architecture moves to realized implementations
Abstract to Concrete b Whole set or one element b Promote reusability b Add elements needed to for that particular concrete version
Abstracting one element A concrete version of directory services shared by several implementations
Mandatory and Optional b If an element is mandatory at the abstract level, it must be included at the concrete level b If an element is optional at the abstract level, it can be mandatory at the concrete level b At the concrete level, the authors can add new mandatory and optional elements
Abstract architecture can’t do it all! b Some things cannot be modeled abstractly Management and Lifecycle Much of security Mobility b Some things need more work Gateways, domains and policy Conversation policy
Relationship to current FIPA specs b Very close to FIPA 99 work b Some differences with FIPA 97 work - see doc for details b Doesn’t cover the application domain specs
FIPA Abstract Architecture b Agents and directory b Message & Message Encoding b Transport b Platforms & Services b Interoperability
Agents & directory b Agents have agent-directory-entries b Agent-directory-entries registered with directory-services b Agent descriptions include Agent-name Locator (contains transport info) Agent-attributes b Search directory-services for interesting agents
Agents & directory
Key differences b Agent-name separated from addressing Gives us transport independence b Directory service Simpler than current FIPA model - suggest that there are two types Quick lookup Extensive search
FIPA-Message b Expressed in Agent Communication Language b Has content b Content is expressed in a content language, may reference ontologies b Very similar to existing models
Message Encoding b Encoding of a message happens at several levels Message content FIPA-message Transport-level b FIPA-messages are transformed to transport-message prior to transport b FIPA-messages can contain FIPA- messages
Message Transformation
Message Transform b Within FIPA-message, sender & receiver are always agent-names b FIPA-messages can be transformed to transport appropriate representations b Envelope can have transport-descriptions and other attributes Message authentication and encryption can be handled this way
Transport b Assume agents can be communicated w/ using multiple transports b Transport-description holds transport info Locator can hold multiple transport descriptions Locator is part of agent-description in the directory-service
Multiple Transports
Transport Description b Transport-description contains Transport-type: SMTP, IIOP, HTTP, etc. Transport-specific-address Transport-specific-properties b FIPA will maintain a standard set of these, but they can be extended
Key Differences b Transport address is separated from agent-name b Message-transport-service* is optional, not mandatory b Extensible model for expanding transports, transport properties * Though most systems will probably implement it
Platforms and Services b Agent-platform is a collection of services b Agent-Platform is optional, not mandatory* b Basic services Directory-service Message-transport-service * Though most systems will probably implement it
Interoperability b Details still in discussion b Basic model is via gateways b Gateways can do logical transforms From one representation to another Java objects -> IDL XML -> tag/string b Gateways can do transport transforms
Gateways b Can be standalone, or part of other elements in system b Can be addressable or “hidden”
Interoperability b As realizations of the architecture occur, need to create interoperability profiles: what can the system interoperate with under what conditions
Next Steps b Review of Abstract Architecture Incorporate comments Go to draft status b Add gateway work b Write Interoperability Guidelines b Write workplans for concrete instantiations
Summary b Abstract architecture designed for end to end messaging interoperability Compatible with FIPA 99 work b Must be mapped to concrete specifications Concrete specification will contain elements that could not be modeled abstractly b Ready to start creating concrete specifications