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
Top Related