Fipa abstract Architecture Specification

6Evolution of the architecture

For this reason it is recommended that new architectural elements be introduced only after they have been the subjects of substantial practical experience. When in doubt, new elements should be proposed as optional elements, and restricted to mutually consenting platform implementations. New properties and relationships for existing architectural elements must be introduced in a backward-compatible fashion; specifically, the change must support (and require) that all concrete implementations can incorporate the change in a backward compatible manner.

Much of our understanding about how to extend the FIPA architecture will depend on the use of experimental systems. It is useful to be able to deploy and test such systems without breaking “production” systems based on FIPA standard specifications. FIPA may elect to define specific ontologies or extend existing architectural elements in order to support experimental features in a well-behaved fashion. (A parallel may be drawn with the use of RFC-822 email systems, in which experimental elements may be introduced provided that they use names that begin “X-“.)

One of the challenges involved in creating the current set of abstractions is drawing the line between elements that belong in the abstract architecture and those which belong in concrete instantiations of the architecture. As FIPA creates several concrete specifications, and explores the mechanisms required to properly manage interoperation of these implementations, some features of the concrete architectures may be abstracted and incorporated in the FIPA abstract architecture. Likewise, certain abstract architectural elements may eventually be dropped from the abstract architecture, but may continue to exist in the form of concrete realizations.

The current placement of various elements as mandatory or optional, as well as actual or explanatory, is somewhat tentative. It is possible that some elements that are currently optional will, upon further experience in the development of the architecture become mandatory. Likewise, explanatory elements may be introduced in order to clarify the architecture, and may over time be reclassified as realized.

7Appendix A: Goals of message transport abstractions

7.1Scope

7.2Variety of transports

There is a wide variety of transport services that may be used to convey a message from one agent to another. The abstract architecture is neutral with respect to this variety. For any instantiation of the architecture, one must specify the set of transports that are supported, how new transports are added, and how interoperability is to be achieved. It is permissible for a particular concrete architecture to require that implementations of that architecture must support particular transports.

Different transports use a variety of different address representations. Instantiations of the message transport architecture may support mechanisms for validating addresses, and for selecting appropriate transport services based upon the form of address used. It is extremely undesirable for an agent to be required to parse, decode, or otherwise rely upon the format of an address.

The following are examples of transport services that may be used to instantiate this abstract architecture:

• 
  Enterprise message systems such as those from IBM and Tibco
  
• 
  A Java Messaging System (JMS) service provider, such as Fiorano
  
• 
  CORBA IIOP used as a simple byte stream
  
• 
  Remote method invocation, using Java RMI or a CORBA-based interface
  
• 
  SMTP email using MIME encoding
  
• 
  XML over HTTP
  
• 
  Wireless Access Protocol
  
• 
  Microsoft Named Pipes
  

7.3Support for alternative transports within a single system

Many application programming environments offer developers a variety of network protocols and higher-level constructs from which to implement inter-process communications, and it is becoming increasingly common for services to be made available over several different communications frameworks. It is expected that some instantiations of the FIPA architecture will allow the developer or deployer of agent systems to advertise the availability of their services over more than one message transport.

For this reason, the notion of transport address is here generalized to that of destination. A destination is an object containing one or more transport addresses. Each address is represented in a format that describes (explicitly or implicitly) the set of transports for which it is usable. (The precise mapping from address to transport is left to the concrete specification, although in practice the mapping is likely to be one-to-one.)

In its simplest form, a destination may be a single address that unambiguously defines the transport for which it can be used.

Download 250.15 Kb.

Share with your friends: