RFC 2552
Architecture for the Information Brokerage in the ACTS Project GAIA
RFC 2552: Architecture for Information Brokerage in the ACTS Project GAIA 📚✨
(part 1 of 6)
Okay bestie, this RFC is the GAIA architecture doc, and it's from April 1999 🌸. It's written by M. Blinov, M. Bessonov, and C. Clissmann, all from Teltec UCD-CS in Ireland 🇮🇪. It's labelled Informational, which means it's sharing ideas, not setting a standard. The title block doesn't list anything it obsoletes or updates, so it's a standalone vibe 💅.
Status of this Memo 📝
This one's just here to inform the Internet community 🫶. It is not a standard of any kind, and you can share it as much as you want, because distribution is unlimited 🦋.
Copyright Notice ©️
The copyright line reads Copyright (C) The Internet Society (1999). All Rights Reserved. Lawyers are gonna love it 💜.
Abstract 🌈
This memo introduces a generic architecture for information brokerage that works for any domain and any supplier, no matter who's selling what 💖. It was designed as part of the ACTS project GAIA, which stands for Generic Architecture for Information Availability 🧚.
1. Introduction ✨
Okay so, today there are so many goods and services on the electronic market, and the number of suppliers keeps going up and up 📈. But ngl, there's still no efficient way for a customer to find the product or information they want, or the supplier who can actually provide it 😭. Customers and suppliers literally can't keep up with how much information is out there on their own 💀. On top of that, all the different protocols, formats, and underlying networks are super heterogeneous, which slows down the whole electronic market 🙈.
So the answer is brokerage systems! 🎀 These work as middlepeople between customers and content suppliers. They help the customer through the trading process and hide all the messy distribution and heterogeneity of information from them 🫶. Designing a domain and supplier independent generic architecture for these brokerage systems is the goal of the GAIA project (Generic Architecture for Information Availability) 🔥. GAIA got part funding from the EU ACTS programme for Research and Technological Development 💜.
The GAIA brokerage system lets a customer do four things 👑:
- search for a particular "product" (information, content or services) that they're interested in
- locate the product, i.e. find supplier(s) from whom the product is available
- order the product from the supplier
- receive delivery of the product by digital means
All of these actions are carried out by the broker when the customer asks for them 🧚. The customer reaches broker services through one unified user interface, and the customer's system doesn't have to support every protocol involved in the trading process. Main character energy for the customer, no cap 💅.
The full specification of the GAIA Architecture is in the GAIA Standard [1] 📖. That standard covers the GAIA Reference Model, GAIA Functional Architecture, GAIA Standard Profiles, and the specification of the GAIA interfaces 🌸.
This memo doesn't try to copy the whole GAIA Standard. It just explains the basic ideas and concepts 🦋.
The structure of this memo follows the structure of the GAIA Standard, so here's the breakdown 🍓:
- The GAIA Reference Model provides a common basis for the description and specification of brokerage systems, including the GAIA system.
- The GAIA Functional Architecture defines functional elements of the GAIA Broker, their roles and relationships.
- The GAIA Brokerage System Interfaces describes internal and external interfaces of the GAIA brokerage system.
- The GAIA Standard Profiles specifies mandatory and optional profiles to which brokerage systems may conform.
2. The GAIA Reference Model 🧠
The GAIA Reference Model is the big-picture map 🗺️. It outlines the operations and actors involved in finding, ordering, and delivering physical and digital objects and services (which it calls "Products") in a global brokered distributed information environment ✨. It shows the overall GAIA environment and how its components are related to each other 💖. Any further standards work on individual GAIA components uses this model and its terminology 🫶.
The GAIA environment is basically a bunch of actors and functions teaming up to handle discovery, ordering, and delivery of information and services 🤝. The actors play roles in the procedure, including starting and running the Actions that together make up the whole transaction 💅. The GAIA architecture gives a standardised and widely applicable framework for brokered search and retrieve applications in a large-scale networked environment 🌈.
2.1. GAIA Roles 👑
The GAIA model has three main roles that actors can play: the Customer, the Broker, and the Supplier 💜. These roles are shown in Figure 1 below 🦋. There's also a whole other class of active entities that play supporting roles in the Actions. That class is called GAIA "Helpers", and it includes things like authentication and payment 🔐. The actors are organisations and individuals in the supply chain, and every GAIA actor plays at least one role at any given time 🫶.
2.1.1. The Customer 🛍️
The Customer wants to get some Products, or information about some Products 💖. The Customer role kicks off the GAIA transaction by requesting one or more GAIA Actions, and then the Customer gets the results 🎀. The Customer can deal with actors playing either of the other two roles, the Broker or the Supplier 🌸. And those actors can also play the Customer role themselves while asking other Brokers for more services 🔄.
2.1.2. The Broker 🤝
The Broker gives brokerage services to both the Customer and the Supplier 💅. It answers the Customer's requests for Products, or for information about Products ✨. The Products a Broker hands to the Customer can come from one or more Suppliers and/or Brokers 🧚. The Broker's main job is to collect and collate information from lots of different Suppliers and pass it along to the Customer, so the Customer never has to deal with a pile of Suppliers themselves 🙌. A Broker can also act on a Supplier's behalf by spreading the word about the Products that are available 📣. The actor playing the Broker can be a Supplier to a Customer or another Broker at the same time 🦋. And the Broker can play the Customer role while it's talking to another Broker or a Supplier 🔁.
2.1.3. The Supplier 📦
The Supplier is where the Product comes from 🌟. The Supplier gives the Broker information about the Product it can supply 💜. The Supplier can send its Product straight to the Customer, or to the Broker so the Broker can forward it to the Customer 🚚. An actor playing the Supplier role can also play the Broker role 🫶. A Supplier might deal with a large number of Brokers and Customers across a bunch of GAIA transactions 🌈.
2.1.4. Helpers 🧚
A Helper is an application layer entity that plays a supporting role in a GAIA transaction 🛠️. Helpers provide a service the supply chain needs, but that sits outside the core functionality of the Broker 💖. Examples include a global directory service, a payment service, or an authentication service 📒.
The authentication Helper is all about making it possible for one actor to authenticate another 🔐. The payment Helper is all about supporting a payment mechanism from one actor to another 💸.
In any given GAIA transaction there will be one or more Customers (usually just one), one or more Brokers, and one or more Suppliers 👯. The Customer gives the Broker a description of the Product they're looking for ✍️. The Broker might bring in other Brokers to help search for the Product 🔍. When the Broker finds a Supplier of the Product, that info goes into the Broker's response to the Customer 🎯. And during an Action, the Broker might need to call on one or more Helpers 🫶.
2.2. GAIA Actions 🎬
Each GAIA transaction is made up of one or more Actions 💜. These Actions are the Customer's requests to the Broker or the Supplier to carry out some operation and send back a response 📨. Four Actions are defined 🔥:
- Search
- Locate
- Order
- Deliver
These Actions are shown in Figure 1 🦋.
+--------+ . . +--------+ . . +-----------+
| |-- Search -->| |-- Search -->| |+
| | : : | | : : | ||
| |-- Locate -->| |-- Locate -->| ||
|Customer| : : | Broker | : : |Supplier(s)||
| |-- Order --->| |-- Order --->| ||
| | : : | | : : | ||
| |<- Deliver --| |<- Deliver --| ||
+--------+ : : +--------+ : : +-----------+|
: : : : +-----------+
Helpers Helpers
<Authentication> <Payment> <Security>Figure 1 GAIA Roles and Actions 🎀
2.2.1. Search 🔍
The Search Action happens when the Customer asks the Broker to find some information for them 🙋. To do this, the Customer describes the Product they need to the Broker 📝. Based on that description, the Broker runs a search for the Customer and sends back the result 🚀. The result of a Search Action is a set of unique identifiers that point to the Products matching the Customer's description 💖.
2.2.2. Locate 📍
The Locate Action happens when the Customer asks the Broker for info about where a Product is and who's selling it 🗺️. For the Broker to do this, the Customer has to give an unambiguous identification of the Product, which might be the result of a Search Action 🎯. The Broker sends back information about a source or sources for the Product 📦. That data includes the Terms of Availability, like the available delivery methods, delivery time, costs, and so on 💸. But ngl, this info isn't final yet, because special terms and conditions might apply, like discounts for certain categories of Customers 🙈. The final version of the Terms of Availability gets settled during the negotiation phase of the Order Action 🤝.
2.2.3. Order 🛒
The Order Action happens when the Customer asks the Broker to get a Product for them, or asks the Supplier to sell the Product straight to the Customer 💅. To make an Order happen, the Customer gives the Broker or Supplier the Product source information, which might come from a Locate Action 📒. The Order Action has a negotiation phase and (possibly) a purchase phase ✨. During the negotiation phase, the Customer gets a quotation with the final version of the Terms of Availability for the (batch of) Products they're thinking about buying 🧾. If the Customer is happy with those conditions, they commit to the purchase 💖. Or, if the Broker or Supplier supports telepresence services for talking with their representatives, those can be used during the negotiations too 📹🫶.
2.2.4. Deliver ✨
okay so the Deliver Action is the moment the Broker actually hands the Customer their requested Product 🎁 the Product can be information, some physical object, or metadata. and it can show up as a response to an Order Action, a Search Action, or a Locate Action 💅
bestie, here's the tea: the Actions in this section can logically be lined up as one integrated sequence, but that is NOT necessarily the case 🫶 Actions can happen independently instead of being part of a four-Action whole. like, the Customer could get info through some other mechanism than GAIA Search and Locate Actions, and then do Order and Deliver Actions based on that 🦋 iconic flex
2.3. GAIA Helper Events 🌸
so during any of the GAIA Actions we just talked about, sometimes you need some supporting activity 💖 these are called GAIA Helper events, and they include things like authentication and payment. the Helper entities show up during the GAIA events to provide services, on top of the GAIA Actions, to the GAIA actors 🧚
Authentication 🔐
to verify the identity of one GAIA actor to another, an authentication exchange might need to happen. this can occur during any of the GAIA Actions. the manner or method of authentication is outside the scope of this document 🙈
Payment 💸
payment might need to happen during a GAIA transaction. in that case, one GAIA actor pays one or more other GAIA actors. the manner or method of payment is outside the scope of this document 💜
Security 🛡️
as part of any GAIA Action, some security operations might be needed, like encryption of data, verification of source and content integrity of Product, or digital signature of some data entity or entities. the particular security services and mechanisms that may be required, or the way they may be provided, is outside the scope of this document. no cap, that's a whole separate conversation 💀
3. The GAIA Functional Architecture 👑
3.1. The Concept 🎀
the GAIA Functional Architecture breaks the overall functionality of the GAIA Broker down into a bunch of components 🧩 it describes the roles and relationships of these components, and how they interoperate 💖
to work in a heterogeneous environment, the architecture introduces three levels of abstract elements of the Broker: the Kernel, Functional Unit Managers (FUMs), and Functional Units (FUs) (see Figure 2) ✨
GAIA Broker:
------------
[ Kernel ] Kernel
/ \ level
/ \
[Functional Unit] [Functional Unit] Technology-independent
[ Manager ] [ Manager ] action-dependent
/ \ / \ level
/ \ / \
[Functional][Functional] [Functional][Functional] Technology
[Unit ][Unit ] [Unit ][Unit ] dependent
level
Figure 2 Levels of the architectureFunctional Units are the technology dependent parts of the architecture 🔧 they perform required transactions in terms of a particular protocol. all FUs are covered by a technology independent interface 🫶 FUs get grouped by the trading action they take part in, e.g. search FUs or locate FUs, and each group is governed by the matching Functional Unit Manager 👑
Functional Unit Managers hold technology independent functions for particular actions 💅 to use a particular technology, an FUM uses the services of its attached FUs. there can be several FUs attached to one FUM, so the FUM can operate in different technology contexts 🦋
there's one FUM in the system for every area of functionality, e.g. search, locate, and order 🌈 the Kernel is in charge of managing the activity of the different FUMs (each one matching a different action) and synchronising events between them ⭐
the GAIA Functional Architecture sets up relationships between the existing technologies (standards and protocols) that are combined in the GAIA Standard, in the context of a brokerage system 🎀 it's expected that new technologies will evolve that could be viable alternatives to the ones selected. the abstract and modular nature of the Functional Architecture lets one technology be swapped for a new one without disrupting the rest of the brokerage system 😭🫶
3.2. Functional Units 🧚
the brokerage system gives its users a number of services 💖 these services are supported by the functions of the brokerage system, including, for example,
- searching
- ordering
- payment
each of these functions can be provided by a number of different candidate technologies 🌸 but the operations that need to be carried out stay the same. no matter which technologies get picked, the functional requirements don't change 💜 the required operations are described in terms of abstract primitives, which can be mapped to the protocol instructions of the technology chosen to support the function ✨ a mapping component, called a Functional Unit (FU), is defined for each candidate technology, and it converts calls to abstract primitives into protocol instructions 🔥 the FU acts as an adaptor between its particular technology and the rest of the brokerage system 🫶
Functional Units get defined for each candidate technology that can be used to fulfil a particular functional need of the brokerage system 💅 a Functional Unit accepts abstract primitive invocations and maps them to calls to the particular technology it's dedicated to 🦋 the results of those calls get translated back into the corresponding abstract primitives and returned by the FU, as shown in Figure 3 🌈
* The rest of the Broker *
^
| -abstract primitives
v
+------------+
| Functional |
| Unit |
+------------+
^
| -technology-specific commands
v
* Technology functions *Figure 3 GAIA Functional Unit
3.3. Functional Unit Managers 🦄
like we said above, a bunch of different candidate technologies can fulfil a particular functional requirement of the brokerage system 💖 depending on the details of the GAIA transaction (underlying network, Customer system capabilities, etc.), different technologies may be more useful during different transactions 🌸 so each candidate technology gets its own Functional Unit, which is invoked when that particular technology is required ✨
a number of different Functional Units can exist that fulfil the same functional requirement 💅 to pick the most appropriate FU (and technology), the brokerage system needs to know which one is most useful at any given time. generally that's the technology supported by the target Supplier system 👑 this is the job of the Functional Unit Manager, or FUM. each function of the brokerage system has a single FUM, which the Broker Kernel invokes using abstract primitives 🎀 this FUM picks the most appropriate candidate technology and calls the matching FU (see Figure 4) 🔥
the interface between the FUM and its FUs is defined for every FUM in an open, platform independent, and programming language independent way 🌈 these interfaces don't depend on any particular technology 🫶 this lets the Broker be configured with different subsets of FUs, so you can attach whichever technologies you want 🧚 if a new technology needs supporting, a new FU implementing it can be created according to the interface specification and attached to the matching FUM 😭✨
+--------------------------------------+
| Functional Unit Manager |
+--------------------------------------+
^ ^
| -abstract primitives- |
v v
+------------+ +------------+
| Functional | | Functional |
| Unit | | Unit |
+------------+ +------------+
^ ^
| -technology-specific commands- |
v v
* Technology * * Technology *
* functions * * functions *Figure 4 Functional Unit Manager
3.4. The Kernel 👑
the Kernel of the brokerage system acts as a bus for transmitting abstract primitives between FUMs 🚌 each FUM imports a set of abstract primitives representing the services it expects to receive from some other part of the system 💜 the services the FUM is prepared to provide to other elements of the brokerage system are presented as exported abstract primitives 🦋 all of these abstract primitives get imported from, and exported to, the Kernel (see Figure 5) 💅
the Kernel is also responsible for synchronisation of different actions within a transaction, and for maintaining a common context between actions 🫶✨
+-------------------------------------+
| Broker Kernel |
+-------------------------------------+
^ ^ ^
| -abstract- | -primitives- |
v v v
+-------+ +-------+ +-------+
| FUM | | FUM | | FUM |
+-------+ +-------+ +-------+Figure 5 Broker Kernel
3.5. Description of FUMs 🧚
okay so the brokerage system has ten core activities it's juggling, and each one gets its own FUM to handle it 💅:
- searching for Products that fit a user description
- sourcing Products the identification of which is known
- allowing users to order Products
- delivering information in item format
- delivering information as a continuous media stream
- providing a user interface to the brokerage services
- alerting users as to the availability of information
- interacting with external directory services
- authentication of other actors
- payment operations
each one is handled by its matching FUM, and you can see how they all fit together in Figure 6 ✨
Search FUM 🔍
the Search FUM takes requests to search for Products that fit a particular user description. it sends back lists of identifiers of Products that fit the description.
Locate FUM 📍
the Locate FUM takes Product identifiers and figures out where they can be obtained. it returns lists of Suppliers and locations for the Product.
Order FUM 🛒
the Order FUM runs the negotiations between a Customer and a Supplier so they can agree on the terms of availability for a particular Product or group of Products. once the negotiation phase is done, the Order FUM accepts purchase commitments from the Customer and forwards them to the Supplier. it then returns a notification of the status of the Order Action 🫶
The GAIA Broker:
----------------
(Customer)) (Alerting)) ( DS )) (Auth)) (Payment))
( FUs )) ( FUs )) ( FUs )) ( FUs)) ( FUs ))
(e.g.HTTP)) (e.g. SMS)) (eg LDAP)) ( )) (e.g.SET))
\/ \/ \/ \/ \/
[Customer] [Alerting] [ DS ] [ Auth ] [Payment]
[ FUM ] [ FUM ] [ FUM ] [ FUM ] [ FUM ]
| | | | |
+----------------------------------------------------------+
| Broker Kernel |
+----------------------------------------------------------+
| | | | |
[ Search ] [ Locate ] [ Order ] [ Stream ] [Discrete]
[ FUM ] [ FUM ] [ FUM ] [Delivery] [Delivery]
[ ] [ ] [ ] [ FUM ] [ FUM ]
/\ /\ /\ /\ /\
( Search )) ( Locate )) ( Order )) ( SD )) ( DD ))
( FUs )) ( FUs )) ( FUs )) ( FUs )) ( FUs ))
(eg Z39.50)) (eg Z39.50)) (eg ISO ILL)) (eg RTP)) (eg FTP))Figure 6 GAIA Functional Architecture
Discrete Delivery FUM 📦
the Discrete Delivery FUM manages the delivery of discrete items to the Customer.
Stream Delivery FUM 🎬
the Stream Delivery FUM manages the delivery of real-time multimedia data streams to the Customer.
Customer FUM 💖
the Customer FUM provides an interface that supports the Customer's systems interaction with the brokerage system.
Alerting FUM 🔔
the Alerting FUM notifies Customers about changes that may interest them.
Directory Services FUM 📚
the Directory Services FUM provides an interface between an external directory service and the brokerage system.
Authentication FUM 🔐
the Authentication FUM provides a mechanism that allows a user to prove their identity to the brokerage system.
Payment FUM 💸
the Payment FUM provides a mechanism for payment from one actor to another.
4. GAIA Brokerage System Interfaces 🔌
this chapter covers the internal and external interfaces of the GAIA brokerage system.
4.1. Internal Interfaces
communication between the functional components inside the GAIA Broker is based on the OMG CORBA model [2]. the interfaces between components are defined in the IDL language specified by OMG, and interface calls get passed between components by the Object Request Broker (ORB) 🧠
the big win here is that the interface specs are platform and programming language independent. these interfaces can be implemented in different programming languages on different platforms. all the necessary conversions during interface invocations are handled transparently by an ORB. the CORBA model also lets you install different functional components of the GAIA Broker on different computers connected by a network, and interface calls get carried across the network by an ORB, invisible to the application ✨
the specification of the interfaces between the Kernel and FUMs, and between each FUM and its corresponding FUs, is presented in the GAIA Standard [1].
4.2. External protocols 🌸
the GAIA Broker can use existing protocols to talk to other actors. for example, it can use HTTP for interactions with Customers and Z39.50 for search, etc. like we covered in the GAIA Functional Architecture, support for particular technologies comes from FUs. you can extend the set of supported protocols by attaching new FUs to a Broker. a Broker can support several protocols for each action, and the FUMs will pick the most appropriate protocol for a transaction. the more protocols a Broker supports, the better service it can give Customers and Suppliers 🙌
the GAIA Standard doesn't limit the set of protocols a Broker can support. however, for the sake of interoperability, it defines several GAIA profiles. these profiles set out a common subset of protocols (and a common range of protocol parameters) that Brokers are encouraged to support, so that GAIA Brokers can talk to each other and to GAIA-aware Suppliers and Customers 🤝
existing protocols aren't the only way to reach the GAIA Broker, though. the GAIA interfaces were designed as a generalisation of existing interfaces and protocols, so they offer more functionality than any single protocol does. to get full access to the Broker's functionality, the GAIA Standard lets users (Customers and other Brokers) call the CORBA-defined Customer interface of the GAIA Broker directly (the interface between the Customer FUM and FUs), as shown in Figure 7. in that case, the Customer system reaches the Broker's Customer interface through an underlying ORB and can request operations by calling the corresponding methods of the interface. the GAIA Broker's Customer interface is specified in the GAIA Standard [1]. 🎀
+----------------+
|Broker |
| |
| -------- |
+-----------+ | [ Kernel ] |
| Broker | | -------- |
| or | | [Customer] |
| Customer | | [ FUM ] |
| | | ========== <-GAIA Customer
| * | | * * | \interface
| { O R B *}* * * * * * *{* O R B * } |
+-----------+ iiop | * | +----------+
| (Customer) | | Customer |
| ( FU ) | | |
+------------I---+ +----I-----+
\ HTTP /
- - - - - -Figure 7 External protocols and the GAIA Customer interface
where Customer and Supplier systems aren't CORBA-aware, they can talk to a GAIA Broker using existing protocols. if they can use an ORB, though, they are encouraged to connect to a Broker's Customer interface. the upside of that route is that it avoids tying a particular protocol to the GAIA interface. the first method makes it possible to interact with all existing types of Customers and Suppliers using existing, widespread protocols. the later method was designed to get maximum functionality by using native GAIA methods for communication with Customers and Suppliers 💜
5. GAIA Standard Profiles 🌈
the GAIA Standard defines a number of profiles that a Broker may support so it can interoperate with other GAIA actors (Customers, Suppliers and other Brokers). which profile a Broker picks depends on the level and type of service it wants to deliver in a GAIA-conformant way. the higher the level of service a Broker gives a Customer, and the longer the supply chain the Broker wants to support, the more advanced the profile and/or the greater the number of extension modules the Broker has to support 📈
5.1. Supply Chains ⛓️
the GAIA profile definition approach is based on the possible types of supply chain a brokerage system can be part of.
the operations of a brokerage system fall into three categories:
- interactions with the Customer
- interactions with other Brokers
- interactions with Suppliers
the first and last of these happen at the two ends of a supply chain, while interbroker operations take place at other points in the chain. a supply chain can take a number of different forms:
- a minimal chain, where the Customer and the Broker are the ends of the chain and there are no intervening links. in this case, the Broker plays the role of Supplier to the Customer.
- a three-piece chain, where the Broker deals with the Customer and the Supplier but not with any other Broker.
- a longer chain, with one or more interbroker operations.
Minimal Supply Chain:
+--------+ +-------------+
|Customer| <=====> | Broker |
+--------+ |(as Supplier)|
+-------------+
3-piece Supply Chain:
+--------+ +--------+ +--------+
|Customer| <===> | Broker | <===> |Supplier|
+--------+ +--------+ +--------+
Longer Supply Chain:
+--------+ +--------+ +--------+ +--------+
|Customer| <===> | Broker |<=>| Broker | <===> |Supplier|
+--------+ +--------+ +--------+ +--------+Figure 8 Supply Chains
5.1.1. Minimal Supply Chains 🥰
as discussed in the GAIA Reference Model, a GAIA transaction is made up of a number of actions, like search, order, and delivery. every transaction is kicked off by the Customer, who makes a request to the Broker. if the Broker can fulfil the request, the transaction doesn't involve any other actors.
in this simple case, the GAIA transaction involves only the Customer and the Broker. the only protocol that really needs to be standardised is the one between the Customer and the Broker, and that's specified in the GAIA Standard Minimal profile below 🫶
5.1.2. Longer Supply Chains ✨
okay so what if the Broker can't fulfil a request? 😭 no panic, bestie. The action can get passed along to other Brokers, and the original Broker plays the Customer role for them 🫶 Each of those Brokers can keep passing it on if they can't handle it either 🔗
Eventually, if the action works out, a Supplier shows up who can fulfil the request 🎀 So the whole supply chain is one Customer, one or more Suppliers, and one or more Brokers. it's giving teamwork 💅
To pass an action from one Broker to another, there has to be a standardised communication protocol for broker-broker interaction 🦋 That's specified in the Basic profile, down below, and it's based on CORBA 💜
Suppliers and Brokers aren't obliged to support the Basic profile of the GAIA Standard, though 🙈 They can use another, more traditional protocol instead, like Z39.50 for discovery or ISO ILL for ordering 🌸 The Extension Modules to the GAIA Standard say which profiles to use for the different brokerage functions ✨
5.2. Introduction to the GAIA Standard Profiles and Modules
okay here are the profiles 👑
- The Minimal profile, which is the very least to which a GAIA Broker must conform
- The Basic Profile, which allows inter-broker communication
- A number of Extension Modules, which allow the Broker to provide various services, and to interoperate with Suppliers, Brokers and Customers using protocols specified in the modules
- A set of Interface Modules, that defines which particular Functional Unit CORBA interfaces are supported by the Broker
every Broker has to conform at least to the Minimal profile so it can give a web-based user interface 💖 To take part in inter-broker communications, the Basic profile is recommended 🧚 For talking to entities that aren't CORBA-aware, and for advanced services, there are other modules of the standard the Broker may conform to. These are called "Extension Modules", and they characterise the protocols and standards in a particular area of functionality 🌈 A Broker can pick whichever Extension Modules match the functionality it wants to achieve ✨
The GAIA Standard specifies all interfaces between FUM and FUs for the GAIA Broker 📋 But it would be too much to make every Broker implement all of them 😭 So the GAIA Standard breaks all the interfaces up into a number of Interface Modules 🧩 A Broker can choose the subset of Interface Modules that matter most in its area of operation, and implement the interfaces defined in those modules 🦋 These interfaces only matter inside the broker system and don't play any role in communication with other GAIA actors 🙈 Still, a declaration of supported interfaces is important, because it's how the administrator finds the areas where the Broker's functionality can be extended by attaching GAIA-conformant FUs 💅
5.3. Minimal Profile
the minimum a Broker must support lets it provide services to the Customer as part of a minimal chain 🎀 In this case, all the Broker needs is a user interface for the Customer. Anything else happens inside the Broker, so it doesn't come within the scope of the standard 💜
The Minimal profile requires the Broker to implement a user interface based on the HTTP 1.1 protocol, defined in RFC 2068 [3], and HTML 2.0, defined in RFC 1866 [4]. It means a Customer should be able to reach the basic functionality of the GAIA Broker using an HTTP 1.1 and HTML 2.0 conformant web-browser 🌸
It should be possible for Customers to locate a GAIA Broker. So a GAIA Broker should be registered in a Directory Service, using a schema specified in the GAIA Standard [1] 🔍
+-------------------------------------------------+
| Minimal Profile |
+------------------------+------------------------+
| Customer | HTTP 1.1 (server), |
| | HTML 2.0 |
+------------------------+------------------------+5.4. Basic Profile
ngl a Broker can function with just the minimal stuff, but dealing with other Brokers is a huge part of being a GAIA Broker 🌈 The goal of the Basic profile is federation between Brokers 🫶 Every GAIA Broker can use the services of other GAIA Brokers to fulfil a Customer's request. That Broker can then use the service of a third GAIA Broker, so every request can be chained through several Brokers ⛓️ This extends the abilities of every GAIA action (Search, Locate, Order, etc.) 🚀 Chained transactions matter most in the discovery phase, where a Broker that can't fulfil a particular information requirement passes the search to another Broker 🔁
The Basic profile requires the Broker to implement the GAIA Customer interface defined in terms of CORBA. This interface is described in more detail in Section 4.2 above. The Basic profile also requires the Broker to implement interface requestor procedures, i.e. to be able to connect to the Customer interfaces of other Brokers. The ORB used by the Broker should be conformant to the CORBA 2.0 specification [2] and use IIOP protocol for inter-ORB communications [2] 💖
A full specification of the GAIA Customer interface is presented in the GAIA Standard [1] 📖
A GAIA Broker should be able to find other Brokers and Suppliers, and it should also allow other participants to find it 🔭 So a GAIA Broker should support a directory service. The Basic profile includes a directory access protocol for this purpose. The actual choice of protocol isn't standardised, because the choice doesn't influence the success of the Broker's inter-operation with other Brokers 🤷♀️ The directory schema that should be used is specified in the GAIA Standard ✨
The Basic profile suggested for a Broker to interoperate with other GAIA Brokers looks like this 🦋
+----------------------------------------------------------------+
| Basic Profile |
+------------------------+---------------------------------------+
| Customer | GAIA Customer interface/IIOP (server) |
| Search and Locate | GAIA Customer interface/IIOP (client) |
| (Discovery) | |
| Order | GAIA Customer interface/IIOP (client) |
| Directory | Some directory access protocol, |
| | such as LDAP |
+------------------------+---------------------------------------+5.5. Extension Modules
so Brokers can still interoperate with Brokers that don't do the Basic profile 🥹 They also need to deal with Suppliers and Customers who aren't CORBA-aware, and to deliver items and data streams via the Broker 📦 That's why other open technologies are suggested as extensions to the Basic and Minimal profiles 🌟 These technologies come from the technology evaluation done as part of the project GAIA 🧪
The extra protocols are grouped into Extension Modules. Supporting these Extension Modules is optional 💜 A Broker can pick whichever Extension Modules match the functionality it wants to achieve 🎀 There's one Extension Module for each functional area that the Basic and Minimal Profiles don't cover, plus one Extension Module for each of the existing areas (Customer, Discovery, and Order), so you can use protocols other than GAIA abstract primitives 🔥
The following Extension Modules are defined 👑
- Discovery Extension Module
- Order Extension Module
- Discrete Delivery Extension Module
- Stream Delivery Extension Module
- Security Extension Module
- Payment Extension Module
- Alerting Extension Module
- Customer Discovery Extension Module
5.5.1. Discovery Extension Module
the Discovery Extension Module specifies the technologies used for searching for and locating products and services 🔎
This Extension Module requires the Broker to support the client part of the Z39.50 protocol, as defined in [5]. The following subset of the protocol is required:
- Init, Search, and Present services
- GRS-1 record syntax
Z39.50 protocol PDUs should be carried using TCP/IP network protocols 🌐
+-------------------------------------------------+
| Discovery Extension Module |
+------------------------+------------------------+
| Searching, | Z39.50 (client) |
| Locating | |
+------------------------+------------------------+5.5.2. Order Extension Module
the Order Extension Module specifies the protocols used to order products and services from a Supplier 🛒
This Extension Module requires the Broker to support all mandatory services of the client part of the ISO ILL protocol [6]. Basic conformance criteria should be adhered to. ISO ILL protocol PDUs should be carried using TCP/IP network protocols 💅
+-------------------------------------------------+
| Order Extension Module |
+------------------------+------------------------+
| Order | ISO ILL (client) |
+------------------------+------------------------+5.5.3. Discrete Delivery Extension Module 📦✨
okay bestie, this one is all about how the on-line products and services actually get delivered to the Customer 💅 There are two delivery scenarios:
- Direct Supplier to Customer delivery The delivery can be a single step, where the Supplier hands its product straight to the Customer and no Broker touches the delivery at all 🦋 The Broker might have pointed the Customer toward the Supplier, but if the Broker isn't involved in the delivery, the Discrete Delivery Extension Module does not apply, no cap.
- Delivery over a supply chain with one or more Brokers involved If the Broker is the middle link in a Supplier-Broker-Customer chain, the Broker uses the protocols in this module to receive the product from the Supplier and then pass it along to the Customer 🔥
The Discrete Delivery Extension Module requires the Broker to have both FTP client and FTP server functionality [7], so it can receive files and send files over FTP 📁
The Broker also needs to be able to accept and generate e-mail messages 💌 The e-mail protocol is Internet e-mail, built on SMTP [8] and the mail data formats from RFC 822 [9]. That combo is totally enough for making, sending, and managing text-only emails, but if you want to send actual data files of all kinds, you need extensions to SMTP and RFC 822. This module uses MIME (Multipurpose Internet Mail Extensions), which is defined in RFCs 2045-2049 [10]. So the vibe is: a GAIA Broker must be able to send and receive "simple" SMTP/RFC822 mail, and it also must be able to handle the RFC 2045-2049 MIME mail extensions 🌈
For electronic document delivery, this module requires support for GEDI version 3.0 📄✨
+--------------------------------------------------------+
| Discrete Delivery Extension Module |
+------------------------+-------------------------------+
| FTP profile | FTP (client+server) |
| Email profile | Internet e-mail [SMTP,RFC822] |
| | (receiver+sender), |
| | MIME |
| Document delivery | GEDI version 3.0 |
+------------------------+-------------------------------+5.5.4. Stream Delivery Extension Module 🎧
This Extension Module is here for real-time multimedia delivery by the GAIA Broker, and it's giving live-stream energy 🎀
There are a few scenarios for stream delivery. A stream can go:
- directly from a Supplier to a Customer The Broker isn't part of the stream delivery here. This scenario is out of scope for this standard, so we're not talking about it 🙈
- from a Supplier to a Customer via a Broker The Broker can add value by doing things like caching, mixing streams, and branching one stream out to several Customers 🌸
- from a Broker to a Customer The Broker can store a small amount of multimedia data, like audio examples, in its own database and send it to a Customer whenever they ask 🧚
The Stream Delivery Extension Module is recommended for a Broker to implement, so it can cover the last two real-time multimedia scenarios 💜
To do this, the Broker needs to support these technologies:
- Compression MPEG-2 Audio Layer 3, specified in ISO/IEC 13818-3 [11]. Only support for constrained parameter streams (CSPS) is required 🎶
- Data transfer protocol RTP over UDP/IP, defined in RFC 1889 [12]. Both the client and server parts are needed. It is recommended that the Broker supports the full behaviour of an RTP application service entity ("translator" or "mixer"), but that isn't required 🦋
- Mapping RTP payload format for MPEG Audio (MPA), defined in RFC 2250 [13] 🗺️
- Session control protocol RTCP, specified in RFC 1889 [12] 🎛️
This profile delivers high-quality audio over networks without guaranteed quality of service, like the Internet. Iconic for a reason 👑
+----------------------------------------------------+
| Stream Delivery Extension Module |
+--------------------------+-------------------------+
| Compression | MPEG-2 Audio Layer 3 |
| Data transfer | RTP (client+server) |
| Mapping | RFC 2250 |
| Session control protocol | RTCP |
+--------------------------+-------------------------+5.5.5. Security Extension Module 🔐
Okay, security is the whole point here, so let's go 🫶 The basic security services GAIA needs are:
- Authentication of users, remote servers (both as entity authentication and as bilateral peer-to-peer authentication), senders, and receivers in network transactions, plus authentication of documents. Authentication is needed in three situations: when the user's workstation starts the session, inside a local environment (client/server authentication), and across a global, open network (the Internet) 🪪
- Confidentiality and integrity of all resources sent over the network or handled locally at application servers and user workstations 🤐
- Control of access to services and resources 🚪
- Non-repudiation of transactions, participants, and sensitive documents ✍️
This module lets a Broker keep its communications secure with other participants. It handles channel security, authentication, and certificate exchange 💖
The Security Extension Module specifies these protocols and algorithms:
- Privacy, integrity, non-repudiation SSL v3.0 protocol, defined in [14] PKCS #7, defined in [15]
- Remote, client/server authentication GSS v5, specified in RFC 1508 [16]
- Certification services PKIX certification protocol, specified in [17]
+-----------------------------------------------------------+
| Security Extension Module |
+--------------------------------------+--------------------+
| Privacy, integrity, non-repudiation | SSL v 3.0, PKCS #7 |
| Remote, client/server authentication | GSS v5 |
| Certification services | PKIX certification |
| | protocol |
+--------------------------------------+--------------------+5.5.6. Payment Extension Module 💸
This module lets a Broker do electronic payment operations with Customers, Suppliers, and other Brokers 💅 These operations can happen at any stage of a GAIA transaction, during a Search, Locate, Order, or Deliver Action.
The GAIA Standard doesn't specify the tariffing or charging model a Broker uses. That's an internal matter, so it's the Broker's call ✨ Once a bill has been agreed on, though, the payment has to happen in a secure and mutually acceptable way 🔒 The payment procedure in the GAIA Standard uses the SET specification.
The Payment Extension Module requires a Broker to support the SET v1.0 merchant's server and the SET certification protocol, specified in [18] 🛍️
+----------------------------------------------------+
| Payment Extension Module |
+------------------------+---------------------------+
| Payment | SET v 1.0 : |
| | 1) CA server for banks |
| | 2) Cardholder wallet |
| | 3) Merchant Server |
| | 4) Payment Gateway server |
+------------------------+---------------------------+5.5.7. Alerting Extension Module 🔔
The Alerting Extension Module is how you notify Customers about changes they'd find interesting 👀
This Extension Module needs support for these technologies:
- Internet e-mail, based on the SMTP protocol [8] and the mail data formats from RFC 822 [9]. The Broker should be able to generate and send e-mail messages 📧
- SMS (Short Message Service), specified in [19] 📱
+-----------------------------------------------------+
| Alerting Extension Module |
+-----------+-----------------------------------------+
| Alerting | Internet e-mail [SMTP,RFC822] (sender), |
| | SMS |
+-----------+-----------------------------------------+5.5.8. Customer Discovery Extension Module 🔍
The Customer Discovery Extension Module lets Z39.50 clients use the GAIA Broker's services. It's a whole vibe 🧚
This Extension Module requires the Broker to support the server part of the Z39.50 protocol, as defined in [5]. The subset that's required is:
- Init, Search, and Present services
- GRS-1 record syntax
Z39.50 protocol PDUs should be carried over TCP/IP network protocols 🌐
+----------------------------------------------------+
| Discovery Extension Module |
+------------------------+---------------------------+
| Searching, | Z39.50 (server) |
| Locating | |
+------------------------+---------------------------+5.6. Interface Modules 🧩
For conformance purposes, all the interfaces between FUMs and FUs that the GAIA Standard specifies get grouped into GAIA Interface Modules. A GAIA Broker is recommended to support these modules, but they aren't mandatory. A Broker can pick the subset of Interface Modules that matter most in its area of operation and implement the interfaces in those modules 💖
A full specification of the Functional Unit interfaces is in the GAIA Standard [1] 📖
The table below shows the Interface Modules and which interfaces have to be supported in each one:
+--------------------+------------------------------------+
| Interface Module | Interfaces that are required to be |
| | supported in this module |
+--------------------+------------------------------------+
| Search | Search FU interface |
| Locate | Locate FU interface |
| Order | Order FU interface |
| Discrete Delivery | Discrete Delivery FU interface |
| Stream Delivery | Stream Delivery FU interface |
| Customer | Customer FU interface |
| Alerting | Alerting FU interface |
| Directory Services | Directory Services FU interface |
| Authentication | Authentication FU interface |
| Payment | Payment FU interface |
+--------------------+------------------------------------+6. Acknowledgement 🌷
We want to say a huge thank you to every member of the GAIA Consortium 🫶 Their very lively discussion, plus all the valuable direct and indirect input they gave during the design process of the GAIA Standard, made this happen ✨
7. Security Considerations 🚨
Security issues related to electronic brokerage are discussed in Sections 2.1.4, 2.3 and 5.4.5. Go read those, bestie, they're important 💀
8. References ✨
Okay bestie, here are all the sources the spec leans on, and I'm keeping every single detail 📚🤓
[1] GAIA Consortium, Deliverable 0403, "GAIA Standard (Final)", December 1998, see also <http://www.syspace.co.uk/GAIA/>.
[2] Object Management Group, "CORBA 2.0 Specification", July 1996, See <ftp://ftp.omg.org/pub/docs/formal/97-02-25.pdf>.
[3] Fielding, R., Gettys, J., Mogul, J., Frystyk, H. and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2068, January 1997.
[4] Berners-Lee, T. and D. Connolly, "Hypertext Markup Language - 2.0", RFC 1866, November 1995.
[5] ANSI/NISO Z39.50-1995 or ISO 23950 "Information Retrieval: Application Service Definition and Protocol Specification".
[6] ISO 10161:1997 "Information and documentation -- Open Systems Interconnection -- Interlibrary Loan Application Protocol Specification".
[7] Postel, J. and J. Reynolds, "File Transfer Protocol", STD 9, RFC 959, October 1985.
[8] Postel, J., "Simple Mail Transfer Protocol", STD 10, RFC 821, August 1982.
[9] Crocker, D., "Standard for the format of ARPA Internet text messages", STD 11, RFC 822, August 1982.
[10] Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies", RFC 2045, November 1996.
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types", RFC 2046, November 1996.
Moore, K., "MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text", RFC 2047, November 1996.
Freed, N., Klensin, J., and J. Postel, "Multipurpose Internet Mail Extensions (MIME) Part Four: Registration Procedures", RFC 2048, November 1996.
Freed, N., and N. Borenstein, "Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples", RFC 2049, November 1996.
[11] ISO/IEC IS 13818 "Information technology -- Coding of moving pictures and associated audio information"
Part 1: Systems Part 2: Video Part 3: Audio Part 4: Conformance testing Part 5: Software simulation
[12] Schulzrinne, H., Casner, S., Frederick, R., and V. Jacobson, "RTP: A Transport Protocol for Real-Time Applications", RFC 1889, January 1996.
[13] Hoffman, D., Fernando, G., Goyal, V. and M. Civanlar, "RTP Payload Format for MPEG1/MPEG2 Video", RFC 2250, January 1998.
[14] Freier, A., Karlton, P. and P. Kocher, "The SSL Protocol - Version 3.0", Work in Progress, Transport Layer Security Working Group, November 1996, See <http://home.netscape.com/eng/ssl3/index.html>.
[15] PKCS #7: Cryptographic Message Syntax Standard. Version 1.5, November 1993.
[16] Linn, J., "Generic Security Service Application Program Interface", RFC 1508, Geer Zolot Associate, September 1993.
[17] Public-Key Infrastructure (X.509) IETF Working Group, <http://www.ietf.org/html.charters/pkix-charter.html>, July 98.
[18] "SET Secure Electronic Transaction Specification", Version 1.0, MasterCard and Visa, May 97.
[19] Digital Cellular Telecommunications System (Phase 2+): Technical Realization of the Short Message Service (SMS) Point-to-Point (PP) (GSM 3.40). Version 5.2.0. European Telecommunications Standards Institute. May 1996.
9. Authors' Addresses 🎀
Meet the squad behind this spec, the team from University College Dublin 🇮🇪🌸
Mikhail Blinov
Mikhail Blinov
Computer Science Department
University College Dublin
Belfield, Dublin 4, Ireland
Phone: +353 1-706-2488
Fax: +353 1-269-7262
EMail: mch@net-cs.ucd.ieMikhail Bessonov
Mikhail Bessonov
Computer Science Department
University College Dublin
Belfield, Dublin 4, Ireland
Phone: +353 1-706-2488
Fax: +353 1-269-7262
EMail: mikeb@net-cs.ucd.ieCiaran Clissmann
Ciaran Clissmann
Computer Science Department
University College Dublin
Belfield, Dublin 4, Ireland
Phone: +353 1-706-2488
Fax: +353 1-269-7262
EMail: ciaranc@net-cs.ucd.ie10. Full Copyright Statement 💅
Legal stuff, but it matters, so here it is in full 🫶
Copyright (C) The Internet Society (1999). All Rights Reserved.
This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works. However, this document itself may not be modified in any way, such as by removing the copyright notice or references to the Internet Society or other Internet organizations, except as needed for the purpose of developing Internet standards in which case the procedures for copyrights defined in the Internet Standards process must be followed, or as required to translate it into languages other than English.
The limited permissions granted above are perpetual and will not be revoked by the Internet Society or its successors or assigns.
This document and the information contained herein is provided on an "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
That's the whole spec, bestie! 🌈🦋👑
📦 where this page comes from
- ietf: rfc2552 1999-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms