« links for 2007-01-16 | Main | links for 2007-01-18 »

FIPA Abstract Architecture

Who are FIPA?

FIPA are the Foundation for Intelligent Physical Agents; a vendor consortium to define architecture and standards for software agents. FIPA has strong links with the OMG and there is some cross-fertilization with the W3C via the latter's Web Ontology program. So as to avoid the black hole of asking what is an agent, you can replace the word "agent" with "service", and this should give you a good idea of FIPA's relevance: think of agents as being consumers and producers of services.

FIPA Architecture

The key FIPA document of interest in is the Abstract Architecture (AA). This document describes basic infrastructure and plumbing required to enable agent communications. The architecture is remarkably similar to what is commonly called a Web Services stack (WS). FIPA has been working with this architecture for about 9 years.

There are numerous implementations of the AA, most of which are in Java. It's fair to say the FIPA were late to notice the similarities between Web Services (WS) and the AA. For whatever reasons, FIPA has not decided to publicize or orient its efforts with respect to web services infrastructure.

The main differences between FIPA AA and the WS "stack" are 1) the level of abstraction (the AA is more abstract), in that FIPA does not mandate specific technologies such as XML or specific standards such as WSDL and SOAP, 2) FIPA assumes the message payload to be a well structured and well understood item, based on what are called communicative acts (messages that are designed to have an effect on the receiver) and very probably grounded using shared ontologies, 3) FIPA does not have the concept of a procedure call, the only things sent between agents are messages, 4) FIPA have a full understanding of the requirements for a services oriented infrastructure thanks largely to its history with the OMG while the WS community is still working through the issues via XML based standards and extensions to both container managed platform middleware such as J2EE and Web based architectures (such as Apache Axis), often under the label of 'SOA'.

FIPA Enveloping

A key architectural component in the AA is the agent message and the methods whereby that message is enveloped for transport using arbitrary protocols and networks. I'd encourage anyone to look at how the AA enveloping model works, noting the following:

  • There is an architectural distinction between a message and a transport-message. This disinction derives from the separation of agents and transports. Messages are transformed into payloads that are suitable for insertion into a transport-message. The transport treats the payload as opaque both semantically and structurally. By way of comparison, SOAP is also semantically opaque, however SOAP requires that message content be well formed XML element content since payloads are physically nested, ie SOAP payloads are not structurally opaque. AA transport-message serializations for the web have tended to use multipart-mime to achieve structural opacity (much like using SOAP+attachments in favour of vanilla SOA.
  • There is a clear separation between the names of senders and receivers and their addresses. Agents only require names to send messages. Gateways and transports do not require names to manage message delivery and routing. The binding between names and addresses is acheived via an object called a Locator, which are designed to be accessible via directory services such as X500, LDAP or JNDI.
  • Both messages and transport-messages are based on dictionaries of well known keys with assscociated values, or in AA parlance "Key Value Tuples" (KVT). This makes both elements extensible; there are a minimal conformance levels required for interoperable messaging (read: you have to populate a certain number of headers to interoperate).
  • Indeed, almost ever architectural element of the AA is a KVT; the AA is entirely compositional and does not make use of subclassing or inheritence mechanisms. FIPA do specify keys and their meaning under the namespace "org.fipa.*".
  • The AA messaging elements don't specify semantics for routing or orchestration.

Why didn't this catch on?

It's not spurious to claim that the AA is the most mature (though not widely used) expression of a distributed services oriented architecture available today, particularly in its notion of what the core platform services are. You could take the AA, ground it in WS standards and have a well-structured platform that will be remain reasonably future proof as WS standards evolve.

FIPA AA perhaps did not catch on as a basis for either WS or SOA for a number of reasons. First, it's is lumbered with the notion of intelligent agents (IA), which fell out of favor post the dotcom bubble. Second, it is a very ambitious standard set and arguably required or assumed too much by way of deployed infrastructure (a case of running before you could walk). Third it carried over considerable baggage from distributed object technology (notably CORBA), that makes over-internet networking difficult. Fourth it might have been too abstract, and introduced too many options especially in terms of on the wire protocols and concrete syntax (even WS pragmatically fixed on a concrete syntax with SOAP). Fifth, the programming model for dealing with application message semantics is very different from the 'business logic' most commercial middleware developers are familiar with.

It's interesting to note that IA terminology is creeping back into the ESB and SOA parlance, typically where either services of clients or services are ocassionally called 'agents', or where the need for application level interop driven by shared message semantics or ontologies is considered important. It's more likely here that 'agency' happens to be a natural way for engineers to talk about SOA/ESB, rather than a sudden rediscovery of a decade's worth of IA research and development. Talking in terms of 'services' is arguably largely done for the benefit of non-technical stakeholders.


January 17, 2007 10:27 PM

Comments

Post a comment

(you may use HTML tags for style)




Remember Me?

Trackback Pings

TrackBack URL for this entry:
http://www.dehora.net/mt/mt-tb.cgi/2025