FIPA Abstract FIPA Abstract ArchitectureArchitecture

London FIPA meeting

January 24-29, 2000

from: TC-A members

OverviewOverview Introduction Describe the architecture Interoperability Next steps

Goals of abstract Goals of abstract architecturearchitecture

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

Other GoalsOther 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

Mapping Abstract to Mapping Abstract to ConcreteConcrete

Abstract architecture moves to realized implementations

Concrete reification: CORBA Elements

Messaging ACLDirectory

Abstract Architecture

Messaging ACLDirectory

Concrete reification: Java Elements

Messaging ACLDirectory

Abstract to ConcreteAbstract to Concrete Whole set or one element Promote reusability Add elements needed to for that

particular concrete version

Abstracting one elementAbstracting one elementA concrete version of

directory services shared by several implementations

Mandatory and OptionalMandatory 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

Abstract architecture Abstract architecture can’t do it all!can’t 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

Relationship to current Relationship to current FIPA specsFIPA specs

Very close to FIPA 99 work Some differences with FIPA 97 work -

see doc for details Doesn’t cover the application domain

specs

FIPA Abstract FIPA Abstract ArchitectureArchitecture

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

Agents & directoryAgents & 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

Agents & directoryAgents & directory

Key differencesKey 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

FIPA-MessageFIPA-Message Expressed in Agent Communication

Language Has content Content is expressed in a content

language, may reference ontologies Very similar to existing models

Message EncodingMessage 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

Message TransformationMessage Transformation

Message TransformMessage 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

TransportTransport 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

Multiple TransportsMultiple Transports

Transport DescriptionTransport 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

Key DifferencesKey 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

Platforms and ServicesPlatforms 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

InteroperabilityInteroperability Details still in discussion Basic model is via gateways Gateways can do logical transforms

• From one representation to another• Java objects -> IDL• XML -> tag/string

Gateways can do transport transforms

GatewaysGateways Can be standalone, or part of other

elements in system Can be addressable or “hidden”

InteroperabilityInteroperability As realizations of the architecture occur,

need to create interoperability profiles:• what can the system interoperate with• under what conditions

Next StepsNext Steps Review of Abstract Architecture

• Incorporate comments• Go to draft status

Add gateway work Write Interoperability Guidelines Write workplans for concrete

instantiations

SummarySummary 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