- Email: [email protected]
Reference model and functional architecture for information availability
Computer Standards & Interfaces 21 Ž1999. 273–285 www.elsevier.comrlocatercsi
Reference model and functional architecture for information availability Ahmed Patel ) , Mikhail Blinov 1, Mikhail Bessonov
2
Computer Networks and Distributed Systems Research Group, UniÕersity College Dublin, Belfield, Dublin 4, Ireland Received 7 December 1998; accepted 16 February 1999
Abstract This paper presents a domain and supplier independent generic architecture for the information brokerage, designed as a part of the EU ACTS R & D project GAIA ŽGeneric Architecture for Information Availability.. The GAIA Architecture provides a common framework for developers of the brokerage systems. This paper describes a Reference Model which defines actors involved in the information trading and actions that constitute the trading process. It introduces a modular Functional Architecture which covers the functionality of the brokerage system and allows to incorporate different existing technologies into the broker. It specifies a set of profiles which ensure an interoperability of the broker with other brokers, and with customers and suppliers. This architecture has been verified by the reference implementation of the GAIA brokerage system and by public trials in three different domains: music, technical data of computer components, and publishing. This architecture will be published as a GAIA Standard at the end of the GAIA project. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Electronic trading; Brokerage; Information architecture; Reference model; Standard
1. Introduction One of the characteristics of the current state of the electronic market, that limit its growth, is a lack of mediation services. In the old model of the market that is still in use today customers are supposed to search for the desired product by themselves and communicate with suppliers directly. This model was designed when the electronic market was relatively
)
Corresponding author. Tel.: q353-1-706-2476; fax: q353-1269-7262; e-mail: [email protected] 1 E-mail: [email protected] 2 E-mail: [email protected]
small. However, the electronic market has been growing rapidly in the past few years. Now it offers for customers a huge number of products, available from a large number of suppliers. The problem is that there is still no efficient and scalable method for customers and suppliers to find each other. High heterogeneity of existing protocols, formats and underlying networks also limits development of the electronic market. These problems can be solved by brokerage systems, which can work as intermediary entities between customers and content suppliers. Brokerage systems can assist a customer during the trading process and hide heterogeneity and distribution of information from the customer. The design of do-
0920-5489r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 0 - 5 4 8 9 Ž 9 9 . 0 0 0 0 6 - 9
274
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
main and supplier independent generic architecture for such brokerage systems is an objective of the project GAIA ŽGeneric Architecture for Information Availability.. The GAIA brokerage system allows a customer to Ø search for a product Žinformation, content or services. of hisrher interest Ø locate the product, which means find a set of suppliers, where this product is available from Ø order the product from the chosen supplier Ø request to deliver the product The broker can carry out all these actions on behalf of the customer. The broker can use trade protocols that are convenient for suppliers to get information about products, and use protocols that are convenient for customer to present this information. Full specification of the GAIA Architecture is available in the GAIA Standard w1x, which is due to be published in December 1998. The GAIA Standard includes a description of the GAIA Reference Model, GAIA Functional Architecture, GAIA Standard Profiles, and specification of the GAIA interfaces. This paper presents basic ideas and concepts of this standard.
2. The GAIA reference model The Generic Architecture for Information Availability ŽGAIA. Reference Model outlines the operations and actors involved in finding, ordering and delivering physical and digital objects and services Ž‘Products’. in a global brokered distributed information environment. It provides an overall view of the GAIA environment, and illustrates the respective roles of and relationships between its components. Further work on standards and frameworks for individual components of the GAIA environment uses the model and terminology provided by the Reference Model. The GAIA environment is a collection of actors and functions that are combined to support a procedure for information and services discovery, order and delivery. The actors play roles in the procedure, including initiation and execution of the Actions which are combined to make up the overall transaction. The GAIA architecture provides a standardised and widely applicable framework for the provision
and implementation of the brokered search and retrieve applications in a large-scale networked environment. 2.1. GAIA roles The GAIA model introduces three principal roles, which can be played by the GAIA actors. These are the Customer, the Broker and the Supplier. The actors are organisations and individuals in the supply chain. Every GAIA actor plays at least one role at any given time. The model also introduces a number of supporting roles, such as authentication or payment, which provide an additional functionality in the GAIA Actions. Supporting roles are played by GAIA ‘Helpers’. 2.1.1. The Customer The Customer role initiates the GAIA transaction by requesting one or more GAIA Actions, and receives the results of the transaction. The aim of the Customer is to obtain some Products or information about some Products. The Customer may deal with actors playing either of the other two roles, the Broker or the Supplier. These actors may themselves play the role of the Customer while requesting further services from other Brokers. 2.1.2. The Broker The Broker responds to requests from the Customer to provide Products, or information about Products. These Products, or information about them, are collected by the Broker from a number of Suppliers. The services provided by a Broker obviate the need for the Customer to deal with a variety of Suppliers. The Broker can use services of other Brokers in order to fulfil requests of the Customer. 2.1.3. The Supplier The Supplier is the source of the Products supplied to the Customer. The Supplier provides the Broker with information about the Products that it can supply. The Supplier may supply its Products directly to the Customer, or to the Broker, for forwarding to the Customer. An actor playing the role of a Supplier may also play the role of a Broker. A Supplier may deal with a large number of Brokers and Customers, over a number of GAIA transactions.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
2.1.4. Helpers A Helper is an application layer entity playing a supporting role in a GAIA transaction. Helpers provide some service needed in the supply chain, but outside the core functionality of the Broker. Examples include a global directory service or payment service or authentication service. The authentication Helper is concerned with facilitating the authentication of one actor to another. The payment Helper provides a mechanism for payment operations between actors. In any given GAIA transaction, there will be one or more Customers Žusually one., one or more Brokers, and one or more Suppliers. 2.2. GAIA actions Each GAIA transaction is made up of one or more Actions. These Actions are requests by the Customer to the Broker or the Supplier to carry out some operation, and to respond to the Customer. Four Actions are defined in the GAIA Standard Žsee Fig. 1. Ø Search Ø Locate Ø Order Ø Deliver 2.2.1. Search The Search Action is carried out by the Broker when the Customer asks to find some information on
275
its behalf. In order to do this, the Customer provides the Broker with some description of the Product which it requires. The Broker carries out a search of the products that matches the description and returns the result to the Customer. The result of a Search Action is a set of unique identifiers of the found Products. It does not include information about where these products can be obtained. 2.2.2. Locate The Locate Action is carried out when the Customer asks the Broker to provide it with information regarding the location and source of some Product. In order to allow the Broker to do this, the Customer provides an unambiguous identification of the Product, which may be the result of a Search Action. The Broker returns information to the Customer about a source or sources for the Product. These data include the Terms of Availability information such as methods of delivery available, time of delivery, costs, etc. However, this information cannot be considered final, since some special terms and conditions may apply, e.g., discounts for some categories of Customers. The final version of the Terms of Availability is established during the negotiation phase of the Order Action. 2.2.3. Order The Order Action is carried out when the Customer asks the Broker to obtain a Product on its behalf, or asks the Supplier to sell the Product
Fig. 1. GAIA roles and actions.
276
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
directly to the Customer. To enable Order, the Customer provides the BrokerrSupplier with Product source information, which may be a result of a Locate Action. The Order Action consists of a negotiation phase and Žpossibly. a purchase phase. During the negotiation phase the Customer obtains the quotation which contains the final version of the Terms of Availability for the Product or a batch of Products he is considering purchasing. If the Customer finds these conditions satisfactory, he commits to the purchase. Alternatively the Customer can negotiate another conditions with the Supplier directly or through the Broker. 2.2.4. DeliÕer The Deliver Action is carried out when the Customer asks the Broker to deliver the chosen Product. The Product may be information, some physical object or metadata. In order to allow the Broker to do this, the Customer provides an unambiguous identification of the Product together with its location. The Deliver Action is usually in response to an Order Action. While the Actions presented in this section may logically be taken to form an integrated sequence, this is not necessarily the case. Actions may take place independently, rather than as a section of a four-Action whole. For example, Order and Deliver Actions may occur on the basis of information obtained by the Customer using some other mechanism than GAIA Search and Locate Actions. 2.3. GAIA helper eÕents During any of the GAIA Actions outlined above, it may be necessary to carry out some supporting activity. These activities are called GAIA Helper events. Examples of such events are authentication and payment. The Helper entities are involved in the GAIA events to provide services, additional to the GAIA Actions, to the GAIA actors. 2.3.1. Authentication Some actions can require a verification of the identity of one GAIA actor to another. In this case an authentication exchange may need to take place. The services for the authentication are provided by an
Authentication Helper. The manner or method of authentication is outside the scope of this document. 2.3.2. Payment It may be necessary for payment to take place during a GAIA transaction. In this situation, one GAIA actor pays one or more other GAIA actors. This is provided by a Payment Helper. The manner or method of payment is outside the scope of this document. 2.3.3. Security As part of any GAIA Action, it may be necessary to carry out some security operations, such as encryption of data, verification of source and content integrity of Product, or digital signature of some data entity or entities. These services are provided by a Security Helper. The particular security services and mechanisms which may be required, or the manner, in which they may be provided, is outside the scope of this document.
3. The GAIA functional architecture 3.1. The concept The GAIA Functional Architecture decomposes the overall functionality of the GAIA Broker into a number of components, and describes the roles and relationships of the components, and the manner in which they interoperate. In order to work in a heterogeneous environment the GAIA Functional Architecture introduces three levels of abstract elements of the Broker: the Kernel, Functional Unit Managers ŽFUMs., and Functional Units ŽFUs. Žsee Fig. 2.. All technology dependent algorithms and procedures are contained in Functional Units. FUs are the only technology-dependent parts of the architecture. They are responsible for performing required transactions in terms of a particular protocol. FUs are grouped according to the trading action they participate in, e.g., search FUs or locate FUs. All FUs from the same group are covered by the same technologyindependent interface. Each group of FUs is governed by the corresponding Functional Unit Manager.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
277
Fig. 2. Levels of the architecture of the GAIA broker.
Functional Unit Managers contain technology independent functions for particular trading actions. In order to use a particular technology, FUM uses the services of attached FUs. There may be several FUs associated with a FUM, allowing the FUM to operate in different technology contexts. There is one FUM in the system for every area of functionality, e.g. search, locate, and order. The Kernel is the highest level in the architecture. It is responsible for managing the activity of different FUMs Žcorresponding to different trading actions. and synchronising events between them. It is expected that a set of technologies, which are required to be supported by the Broker to communicate with Customers and Suppliers, is not permanent. New technologies will evolve. The abstract and modular nature of the Functional Architecture allows the replacement of one technology with a new one without disruption to the rest of the brokerage system. 3.2. Functional units Each of the functions of the brokerage system can be provided by a number of different candidate technologies. However, the actual operations that are required to be carried out remain the same regardless of the selected technologies. These operations are described in terms of abstract primitives, which can be mapped to the protocol instructions of the technology selected to support the function. A set of the abstract primitives is defined for each of the functional areas of the brokerage system. A mapping between abstract primitives and actual technology is performed by a Functional Unit ŽFU. component. A FU is defined for each candidate technology that can
be used to fulfil a particular functional need of the brokerage system, and 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. A Functional Unit accepts abstract primitive invocations, and maps them to calls to the particular technology to which it is dedicated. The results of these calls are translated into the corresponding abstract primitives and returned by the FU, as shown in Fig. 3. 3.3. Functional unit managers A number of different Functional Units can exist which fulfil the same functional requirement of the brokerage system, but using different underlying technologies. For any particular transaction the brokerage system should select the most appropriate technology Žrepresented by a FU.. This is the responsibility of the Functional Unit Manager, or FUM. Each functional area of the brokerage system has a single FUM, which is invoked in terms of abstract primitives by the Broker Kernel. This FUM selects
Fig. 3. Interfaces of the GAIA functional unit.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
278
the most appropriate of the candidate technologies, and calls the corresponding FU ŽFig. 4.. The interface between the FUM and the corresponding FUs is defined for every FUM in an open, platform-independent, programming-language independent manner. These interfaces do not depend on any particular technology. It allows configuring the set of technologies, supported by the Broker, by attaching different subsets of FUs. If a new technology is to be supported by the Broker, a new FU implementing this technology can be created according to the specification of the interface and attached to the corresponding FUM. 3.4. The kernel The Kernel is responsible for synchronisation of events between different actions Ždifferent FUMs.. According to the GAIA Functional Architecture FUMs do not have direct connections between each other, but only via the Kernel. The Kernel imports primitives exported by FUMs and provides primitives which are expected by FUMs. When an operation is requested by one of the FUMs, the Kernel uses the services of other attached FUMs to fulfil the request. The Kernel is also responsible for maintaining a common context between actions ŽFig. 5.. 3.5. Description of FUMs The core activities of the brokerage system include: 1. searching for and Products that fit a user description
Fig. 4. Interfaces of the GAIA functional unit manager.
Fig. 5. GAIA broker Kernel.
2. sourcing Products the identification of which is known 3. allowing users to order Products 4. delivering information in file format 5. delivering information as a continuous media stream 6. providing a user interface to the brokerage services 7. alerting users as to the availability of information 8. interacting with external directory services 9. authentication of other actors 10. payment operations Each of these activities is carried out by the corresponding FUM as described below and shown in the Fig. 6. 3.5.1. Search FUM The Search FUM accepts requests to carry out a search for Products that fit a particular user description. It returns lists of identifiers of Products that fit the description. 3.5.2. Locate FUM The Locate FUM accepts Product identifiers, and discovers where they may be obtained. It returns lists of Suppliers and locations for the Product. 3.5.3. Order FUM The Order FUM manages negotiations between a Customer and a Supplier, in order that agreement may be reached on the terms of availability of a particular Product or group of Products. Following the negotiation phase, the Order FUM accepts purchase commitments from the Customer and forwards them to the Supplier. It returns a notification of the status of the order Action.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
279
Fig. 6. GAIA functional architecture.
3.5.4. Item deliÕery FUM The Item Delivery FUM manages the delivery of file-structured items to the Customer. 3.5.5. Stream deliÕery FUM The Stream Delivery FUM manages the delivery of real-time multimedia data streams to the Customer. 3.5.6. Customer FUM The Customer FUM provides an interface to support the Customer’s systems interaction with the brokerage system. 3.5.7. Alerting FUM The Alerting FUM notifies Customers about changes that may interest them. 3.5.8. Directory serÕices FUM The Directory Services FUM provides an interface between an external directory service and the brokerage system. 3.5.9. Authentication FUM The Authentication FUM provides a mechanism that allows a user to prove his identity to the brokerage system.
3.5.10. Payment FUM The Payment FUM provides a mechanism for payment from one actor to another.
4. Technology mapping This section describes which particular technologies have been chosen to specify and implement interfaces of the GAIA system.
4.1. Internal interfaces The definition of communications between functional components within the GAIA Broker is based on the OMG CORBA model w2x. Interfaces between components are defined on the IDL language, specified by OMG. Interface calls are passed between components by Object Request Broker ŽORB.. The advantage of this approach is that the specifications of the interfaces are platform- and programming-language-independent. These interfaces can be implemented using different programming languages on different platforms. All necessary conversions
280
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
Fig. 7. External protocols and GAIA customer interface.
during interface invocations are transparently performed by an ORB. The CORBA model also allows installing different functional components of the GAIA Broker on different computers connected by a network. Interface calls will be transferred over the network by an ORB transparently for the application. The specification of the interfaces between the Kernel and FUMs and between each FUM and corresponding FUs is presented in the GAIA Standard w1x. 4.2. External protocols The GAIA Broker can use existing protocols to communicate with other actors. For example, it can use HTTP for interactions with Customers, Z39.50 for search, etc. As described in the GAIA Functional Architecture, support of particular technologies is provided by FUs. A set of supported protocols can be extended by attaching corresponding new FUs to a Broker. The GAIA Broker can support several protocols for each action. FUMs will select the most appropriate protocol for a transaction. The more protocols are supported by the Broker, the better service it can provide to Customers and Suppliers. The GAIA Standard does not limit the set of protocols supported by the Broker. However, for the purpose of interoperability, it specifies several GAIA profiles. These profiles aim to define the common subset of protocols Žand a common range of protocol parameters., which is encouraged to be supported by Brokers in order to make possible communications between GAIA Brokers and with GAIA-aware Suppliers and Customers. Existing protocols are not the only way to contact the GAIA Broker. The GAIA interfaces have been
designed as a generalisation of existing interfaces and protocols, so they provide more functionality than any particular protocol. In order to give access to full functionality of the GAIA Broker, the GAIA Standard allows users ŽCustomers and other Brokers. to use directly the CORBA-defined Customer interface of the GAIA Broker Žinterface between Customer FUM and FUs. as shown in Fig. 7. In this case the Customer system gets access to the Customer interface of the Broker using the service of an underlying ORB, and can request operations by calling corresponding methods of the interface. This method allows avoiding convergence between a particular protocol and the GAIA interface. Where Customer and Supplier systems are not CORBA-aware, they can communicate with a GAIA Broker using existing protocols. If, however, they can use the service of an ORB, they are encouraged to communicate with a Broker by connecting to its Customer interface. The former way makes possible interactions with all existing types of Customer and Suppliers, using existing and widespread protocols. The later way has been designed to archive maximum functionality by using native GAIA methods for communications with Customers and Suppliers. 5. GAIA standard profiles 5.1. Introduction to profiles and modules The GAIA Standard defines a number of profiles, which a Broker may support in order to archive interoperability with other GAIA actors ŽCustomer, Supplier and other Brokers.. The complexity of the profile chosen by a Broker depends on the level and
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
type of service which the Broker wishes to deliver in a GAIA-conformant manner. The higher the level of service which a Broker provides to a Customer, and the greater the length of the supply chain which the Broker wishes to support, the more advanced the profile, andror the greater the number of extension modules the Broker must support. The profiles specified are Ø 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 Each Broker must conform at least to the Minimal profile to provide a web-based user interface. In addition, in order to take part in inter-broker communications, the Basic profile is recommended. For interaction with non-CORBA-aware entities, and for the use of advanced services, there are other modules of the standard to which the Broker may conform. These are denoted ‘Extension Modules’, and they characterise the protocols and standards in a particular area of functionality. A Broker can choose an appropriate set of Extension Modules to conform to according to functionality it wishes to achieve. The GAIA Standard specifies all interfaces between FUM and FUs for the GAIA Broker. These interfaces are important only inside the broker system and do not play any role in communication with other GAIA actors. However, a declaration of supported interfaces is important for the administrator to find in which areas the functionality of the Broker can be extended by attaching GAIA-conformant FUs. The GAIA Standard decomposes all interfaces into a number of Interface Modules. A Broker can choose a subset of Interface Modules, which is more important in its area of operation, and implement interfaces defined in these modules. 5.2. Minimal profile Usually a Broker works as a mediator between a Customer and Suppliers. However if the Broker is
281
able to fulfil the request of the Customer by itself, the transaction involves no other actors. In this case, what is required to be standardised at the Broker side is simply a user interface for the Customer. Any further operations take place within the Broker, and so do not come within the scope of the standard. Therefore a Minimal profile is devoted to ensure the possibility of the communication between the Customer and the Broker. It defines protocols which should be implemented by the Broker to communicate with Customers. The Broker can implement any other protocols as well, but the Standard requires the Broker to support at least protocol defined in the Minimal profile. The Minimal profile requires the Broker to implement a user interface based on the HTTP 1.1 protocol w3x, and HTML 2.0 w4x. It means that a Customer should be able to access the basic functionality of the GAIA Broker by using an HTTP 1.1 and HTML 2.0-conformant web-browser. It should be possible for Customers to locate a GAIA Broker. Thus a GAIA Broker should be registered in a Directory Service using a schema specified in the GAIA Standard w1x. 5.3. Basic profile While the minimal functionality is sufficient to allow a Broker to function, an important aspect of any GAIA Broker functionality is dealing with other Brokers. The goal of the Basic profile is to achieve federation between Brokers. Every GAIA Broker can use the service of other GAIA Broker in order to fulfil a request of a Customer. That Broker in turn can use the service of the third GAIA Broker. So every request can be chained by several Brokers. This extends the abilities of every GAIA action ŽSearch, Locate, Order, etc... Chained transactions are particularly important in the discovery phase of a transaction, where a Broker unable to fulfil a particular information requirement, passes on the search to another Broker. The Basic profile requires the Broker to implement the GAIA Customer interface defined in terms of CORBA. This is described in more detail in Section 4.2 above. It also requires the Broker to implement interface requestor procedures, i.e., to be
282
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
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 w2x and use IIOP protocol for inter-ORB communications w2x. The Basic profile is not mandatory. So a GAIAconformant brokerage system can be designed without support of CORBA. However the Broker is strongly encouraged to support the Basic profile in order to be able to fully interoperate with other GAIA Brokers. A full specification of the GAIA Customer interface is presented in the GAIA Standard w1x. A GAIA Broker should be able to find other Brokers and Suppliers. It should also allow other participants to find it. Thus a GAIA Broker should support a directory service. The Basic profile includes a directory access protocol for this purpose. The actual choice of protocol is not standardised,
because the choice does not influence the success of the Broker’s inter-operation with other Brokers. The directory schema, which should be used, is specified in the GAIA Standard. 5.4. Extension modules In order to allow Brokers to interoperate with other Brokers that do not support the Basic profile, and to allow Brokers to deal with Suppliers and Customers who are not CORBA-aware, as well as to allow delivery of items and multimedia streams via the Broker, other open standards are suggested as extensions to the Basic and Minimal profiles. These standards reflect the results of the technology evaluation carried out as part of the project GAIA. The extra protocols are grouped into Extension Modules. Support of these Extension Modules is
Table 1 Extension modules DiscoÕery extension module Searching, locating
Z39.50 w5x Žclient.
Order extension module Order
ISO ILL w6x Žclient.
Item deliÕery extension module FTP profile E-mail profile Document delivery
FTP w7x Žclientq server. Internet E-mail w8,9x Žreceiverq sender., MIME w10–14x GEDI version 3.0
Stream deliÕery extension module Compression Data transfer Mapping Session control protocol
MPEG-2 Audio Layer 3 w15x RTP w16x Žclientq server. RTP Audio Video Profile w17x RTCP w16x
Security extension module Privacy, integrity, non-repudiation Remote, clientrserver authentication Certification services
SSL v 3.0 w18x, PKCS a7 w19x GSS v5 w20x PKIX certification protocol w21x
Payment extension module Payment
SET v 1.0 w22x: Ž1. CA server for banks; Ž2. Cardholder wallet; Ž3. Merchant server; Ž4. Payment gateway server
Alerting extension module Alerting
Internet E-mail w8,9x Žsender., SMS w23x
Customer discoÕery extension module Searching, locating
Z39.50 w5x Žserver.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
optional. A Broker can choose an appropriate set of Extension Modules to conform to according to the functionality it wishes to achieve. There is one Extension Module for each of the functional areas which are not covered by the Basic and Minimal Profiles, and also one Extension Module for each of the existing areas ŽCustomer, Discovery and Order. to allow the use of protocols other than GAIA abstract primitives Ø Discovery Extension Module — This module selects the protocols to be used to carry out search and locate actions. Ø Order Extension Module—This Extension Module specifies the protocols for ordering the products from Suppliers. Ø Item Delivery Extension Module—This Extension Module describes which protocols should be used by the Broker to deliver on-line products and services to the Customer. Ø Stream Delivery Extension Module—This module is intended to support real-time delivery of multimedia by the GAIA Broker. Ø Security Extension Module—This module allows a Broker to secure communications with other participants. It provides channel security, authentication, and certificate exchange. Ø Payment Extension Module—This Extension Module allows a Broker to perform electronic payment operations with Customers, Suppliers and other Brokers. Ø Alerting Extension Module—This module specifies the protocols to notify Customers about changes that can be interesting for them. Ø Customer Discovery Extension Module—The Customer Discovery Extension Module allows Z39.50 clients to use the service of the GAIA Broker. The GAIA Standard contains a detailed specification of every of the above Extension Modules. Here we will include only a brief list of protocols selected in each module Žsee Table 1.. 5.5. Interface modules For the purpose of conformance all interfaces between FUM and FUs, specified by the GAIA Standard, are grouped into GAIA Interface Modules. These modules are recommended to be supported by
283
Table 2 Interface modules Interface module
Interfaces that are required to be supported in this module
Search Locate Order Item delivery Stream delivery Alerting Directory services Authentication Payment
Search FU interface Locate FU interface Order FU interface Item Delivery FU interface Stream Delivery FU interface Alerting FU interface Directory Services FU interface Authentication FU interface Payment FU interface
a GAIA Broker, but they are not mandatory. A Broker can choose a subset of Interface Modules, which is more important in its area of operation, and implement interfaces defined in these modules. Table 2 defines Interface Modules and specifies, which interfaces have to be supported in each of them.
6. Implementation and trials In order to validate the designed architecture the core modules of the architecture were implemented and tested. This helped to reveal some mismatches in the first version of the interface specification and to correct an original division into functional modules. The experience obtained during implementation and testing was accommodated into the final version of the GAIA architecture presented in this paper. As a next step of the validation, three brokerage systems were implemented according to the designed GAIA architecture. These brokerage systems were specialised in three different domains: music, technical data and publishing. The public trials of the brokerage systems were launched on October 98. During the trials the brokerage systems offer products from a number of real suppliers in each of the three domains to the real users connected by the Internet. These trials aim to prove the broad applicability of the GAIA architecture. The public GAIA trials are currently in progress. Feedback from suppliers and customers is collected. The results of the trials will be used to evaluate the designed architecture.
284
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
7. Conclusion The architecture for the information brokerage introduced in this paper allows to create a brokerage system that can assist a customer on the electronic market. This architecture covers all phases of the trading process. The modular structure described in the functional architecture allows the broker to use different existing technologies for communication with customers and suppliers. The GAIA Standard includes profiles that specify requirements to achieve interoperability between actors. It is our belief that this brokerage architecture will be of significant assistance to anyone wanting to design and implement a brokerage system for electronic trading.
Acknowledgements We wish to express our gratitude to the EU’s ACTS programme for Research and Technological Development and Teltec Ireland for their sponsorship. We also wish to thank the GAIA Consortium for very lively discussion and their direct and indirect input in the process of design of the GAIA Standard.
References w1x GAIA Consortium, Deliverable 0403, GAIA Standard, December 1998. w2x Object Management Group, CORBA 2.0 Specification, July 1996, See ²ftp:rrftp.omg.orgrpubrdocsrformalr 97-02-25.pdf:. w3x R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, Hypertext Transfer Protocol, HTTPr1.1, RFC 2068, January 1997. w4x T. Berners-Lee, D. Connolly, Hypertext Markup Language, 2.0, RFC 1866, November 1995. w5x ANSIrNISO Z39.50-1995 or ISO 23950, Information Retrieval: Application Service Definition and Protocol Specification.
w6x ISO 10161, Information and documentation—Open Systems Interconnection—Interlibrary Loan Application Protocol Specification, 1997. w7x J. Postel, J.K. Reynolds, File Transfer Protocol, RFC 959, October 1985. w8x J. Postel, Simple Mail Transfer Protocol, RFC 821, August 1982. w9x D. Crocker, Standard for the format of ARPA Internet text messages, RFC 822, August 1982. w10x N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions ŽMIME. Part One: Format of Internet Message Bodies, RFC 2045, November 1996. w11x N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions ŽMIME. Part Two: Media Types, RFC 2046, November 1996. w12x K. Moore, MIME ŽMultipurpose Internet Mail Extensions. Part Three: Message Header Extensions for Non-ASCII Text, RFC 2047, November 1996. w13x N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail Extensions ŽMIME. Part Four: Registration Procedures, RFC 2048, November 1996. w14x N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions ŽMIME. Part Five: Conformance Criteria and Examples, RFC 2049, November 1996. w15x ISOrIEC 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. w16x H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, Audio-Video Transport Working Group, January 1996. w17x H. Schulzrinne, RTP Profile for Audio and Video Conferences with Minimal Control, RFC 1890, Audio-Video Transport Working Group, January 1996. w18x A. Freier, P. Karlton, P. Kocher, The SSL Protocol—Version 3.0, INTERNET-DRAFT, Transport Layer Security Working Group, November 1996, See ²http:rrhome.netscape.comrengrssl3rindex.html:. w19x PKCS a7: Cryptographic Message Syntax Standard. Version 1.5, November 1993. w20x J. Linn, Generic Security Service Application Program Interface, RFC 1508, Geer Zolot Associate, September 1993. w21x Public-Key Infrastructure ŽX.509. IETF Working Group, ² http:rrwww.ietf.orgrhtml.chartersrpkix-charter.html:, July 98. w22x SET Secure Electronic Transaction Specification, Version 1.0, MasterCard and Visa, May 97. w23x Digital Cellular Telecommunications System ŽPhase 2q.: 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.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285 Ahmed Patel is the Director of the research group, he received his MS and PhD degrees from Trinity College of Dublin in 1978 and 1984 respectively. He is currently a senior lecturer in the Department of Computer Science, University of Dublin ŽUCD.. His research interests include international networking standards, security, ISDN, high speed networks, brokerage, and distributed operating systems and applications. He has a wide range of experience in industrial telecommunications and security consultancy, working with major industrial partners in international academic R & D. He has been actively involved in many pan-European R & D programmes, including RARE, COSINE, ACTS, ESPRIT, TELEMATICS, INFOSEC, etc. and as a participant and a reviewer of many Framework projects. He is also a member of the Computer Communications journal. Mikhail Blinov is currently a full time PhD researcher in the Department of Computer Science, UCD. He received his MS Degree from St. Petersburg State University in 1993. Prior to joining UCD he carried design and implementation of the multiprotocol network router for Open System in Russia. His research interests include stream delivery distributed applications, network management, and information brokerage.
285
Mikhail Bessonov is currently a Research Officer in Teltec UCD-CS. He is also reading for his PhD in UCD in the area information retrieval and brokerage. He received his MS degree from St. Petersburg State University in 1993. Prior to joining UCD he carried out design and implementation of the multiprotocol network router for Open System in Russia. His research interests include distributed applications, electronic brokerage, information retrieval.
Reference model and functional architecture for information availability Ahmed Patel ) , Mikhail Blinov 1, Mikhail Bessonov
2
Computer Networks and Distributed Systems Research Group, UniÕersity College Dublin, Belfield, Dublin 4, Ireland Received 7 December 1998; accepted 16 February 1999
Abstract This paper presents a domain and supplier independent generic architecture for the information brokerage, designed as a part of the EU ACTS R & D project GAIA ŽGeneric Architecture for Information Availability.. The GAIA Architecture provides a common framework for developers of the brokerage systems. This paper describes a Reference Model which defines actors involved in the information trading and actions that constitute the trading process. It introduces a modular Functional Architecture which covers the functionality of the brokerage system and allows to incorporate different existing technologies into the broker. It specifies a set of profiles which ensure an interoperability of the broker with other brokers, and with customers and suppliers. This architecture has been verified by the reference implementation of the GAIA brokerage system and by public trials in three different domains: music, technical data of computer components, and publishing. This architecture will be published as a GAIA Standard at the end of the GAIA project. q 1999 Elsevier Science B.V. All rights reserved. Keywords: Electronic trading; Brokerage; Information architecture; Reference model; Standard
1. Introduction One of the characteristics of the current state of the electronic market, that limit its growth, is a lack of mediation services. In the old model of the market that is still in use today customers are supposed to search for the desired product by themselves and communicate with suppliers directly. This model was designed when the electronic market was relatively
)
Corresponding author. Tel.: q353-1-706-2476; fax: q353-1269-7262; e-mail: [email protected] 1 E-mail: [email protected] 2 E-mail: [email protected]
small. However, the electronic market has been growing rapidly in the past few years. Now it offers for customers a huge number of products, available from a large number of suppliers. The problem is that there is still no efficient and scalable method for customers and suppliers to find each other. High heterogeneity of existing protocols, formats and underlying networks also limits development of the electronic market. These problems can be solved by brokerage systems, which can work as intermediary entities between customers and content suppliers. Brokerage systems can assist a customer during the trading process and hide heterogeneity and distribution of information from the customer. The design of do-
0920-5489r99r$ - see front matter q 1999 Elsevier Science B.V. All rights reserved. PII: S 0 9 2 0 - 5 4 8 9 Ž 9 9 . 0 0 0 0 6 - 9
274
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
main and supplier independent generic architecture for such brokerage systems is an objective of the project GAIA ŽGeneric Architecture for Information Availability.. The GAIA brokerage system allows a customer to Ø search for a product Žinformation, content or services. of hisrher interest Ø locate the product, which means find a set of suppliers, where this product is available from Ø order the product from the chosen supplier Ø request to deliver the product The broker can carry out all these actions on behalf of the customer. The broker can use trade protocols that are convenient for suppliers to get information about products, and use protocols that are convenient for customer to present this information. Full specification of the GAIA Architecture is available in the GAIA Standard w1x, which is due to be published in December 1998. The GAIA Standard includes a description of the GAIA Reference Model, GAIA Functional Architecture, GAIA Standard Profiles, and specification of the GAIA interfaces. This paper presents basic ideas and concepts of this standard.
2. The GAIA reference model The Generic Architecture for Information Availability ŽGAIA. Reference Model outlines the operations and actors involved in finding, ordering and delivering physical and digital objects and services Ž‘Products’. in a global brokered distributed information environment. It provides an overall view of the GAIA environment, and illustrates the respective roles of and relationships between its components. Further work on standards and frameworks for individual components of the GAIA environment uses the model and terminology provided by the Reference Model. The GAIA environment is a collection of actors and functions that are combined to support a procedure for information and services discovery, order and delivery. The actors play roles in the procedure, including initiation and execution of the Actions which are combined to make up the overall transaction. The GAIA architecture provides a standardised and widely applicable framework for the provision
and implementation of the brokered search and retrieve applications in a large-scale networked environment. 2.1. GAIA roles The GAIA model introduces three principal roles, which can be played by the GAIA actors. These are the Customer, the Broker and the Supplier. The actors are organisations and individuals in the supply chain. Every GAIA actor plays at least one role at any given time. The model also introduces a number of supporting roles, such as authentication or payment, which provide an additional functionality in the GAIA Actions. Supporting roles are played by GAIA ‘Helpers’. 2.1.1. The Customer The Customer role initiates the GAIA transaction by requesting one or more GAIA Actions, and receives the results of the transaction. The aim of the Customer is to obtain some Products or information about some Products. The Customer may deal with actors playing either of the other two roles, the Broker or the Supplier. These actors may themselves play the role of the Customer while requesting further services from other Brokers. 2.1.2. The Broker The Broker responds to requests from the Customer to provide Products, or information about Products. These Products, or information about them, are collected by the Broker from a number of Suppliers. The services provided by a Broker obviate the need for the Customer to deal with a variety of Suppliers. The Broker can use services of other Brokers in order to fulfil requests of the Customer. 2.1.3. The Supplier The Supplier is the source of the Products supplied to the Customer. The Supplier provides the Broker with information about the Products that it can supply. The Supplier may supply its Products directly to the Customer, or to the Broker, for forwarding to the Customer. An actor playing the role of a Supplier may also play the role of a Broker. A Supplier may deal with a large number of Brokers and Customers, over a number of GAIA transactions.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
2.1.4. Helpers A Helper is an application layer entity playing a supporting role in a GAIA transaction. Helpers provide some service needed in the supply chain, but outside the core functionality of the Broker. Examples include a global directory service or payment service or authentication service. The authentication Helper is concerned with facilitating the authentication of one actor to another. The payment Helper provides a mechanism for payment operations between actors. In any given GAIA transaction, there will be one or more Customers Žusually one., one or more Brokers, and one or more Suppliers. 2.2. GAIA actions Each GAIA transaction is made up of one or more Actions. These Actions are requests by the Customer to the Broker or the Supplier to carry out some operation, and to respond to the Customer. Four Actions are defined in the GAIA Standard Žsee Fig. 1. Ø Search Ø Locate Ø Order Ø Deliver 2.2.1. Search The Search Action is carried out by the Broker when the Customer asks to find some information on
275
its behalf. In order to do this, the Customer provides the Broker with some description of the Product which it requires. The Broker carries out a search of the products that matches the description and returns the result to the Customer. The result of a Search Action is a set of unique identifiers of the found Products. It does not include information about where these products can be obtained. 2.2.2. Locate The Locate Action is carried out when the Customer asks the Broker to provide it with information regarding the location and source of some Product. In order to allow the Broker to do this, the Customer provides an unambiguous identification of the Product, which may be the result of a Search Action. The Broker returns information to the Customer about a source or sources for the Product. These data include the Terms of Availability information such as methods of delivery available, time of delivery, costs, etc. However, this information cannot be considered final, since some special terms and conditions may apply, e.g., discounts for some categories of Customers. The final version of the Terms of Availability is established during the negotiation phase of the Order Action. 2.2.3. Order The Order Action is carried out when the Customer asks the Broker to obtain a Product on its behalf, or asks the Supplier to sell the Product
Fig. 1. GAIA roles and actions.
276
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
directly to the Customer. To enable Order, the Customer provides the BrokerrSupplier with Product source information, which may be a result of a Locate Action. The Order Action consists of a negotiation phase and Žpossibly. a purchase phase. During the negotiation phase the Customer obtains the quotation which contains the final version of the Terms of Availability for the Product or a batch of Products he is considering purchasing. If the Customer finds these conditions satisfactory, he commits to the purchase. Alternatively the Customer can negotiate another conditions with the Supplier directly or through the Broker. 2.2.4. DeliÕer The Deliver Action is carried out when the Customer asks the Broker to deliver the chosen Product. The Product may be information, some physical object or metadata. In order to allow the Broker to do this, the Customer provides an unambiguous identification of the Product together with its location. The Deliver Action is usually in response to an Order Action. While the Actions presented in this section may logically be taken to form an integrated sequence, this is not necessarily the case. Actions may take place independently, rather than as a section of a four-Action whole. For example, Order and Deliver Actions may occur on the basis of information obtained by the Customer using some other mechanism than GAIA Search and Locate Actions. 2.3. GAIA helper eÕents During any of the GAIA Actions outlined above, it may be necessary to carry out some supporting activity. These activities are called GAIA Helper events. Examples of such events are authentication and payment. The Helper entities are involved in the GAIA events to provide services, additional to the GAIA Actions, to the GAIA actors. 2.3.1. Authentication Some actions can require a verification of the identity of one GAIA actor to another. In this case an authentication exchange may need to take place. The services for the authentication are provided by an
Authentication Helper. The manner or method of authentication is outside the scope of this document. 2.3.2. Payment It may be necessary for payment to take place during a GAIA transaction. In this situation, one GAIA actor pays one or more other GAIA actors. This is provided by a Payment Helper. The manner or method of payment is outside the scope of this document. 2.3.3. Security As part of any GAIA Action, it may be necessary to carry out some security operations, such as encryption of data, verification of source and content integrity of Product, or digital signature of some data entity or entities. These services are provided by a Security Helper. The particular security services and mechanisms which may be required, or the manner, in which they may be provided, is outside the scope of this document.
3. The GAIA functional architecture 3.1. The concept The GAIA Functional Architecture decomposes the overall functionality of the GAIA Broker into a number of components, and describes the roles and relationships of the components, and the manner in which they interoperate. In order to work in a heterogeneous environment the GAIA Functional Architecture introduces three levels of abstract elements of the Broker: the Kernel, Functional Unit Managers ŽFUMs., and Functional Units ŽFUs. Žsee Fig. 2.. All technology dependent algorithms and procedures are contained in Functional Units. FUs are the only technology-dependent parts of the architecture. They are responsible for performing required transactions in terms of a particular protocol. FUs are grouped according to the trading action they participate in, e.g., search FUs or locate FUs. All FUs from the same group are covered by the same technologyindependent interface. Each group of FUs is governed by the corresponding Functional Unit Manager.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
277
Fig. 2. Levels of the architecture of the GAIA broker.
Functional Unit Managers contain technology independent functions for particular trading actions. In order to use a particular technology, FUM uses the services of attached FUs. There may be several FUs associated with a FUM, allowing the FUM to operate in different technology contexts. There is one FUM in the system for every area of functionality, e.g. search, locate, and order. The Kernel is the highest level in the architecture. It is responsible for managing the activity of different FUMs Žcorresponding to different trading actions. and synchronising events between them. It is expected that a set of technologies, which are required to be supported by the Broker to communicate with Customers and Suppliers, is not permanent. New technologies will evolve. The abstract and modular nature of the Functional Architecture allows the replacement of one technology with a new one without disruption to the rest of the brokerage system. 3.2. Functional units Each of the functions of the brokerage system can be provided by a number of different candidate technologies. However, the actual operations that are required to be carried out remain the same regardless of the selected technologies. These operations are described in terms of abstract primitives, which can be mapped to the protocol instructions of the technology selected to support the function. A set of the abstract primitives is defined for each of the functional areas of the brokerage system. A mapping between abstract primitives and actual technology is performed by a Functional Unit ŽFU. component. A FU is defined for each candidate technology that can
be used to fulfil a particular functional need of the brokerage system, and 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. A Functional Unit accepts abstract primitive invocations, and maps them to calls to the particular technology to which it is dedicated. The results of these calls are translated into the corresponding abstract primitives and returned by the FU, as shown in Fig. 3. 3.3. Functional unit managers A number of different Functional Units can exist which fulfil the same functional requirement of the brokerage system, but using different underlying technologies. For any particular transaction the brokerage system should select the most appropriate technology Žrepresented by a FU.. This is the responsibility of the Functional Unit Manager, or FUM. Each functional area of the brokerage system has a single FUM, which is invoked in terms of abstract primitives by the Broker Kernel. This FUM selects
Fig. 3. Interfaces of the GAIA functional unit.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
278
the most appropriate of the candidate technologies, and calls the corresponding FU ŽFig. 4.. The interface between the FUM and the corresponding FUs is defined for every FUM in an open, platform-independent, programming-language independent manner. These interfaces do not depend on any particular technology. It allows configuring the set of technologies, supported by the Broker, by attaching different subsets of FUs. If a new technology is to be supported by the Broker, a new FU implementing this technology can be created according to the specification of the interface and attached to the corresponding FUM. 3.4. The kernel The Kernel is responsible for synchronisation of events between different actions Ždifferent FUMs.. According to the GAIA Functional Architecture FUMs do not have direct connections between each other, but only via the Kernel. The Kernel imports primitives exported by FUMs and provides primitives which are expected by FUMs. When an operation is requested by one of the FUMs, the Kernel uses the services of other attached FUMs to fulfil the request. The Kernel is also responsible for maintaining a common context between actions ŽFig. 5.. 3.5. Description of FUMs The core activities of the brokerage system include: 1. searching for and Products that fit a user description
Fig. 4. Interfaces of the GAIA functional unit manager.
Fig. 5. GAIA broker Kernel.
2. sourcing Products the identification of which is known 3. allowing users to order Products 4. delivering information in file format 5. delivering information as a continuous media stream 6. providing a user interface to the brokerage services 7. alerting users as to the availability of information 8. interacting with external directory services 9. authentication of other actors 10. payment operations Each of these activities is carried out by the corresponding FUM as described below and shown in the Fig. 6. 3.5.1. Search FUM The Search FUM accepts requests to carry out a search for Products that fit a particular user description. It returns lists of identifiers of Products that fit the description. 3.5.2. Locate FUM The Locate FUM accepts Product identifiers, and discovers where they may be obtained. It returns lists of Suppliers and locations for the Product. 3.5.3. Order FUM The Order FUM manages negotiations between a Customer and a Supplier, in order that agreement may be reached on the terms of availability of a particular Product or group of Products. Following the negotiation phase, the Order FUM accepts purchase commitments from the Customer and forwards them to the Supplier. It returns a notification of the status of the order Action.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
279
Fig. 6. GAIA functional architecture.
3.5.4. Item deliÕery FUM The Item Delivery FUM manages the delivery of file-structured items to the Customer. 3.5.5. Stream deliÕery FUM The Stream Delivery FUM manages the delivery of real-time multimedia data streams to the Customer. 3.5.6. Customer FUM The Customer FUM provides an interface to support the Customer’s systems interaction with the brokerage system. 3.5.7. Alerting FUM The Alerting FUM notifies Customers about changes that may interest them. 3.5.8. Directory serÕices FUM The Directory Services FUM provides an interface between an external directory service and the brokerage system. 3.5.9. Authentication FUM The Authentication FUM provides a mechanism that allows a user to prove his identity to the brokerage system.
3.5.10. Payment FUM The Payment FUM provides a mechanism for payment from one actor to another.
4. Technology mapping This section describes which particular technologies have been chosen to specify and implement interfaces of the GAIA system.
4.1. Internal interfaces The definition of communications between functional components within the GAIA Broker is based on the OMG CORBA model w2x. Interfaces between components are defined on the IDL language, specified by OMG. Interface calls are passed between components by Object Request Broker ŽORB.. The advantage of this approach is that the specifications of the interfaces are platform- and programming-language-independent. These interfaces can be implemented using different programming languages on different platforms. All necessary conversions
280
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
Fig. 7. External protocols and GAIA customer interface.
during interface invocations are transparently performed by an ORB. The CORBA model also allows installing different functional components of the GAIA Broker on different computers connected by a network. Interface calls will be transferred over the network by an ORB transparently for the application. The specification of the interfaces between the Kernel and FUMs and between each FUM and corresponding FUs is presented in the GAIA Standard w1x. 4.2. External protocols The GAIA Broker can use existing protocols to communicate with other actors. For example, it can use HTTP for interactions with Customers, Z39.50 for search, etc. As described in the GAIA Functional Architecture, support of particular technologies is provided by FUs. A set of supported protocols can be extended by attaching corresponding new FUs to a Broker. The GAIA Broker can support several protocols for each action. FUMs will select the most appropriate protocol for a transaction. The more protocols are supported by the Broker, the better service it can provide to Customers and Suppliers. The GAIA Standard does not limit the set of protocols supported by the Broker. However, for the purpose of interoperability, it specifies several GAIA profiles. These profiles aim to define the common subset of protocols Žand a common range of protocol parameters., which is encouraged to be supported by Brokers in order to make possible communications between GAIA Brokers and with GAIA-aware Suppliers and Customers. Existing protocols are not the only way to contact the GAIA Broker. The GAIA interfaces have been
designed as a generalisation of existing interfaces and protocols, so they provide more functionality than any particular protocol. In order to give access to full functionality of the GAIA Broker, the GAIA Standard allows users ŽCustomers and other Brokers. to use directly the CORBA-defined Customer interface of the GAIA Broker Žinterface between Customer FUM and FUs. as shown in Fig. 7. In this case the Customer system gets access to the Customer interface of the Broker using the service of an underlying ORB, and can request operations by calling corresponding methods of the interface. This method allows avoiding convergence between a particular protocol and the GAIA interface. Where Customer and Supplier systems are not CORBA-aware, they can communicate with a GAIA Broker using existing protocols. If, however, they can use the service of an ORB, they are encouraged to communicate with a Broker by connecting to its Customer interface. The former way makes possible interactions with all existing types of Customer and Suppliers, using existing and widespread protocols. The later way has been designed to archive maximum functionality by using native GAIA methods for communications with Customers and Suppliers. 5. GAIA standard profiles 5.1. Introduction to profiles and modules The GAIA Standard defines a number of profiles, which a Broker may support in order to archive interoperability with other GAIA actors ŽCustomer, Supplier and other Brokers.. The complexity of the profile chosen by a Broker depends on the level and
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
type of service which the Broker wishes to deliver in a GAIA-conformant manner. The higher the level of service which a Broker provides to a Customer, and the greater the length of the supply chain which the Broker wishes to support, the more advanced the profile, andror the greater the number of extension modules the Broker must support. The profiles specified are Ø 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 Each Broker must conform at least to the Minimal profile to provide a web-based user interface. In addition, in order to take part in inter-broker communications, the Basic profile is recommended. For interaction with non-CORBA-aware entities, and for the use of advanced services, there are other modules of the standard to which the Broker may conform. These are denoted ‘Extension Modules’, and they characterise the protocols and standards in a particular area of functionality. A Broker can choose an appropriate set of Extension Modules to conform to according to functionality it wishes to achieve. The GAIA Standard specifies all interfaces between FUM and FUs for the GAIA Broker. These interfaces are important only inside the broker system and do not play any role in communication with other GAIA actors. However, a declaration of supported interfaces is important for the administrator to find in which areas the functionality of the Broker can be extended by attaching GAIA-conformant FUs. The GAIA Standard decomposes all interfaces into a number of Interface Modules. A Broker can choose a subset of Interface Modules, which is more important in its area of operation, and implement interfaces defined in these modules. 5.2. Minimal profile Usually a Broker works as a mediator between a Customer and Suppliers. However if the Broker is
281
able to fulfil the request of the Customer by itself, the transaction involves no other actors. In this case, what is required to be standardised at the Broker side is simply a user interface for the Customer. Any further operations take place within the Broker, and so do not come within the scope of the standard. Therefore a Minimal profile is devoted to ensure the possibility of the communication between the Customer and the Broker. It defines protocols which should be implemented by the Broker to communicate with Customers. The Broker can implement any other protocols as well, but the Standard requires the Broker to support at least protocol defined in the Minimal profile. The Minimal profile requires the Broker to implement a user interface based on the HTTP 1.1 protocol w3x, and HTML 2.0 w4x. It means that a Customer should be able to access the basic functionality of the GAIA Broker by using an HTTP 1.1 and HTML 2.0-conformant web-browser. It should be possible for Customers to locate a GAIA Broker. Thus a GAIA Broker should be registered in a Directory Service using a schema specified in the GAIA Standard w1x. 5.3. Basic profile While the minimal functionality is sufficient to allow a Broker to function, an important aspect of any GAIA Broker functionality is dealing with other Brokers. The goal of the Basic profile is to achieve federation between Brokers. Every GAIA Broker can use the service of other GAIA Broker in order to fulfil a request of a Customer. That Broker in turn can use the service of the third GAIA Broker. So every request can be chained by several Brokers. This extends the abilities of every GAIA action ŽSearch, Locate, Order, etc... Chained transactions are particularly important in the discovery phase of a transaction, where a Broker unable to fulfil a particular information requirement, passes on the search to another Broker. The Basic profile requires the Broker to implement the GAIA Customer interface defined in terms of CORBA. This is described in more detail in Section 4.2 above. It also requires the Broker to implement interface requestor procedures, i.e., to be
282
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
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 w2x and use IIOP protocol for inter-ORB communications w2x. The Basic profile is not mandatory. So a GAIAconformant brokerage system can be designed without support of CORBA. However the Broker is strongly encouraged to support the Basic profile in order to be able to fully interoperate with other GAIA Brokers. A full specification of the GAIA Customer interface is presented in the GAIA Standard w1x. A GAIA Broker should be able to find other Brokers and Suppliers. It should also allow other participants to find it. Thus a GAIA Broker should support a directory service. The Basic profile includes a directory access protocol for this purpose. The actual choice of protocol is not standardised,
because the choice does not influence the success of the Broker’s inter-operation with other Brokers. The directory schema, which should be used, is specified in the GAIA Standard. 5.4. Extension modules In order to allow Brokers to interoperate with other Brokers that do not support the Basic profile, and to allow Brokers to deal with Suppliers and Customers who are not CORBA-aware, as well as to allow delivery of items and multimedia streams via the Broker, other open standards are suggested as extensions to the Basic and Minimal profiles. These standards reflect the results of the technology evaluation carried out as part of the project GAIA. The extra protocols are grouped into Extension Modules. Support of these Extension Modules is
Table 1 Extension modules DiscoÕery extension module Searching, locating
Z39.50 w5x Žclient.
Order extension module Order
ISO ILL w6x Žclient.
Item deliÕery extension module FTP profile E-mail profile Document delivery
FTP w7x Žclientq server. Internet E-mail w8,9x Žreceiverq sender., MIME w10–14x GEDI version 3.0
Stream deliÕery extension module Compression Data transfer Mapping Session control protocol
MPEG-2 Audio Layer 3 w15x RTP w16x Žclientq server. RTP Audio Video Profile w17x RTCP w16x
Security extension module Privacy, integrity, non-repudiation Remote, clientrserver authentication Certification services
SSL v 3.0 w18x, PKCS a7 w19x GSS v5 w20x PKIX certification protocol w21x
Payment extension module Payment
SET v 1.0 w22x: Ž1. CA server for banks; Ž2. Cardholder wallet; Ž3. Merchant server; Ž4. Payment gateway server
Alerting extension module Alerting
Internet E-mail w8,9x Žsender., SMS w23x
Customer discoÕery extension module Searching, locating
Z39.50 w5x Žserver.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
optional. A Broker can choose an appropriate set of Extension Modules to conform to according to the functionality it wishes to achieve. There is one Extension Module for each of the functional areas which are not covered by the Basic and Minimal Profiles, and also one Extension Module for each of the existing areas ŽCustomer, Discovery and Order. to allow the use of protocols other than GAIA abstract primitives Ø Discovery Extension Module — This module selects the protocols to be used to carry out search and locate actions. Ø Order Extension Module—This Extension Module specifies the protocols for ordering the products from Suppliers. Ø Item Delivery Extension Module—This Extension Module describes which protocols should be used by the Broker to deliver on-line products and services to the Customer. Ø Stream Delivery Extension Module—This module is intended to support real-time delivery of multimedia by the GAIA Broker. Ø Security Extension Module—This module allows a Broker to secure communications with other participants. It provides channel security, authentication, and certificate exchange. Ø Payment Extension Module—This Extension Module allows a Broker to perform electronic payment operations with Customers, Suppliers and other Brokers. Ø Alerting Extension Module—This module specifies the protocols to notify Customers about changes that can be interesting for them. Ø Customer Discovery Extension Module—The Customer Discovery Extension Module allows Z39.50 clients to use the service of the GAIA Broker. The GAIA Standard contains a detailed specification of every of the above Extension Modules. Here we will include only a brief list of protocols selected in each module Žsee Table 1.. 5.5. Interface modules For the purpose of conformance all interfaces between FUM and FUs, specified by the GAIA Standard, are grouped into GAIA Interface Modules. These modules are recommended to be supported by
283
Table 2 Interface modules Interface module
Interfaces that are required to be supported in this module
Search Locate Order Item delivery Stream delivery Alerting Directory services Authentication Payment
Search FU interface Locate FU interface Order FU interface Item Delivery FU interface Stream Delivery FU interface Alerting FU interface Directory Services FU interface Authentication FU interface Payment FU interface
a GAIA Broker, but they are not mandatory. A Broker can choose a subset of Interface Modules, which is more important in its area of operation, and implement interfaces defined in these modules. Table 2 defines Interface Modules and specifies, which interfaces have to be supported in each of them.
6. Implementation and trials In order to validate the designed architecture the core modules of the architecture were implemented and tested. This helped to reveal some mismatches in the first version of the interface specification and to correct an original division into functional modules. The experience obtained during implementation and testing was accommodated into the final version of the GAIA architecture presented in this paper. As a next step of the validation, three brokerage systems were implemented according to the designed GAIA architecture. These brokerage systems were specialised in three different domains: music, technical data and publishing. The public trials of the brokerage systems were launched on October 98. During the trials the brokerage systems offer products from a number of real suppliers in each of the three domains to the real users connected by the Internet. These trials aim to prove the broad applicability of the GAIA architecture. The public GAIA trials are currently in progress. Feedback from suppliers and customers is collected. The results of the trials will be used to evaluate the designed architecture.
284
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285
7. Conclusion The architecture for the information brokerage introduced in this paper allows to create a brokerage system that can assist a customer on the electronic market. This architecture covers all phases of the trading process. The modular structure described in the functional architecture allows the broker to use different existing technologies for communication with customers and suppliers. The GAIA Standard includes profiles that specify requirements to achieve interoperability between actors. It is our belief that this brokerage architecture will be of significant assistance to anyone wanting to design and implement a brokerage system for electronic trading.
Acknowledgements We wish to express our gratitude to the EU’s ACTS programme for Research and Technological Development and Teltec Ireland for their sponsorship. We also wish to thank the GAIA Consortium for very lively discussion and their direct and indirect input in the process of design of the GAIA Standard.
References w1x GAIA Consortium, Deliverable 0403, GAIA Standard, December 1998. w2x Object Management Group, CORBA 2.0 Specification, July 1996, See ²ftp:rrftp.omg.orgrpubrdocsrformalr 97-02-25.pdf:. w3x R. Fielding, J. Gettys, J. Mogul, H. Frystyk, T. Berners-Lee, Hypertext Transfer Protocol, HTTPr1.1, RFC 2068, January 1997. w4x T. Berners-Lee, D. Connolly, Hypertext Markup Language, 2.0, RFC 1866, November 1995. w5x ANSIrNISO Z39.50-1995 or ISO 23950, Information Retrieval: Application Service Definition and Protocol Specification.
w6x ISO 10161, Information and documentation—Open Systems Interconnection—Interlibrary Loan Application Protocol Specification, 1997. w7x J. Postel, J.K. Reynolds, File Transfer Protocol, RFC 959, October 1985. w8x J. Postel, Simple Mail Transfer Protocol, RFC 821, August 1982. w9x D. Crocker, Standard for the format of ARPA Internet text messages, RFC 822, August 1982. w10x N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions ŽMIME. Part One: Format of Internet Message Bodies, RFC 2045, November 1996. w11x N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions ŽMIME. Part Two: Media Types, RFC 2046, November 1996. w12x K. Moore, MIME ŽMultipurpose Internet Mail Extensions. Part Three: Message Header Extensions for Non-ASCII Text, RFC 2047, November 1996. w13x N. Freed, J. Klensin, J. Postel, Multipurpose Internet Mail Extensions ŽMIME. Part Four: Registration Procedures, RFC 2048, November 1996. w14x N. Freed, N. Borenstein, Multipurpose Internet Mail Extensions ŽMIME. Part Five: Conformance Criteria and Examples, RFC 2049, November 1996. w15x ISOrIEC 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. w16x H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A Transport Protocol for Real-Time Applications, RFC 1889, Audio-Video Transport Working Group, January 1996. w17x H. Schulzrinne, RTP Profile for Audio and Video Conferences with Minimal Control, RFC 1890, Audio-Video Transport Working Group, January 1996. w18x A. Freier, P. Karlton, P. Kocher, The SSL Protocol—Version 3.0, INTERNET-DRAFT, Transport Layer Security Working Group, November 1996, See ²http:rrhome.netscape.comrengrssl3rindex.html:. w19x PKCS a7: Cryptographic Message Syntax Standard. Version 1.5, November 1993. w20x J. Linn, Generic Security Service Application Program Interface, RFC 1508, Geer Zolot Associate, September 1993. w21x Public-Key Infrastructure ŽX.509. IETF Working Group, ² http:rrwww.ietf.orgrhtml.chartersrpkix-charter.html:, July 98. w22x SET Secure Electronic Transaction Specification, Version 1.0, MasterCard and Visa, May 97. w23x Digital Cellular Telecommunications System ŽPhase 2q.: 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.
A. Patel et al.r Computer Standards & Interfaces 21 (1999) 273–285 Ahmed Patel is the Director of the research group, he received his MS and PhD degrees from Trinity College of Dublin in 1978 and 1984 respectively. He is currently a senior lecturer in the Department of Computer Science, University of Dublin ŽUCD.. His research interests include international networking standards, security, ISDN, high speed networks, brokerage, and distributed operating systems and applications. He has a wide range of experience in industrial telecommunications and security consultancy, working with major industrial partners in international academic R & D. He has been actively involved in many pan-European R & D programmes, including RARE, COSINE, ACTS, ESPRIT, TELEMATICS, INFOSEC, etc. and as a participant and a reviewer of many Framework projects. He is also a member of the Computer Communications journal. Mikhail Blinov is currently a full time PhD researcher in the Department of Computer Science, UCD. He received his MS Degree from St. Petersburg State University in 1993. Prior to joining UCD he carried design and implementation of the multiprotocol network router for Open System in Russia. His research interests include stream delivery distributed applications, network management, and information brokerage.
285
Mikhail Bessonov is currently a Research Officer in Teltec UCD-CS. He is also reading for his PhD in UCD in the area information retrieval and brokerage. He received his MS degree from St. Petersburg State University in 1993. Prior to joining UCD he carried out design and implementation of the multiprotocol network router for Open System in Russia. His research interests include distributed applications, electronic brokerage, information retrieval.