1. FIPA Abstract Architecture London FIPA meeting January 24-29, 2000 from: TC-A members

2. Overview b Introduction b Describe the architecture b Interoperability b Next steps

3. 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

4. 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

5. Mapping Abstract to Concrete b Abstract architecture moves to realized implementations

6. Abstract to Concrete b Whole set or one element b Promote reusability b 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 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

9. 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

10. 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

11. FIPA Abstract Architecture b Agents and directory b Message & Message Encoding b Transport b Platforms & Services b Interoperability

12. 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

13. Agents & directory

14. 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

15. 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

16. 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

17. Message Transformation

18. 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

19. 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

20. Multiple Transports

21. 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

22. 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

23. 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

24. 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

25. Gateways b Can be standalone, or part of other elements in system b Can be addressable or “hidden”

26. Interoperability b As realizations of the architecture occur, need to create interoperability profiles: what can the system interoperate with under what conditions

27. 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

28. 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