17
Ž . Decision Support Systems 29 2000 305–321 www.elsevier.comrlocaterdsw An inclusive and extensible architecture for electronic brokerage Jenny Hands a, ) , Mikhail Bessonov b , Mike Blinov b , Ahmed Patel b , Ron Smith c a Fretwell–Downing Data Systems Ltd., 113 OÕerton Road, Hillsborough, Sheffield S6 1WH UK b Computer Networks and Distributed Systems Research Group, Department of Computer Science, UniÕersity College Dublin, Belfield, Dublin 4, Ireland c KYROS, 55 EÕripidou and Thiesseos AÕe., Kalithea 17674 Athens, Greece Abstract The output and experience of a large European project in Electronic Brokerage called AGeneric Architecture for Ž . Information AvailabilityB GAIA is presented. The paper describes a reference model and functional architecture for value-added mediation in Electronic Commerce. The customers are provided with a uniform way of accessing heterogeneous suppliers without changes in the supplier software. A way of employing distributed objects for large-scale service integration and multi-enterprise transactions is shown. The issues encountered during the implementation of the Common Brokerage Ž . Architecture CORBA -based pilot prototype and the application of the architecture in three diverse domains are presented. q 2000 Elsevier Science B.V. All rights reserved. Keywords: Electronic brokerage; Electronic Commerce; Brokerage architecture; Supply chain; CORBA; Java; Z39.50; GAIA Project; RFC 2552 1. Introduction Dictionaries define commerce as Athe buying and selling of goods and servicesB. Electronic Commerce can be broadly seen as applying the information technology and telecommu- nications advances of recent years towards increas- ing the efficiency, effectiveness, and functionality of traditional commerce practices in the supply chain linking producers of goods and services and the eventual consumer. As such, Electronic Commerce ) Corresponding author. Fretwell–Downing, Brincliffe House, 861 Ecclesall Road, Sheffield S11 7AE, UK. Ž . E-mail addresses: [email protected] J. Hands , Ž . Ž . [email protected] M. Blinov , [email protected] A. Patel , Ž . [email protected] R. Smith . covers a diverse range of commerce related activities including, but not limited to: Ž Ø processes that aid the potential customer individ- . ual or business , in locating the goods and ser- vices they need and at the same time allowing suppliers to make potential customers aware of their products; Ø processes facilitating the negotiation of a basis for the transaction that mutually benefits all parties; Ø the processing of the agreed transaction; Ø the management of the on-line delivery of the goods or services from the supplier to the con- sumer; and Ø after sales services that ensure that the customer is satisfied with the order and delivery process and is able to use the delivered goods or services to their full extent. 0167-9236r00r$ - see front matter q 2000 Elsevier Science B.V. All rights reserved. Ž . PII: S0167-9236 00 00080-4

An inclusive and extensible architecture for electronic brokerage

Embed Size (px)

Citation preview

Ž .Decision Support Systems 29 2000 305–321www.elsevier.comrlocaterdsw

An inclusive and extensible architecture for electronic brokerage

Jenny Hands a,), Mikhail Bessonov b, Mike Blinov b, Ahmed Patel b, Ron Smith c

a Fretwell–Downing Data Systems Ltd., 113 OÕerton Road, Hillsborough, Sheffield S6 1WH UKb Computer Networks and Distributed Systems Research Group, Department of Computer Science, UniÕersity College Dublin,

Belfield, Dublin 4, Irelandc KYROS, 55 EÕripidou and Thiesseos AÕe., Kalithea 17674 Athens, Greece

Abstract

The output and experience of a large European project in Electronic Brokerage called AGeneric Architecture forŽ .Information AvailabilityB GAIA is presented. The paper describes a reference model and functional architecture for

value-added mediation in Electronic Commerce. The customers are provided with a uniform way of accessing heterogeneoussuppliers without changes in the supplier software. A way of employing distributed objects for large-scale service integrationand multi-enterprise transactions is shown. The issues encountered during the implementation of the Common Brokerage

Ž .Architecture CORBA -based pilot prototype and the application of the architecture in three diverse domains are presented.q 2000 Elsevier Science B.V. All rights reserved.

Keywords: Electronic brokerage; Electronic Commerce; Brokerage architecture; Supply chain; CORBA; Java; Z39.50; GAIA Project; RFC2552

1. Introduction

Dictionaries define commerce as Athe buying andselling of goods and servicesB.

Electronic Commerce can be broadly seen asapplying the information technology and telecommu-nications advances of recent years towards increas-ing the efficiency, effectiveness, and functionality oftraditional commerce practices in the supply chainlinking producers of goods and services and theeventual consumer. As such, Electronic Commerce

) Corresponding author. Fretwell–Downing, Brincliffe House,861 Ecclesall Road, Sheffield S11 7AE, UK.

Ž .E-mail addresses: [email protected] J. Hands ,Ž . Ž [email protected] M. Blinov , [email protected] A. Patel ,Ž [email protected] R. Smith .

covers a diverse range of commerce related activitiesincluding, but not limited to:

ŽØ processes that aid the potential customer individ-.ual or business , in locating the goods and ser-

vices they need and at the same time allowingsuppliers to make potential customers aware oftheir products;

Ø processes facilitating the negotiation of a basis forthe transaction that mutually benefits all parties;

Ø the processing of the agreed transaction;Ø the management of the on-line delivery of the

goods or services from the supplier to the con-sumer; and

Ø after sales services that ensure that the customeris satisfied with the order and delivery processand is able to use the delivered goods or servicesto their full extent.

0167-9236r00r$ - see front matter q 2000 Elsevier Science B.V. All rights reserved.Ž .PII: S0167-9236 00 00080-4

( )J. Hands et al.rDecision Support Systems 29 2000 305–321306

The objective of this paper is to examine the roleof brokerage within the context of Electronic Com-merce and to present the Generic Architecture for

Ž .Information Availability GAIA , an expandable ar-chitecture for the implementation of electronic bro-kerage systems.

1.1. Electronic commerce concerns

Electronic Commerce offers a foundation for manybenefits for both the consumer and the supplier. Thefact that DELL Computers profitably sells over $5 Ma day via their WEB site a is proof of the benefitsElectronic Commerce has to offer customers and

w xsuppliers 10 . In parallel, there are also risks associ-ated with the introduction and spread of ElectronicCommerce. Outside of the well-publicized issues,such as those in regard to credit card fraud, there is areal danger in what we will refer to as supplieroverload. With the ease at which the current state ofthe art allows the creation of a WEB site, one caneasily envision the situation where every individualor organization producing goods and services sets upits own on-line WEB store. If such an unstructureduncontrollable approach to the spread of ElectronicCommerce continues, the future success and up-takeof the technology and concepts is questionable. Re-lated business models, architectures, and standardsmust be developed and adopted if Electronic Com-merce is to fulfill its promise.

1.2. The need for the electronic broker

With this avalanche of on-line suppliers and infor-mation about goods and services, how is the con-sumer to locate, purchase, and obtain the goods andservices they seek, at a fair market price, and from asupplier they can feel confident with? The introduc-tion of the role of an on-line electronic broker intothe Electronic Commerce supply chain linking con-sumers and suppliers presents the ideal solution tothis problem. Mediation by these on-line electronicbrokers joins customers and suppliers, thus, stimulat-ing the market activities of both parties. Electronicbrokerage systems have the potential of offeringsuppliers the capability to expand the number andtype of potential customers for their products, thus,allowing small and medium size suppliers to more

effectively and efficiently compete with larger sup-pliers in their domain.

1.3. The need for a supplier-independent architec-ture for electronic brokerage

In order for the electronic brokerage concepts tobe effectively implemented, it is important that suchimplementations be based on relevant architecturesand agreed standards. The brokerage architecturemust be scaleable and be applicable to the distributedon-line nature of today’s Electronic Commerce sup-ply chains. It must handle the diverse nature of theexisting and future goods and services to be traded.At the same time, it must handle the heterogeneity ofthe systems deployed by the actors involved in thesupply chain and the heterogeneous networks linkingthem. The architecture must allow implementationsthat are commercially feasible. It must support theability of actors taking the role of broker to addvalue to the supply chain and to financially benefitfrom this added value. Recognizing that today, it iswidely accepted that transactions are the key toconstructing reliable distributed applications, it isimportant that the architecture support the transac-tion-oriented ACID properties, which are currentlyabsent in today’s most commonly used Internet tech-

w xnologies 21,12 . To ensure success, the architecturemust be generic and applicable to a diverse range ofdomains. And most importantly, to ensure fair com-petition and protect the consumer from a monopolis-tic environment, the architecture must be supplier-in-dependent.

The explosion in Internet access and the advent ofElectronic Commerce presents great potential for themarket for electronic brokerage services. To date,most efforts towards the realization and standardiza-tion of this market have focused on infrastructuralissues, such as secure on-line payment, electronicproduct catalogues, and digital delivery. However, ifthere is to be interoperability between businesses inthe supply chain, permitting participation of bothlarge and small suppliers and promoting choice anddiversity, a supplier-independent architecture for bro-kerage meeting the above-described requirements isrequired. The GAIA, presented in this paper, is beingdeveloped by an international consortium of 19 orga-nizations. The GAIA approach supports an informa-

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 307

tion society in which Information Brokers offer ser-vice economies and refinements that enhance thesupply chain to the advantage of producers andservice providers in diverse domains.

1.4. Related electronic brokerage projects

During the past few years several projects havebeen carried out in the area of electronic brokerage.These projects were either focused purely on broker-age, or else, considered it in the context of ElectronicCommerce in general.

Ž .The Common Brokerage Architecture CORBAw xproject 9 aimed to create an open architecture for

the brokerage of distributed on-line resources. It hasproduced a comprehensive framework for brokeragesystems. However, it has not defined any protocolsand interfaces between actors, and did not addressrelated interoperability issues. It also did not paysignificant attention to possible federation betweenbrokers.

ŽThe objective of the OSM An Open ServiceModel for Global Information Brokerage and Distri-

. w xbution project 6 was to create a framework for theElectronic Commerce in general. The OSM model isbased on the CORBA architecture. Unfortunately,the OSM architecture does not go beyond theCORBA world. It requires all customers, brokers,and suppliers to support CORBA. This model doesnot cover existing customers and suppliers that usecustomary trading protocols. OSM also limits thescope of the brokerage to the discovery stage of thetrading process.

The Object Framework for Electronic Requisition-Ž . w xing OFFER project 1 extended the OSM model of

brokerage to cover both discovery and negotiation.However, it is still limited to the CORBA world. TheOFFER project also increased the flexibility of theframework by introducing a class of exchangeablecomponents. Unfortunately, this idea was only ap-

Ž .plied to the swapping of negotiation auction mech-anisms.

w xThe Metabroker project 2 , in contrast to theOSM project, aimed to provide a framework thatallows the integration of existing trading protocolsand data formats. This is achieved by the introduc-tion of an extra level of Aclient proxiesB that areresponsible for the protocol implementations. How-

ever, the Metabroker project did not specify theexternal interfaces of brokers to facilitate inter-brokercommunication. It also used a proprietary Shadowsenvironment for the design of proxies, which compli-cates the implementation of proxies by third parties.The scope of Metabroker is also limited to thediscovery stage.

OMG established a Domain Task Force in Elec-Ž .tronic Commerce ECDTF . This group produced a

working version of the Electronic Commerce Refer-w xence Model 11 . This model is largely based on the

results of the OSM project and inherits certain disad-vantages of the OSM model. It limits the activity ofthe broker only to the discovery stage of the tradingprocess and does not pay attention to the existingtrading protocols. ECDTF has defined a frameworkfor the long-term development of the facilities for anelectronic market. However, only a few facilities aredeveloped at the moment.

2. The GAIA project

2.1. Conception of the GAIA project

The GAIA project was conceived in 1996 toaddress the requirement of the on-line business soci-ety for a standards-based brokerage architecture, asoutlined above. Around the central theme of theproject, to produce an architecture for brokered in-formation supply services, objectives were defined toestablish a GAIA Standard with architecture andprotocol recommendations, and a generic toolset tocontribute to the development of practical, interoper-able information brokers. In this way, GAIA wouldfacilitate the location and purchase of online infor-mation, goods and services.

The GAIA consortium comprises service providersfrom diverse fields in IT, telecommunications andcommerce, and a number of research organisations.

2.2. OÕerÕiew of GAIA’s work

In the remainder of this paper, we present the keyresults of the GAIA project with reference to theirapplication and applicability in Electronic Com-merce.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321308

As shown in Fig. 1, the GAIA environment hasbeen modeled from a number of perspectives, differ-ing in their level of abstraction.

At the most abstract level, the GAIA ReferenceModel provides a common basis for the descriptionand specification of brokerage systems. The GAIAReference Model is defined in terms of the Roles,Actions, Events and Entities involved in electronicbrokerage. The GAIA Functional Architecture de-fines the functional elements of the GAIA system,embodying the GAIA Reference Model. The Func-tional Architecture specifies the roles and relation-ships between the GAIA Services which instantiatethe Actions and supporting Events of the ReferenceModel. Based on the functional relationships of ar-chitectural elements and their relationship to theworld at the large, the GAIA Standard is specified.

The development of generic tools within the ar-chitecture has been a core activity in the project,providing key reusable services, including user ac-cess components and mechanisms to use data fromexisting repositories. The GAIA pilot implementa-tion broker is built on the CORBA-distributed objectarchitecture. The experience the GAIA project gainedfrom building a CORBA-based Broker is describedlater in this paper.

Crucially important to the development and vali-dation of the GAIA approach has been the involve-ment of representative bodies and user communitiesin trials of the GAIA service. GAIA selected three

target domains in which to demonstrate various im-plementations of the developed GAIA compliantbrokerage system: the Music industry, the TechnicalComponents industry, and the Publishing industry.The Music Industry Trial focuses on delivering in-

Žformation and product in specialized genres namely.dance, ambient and free improvisation to the sector’s

highly dispersed global consumer base. The Techni-cal Components Industry Trial provides electronicbrokerage services to allow engineers to select andretrieve technical information on a wide selection of

Ž .die for the design of MultiChip Modules MCMsand hybrid circuits. The Publishing Industry Trialallows students, researchers and industry experts tolocate, order and receive digitally a wide range ofon-line material, including scientific articles fromjournals and agricultural information, such as agri-cultural statistics and customer contacts.

The span of these domains, from the structured,highly specified, standards-oriented, technical natureof the Technical Components industry to the artistic,loosely structured, multimedia nature of the Musicindustry, is to ensure that the GAIA architecturecovers the needs of a wide array of other domains.

2.3. The GAIA Reference Model

Before describing the Functional Architecture,which is a key result of GAIA and the basis fordeployment of brokerage services, we will briefly

Fig. 1. GAIA standard formulation levels of abstraction.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 309

outline the Reference Model, which is the highestlevel of abstraction considered by GAIA, in order toclarify the use of terminology. The design of theGAIA Reference Model was based on the require-ments captured in three diverse application domains,namely publishing, music and technical data do-mains. Models of the electronic marketplace sug-gested by other projects in the area of ElectronicCommerce were also taken into consideration.

The core concepts promoted by the GAIAproject’s Reference Model are the roles of customer,broker and supplier, and the actions of search, locate,order and deliver. These generic roles and actionshave been found to be a good basis to discuss anddevelop a working demonstrator broker infrastruc-ture, with brokers and suppliers spread around Eu-rope. The scope of the Reference Model has beenlimited to these areas of electronic brokerage and hasnot been formulated to address other areas of broker-age, such as workflow and pre- and post-sales sup-port. Clearly, the brokerage system must interactwith the back-of-house systems supporting suchfunctionality.

Central to the reference model is the GAIA bro-ker, which acts as a locator and supplier of informa-tion or services to customers, i.e. users who seekservices and information online, and likewise, a dis-tribution mechanism for suppliers wishing to pro-mote goods and services. The broker either supplies

Žthe information or service to the customer itself in.which case, it is acting in the supplier role , or else

Ž .playing a customer role itself it sources the infor-mation or service from another brokerrsupplier.

Inter-broker connections are very important forthe scalability of the architecture. Brokers can spe-

Žcialise in different domains either by application or.geographic meaning . However, a customer does not

have to search for an appropriate broker. The nearestbroker that supports inter-broker communications canaccept the request and fulfil it using the service of abroker specialised in the area of request. If a newapplication domain or area is available, it can becovered by a new broker, which will propagate itsservices to all the members of the federation. Differ-ent brokers can cover some areas simultaneously,which creates competition between brokers.

The function of the broker is to provide a path,whereby a customer may find and obtain a product.

If the broker knows where such a product can befound, he supplies the customer with the locationinformation. If the broker does not know the locationof a product, he requests a search on his behalf fromother brokers, thus, widening the search. In order toallow a search to be carried out, the terms of thesearch need to be clearly defined. A descriptionneeds to be given by the customer to the broker ofthe product that he requires. The use of metadata iscentral to the functioning of the GAIA broker, bothfor the customer to describe the product that herequires, and for the GAIA broker to propagate thesearch to further brokers.

While brokerage involves various phases of busi-w xness operation 13 , including awareness creation,

etc., it is the transaction phase that is of mostconcern to GAIA. The AactionsB which the GAIAarchitecture caters for during a transaction are:

Ø search, where the customer describes the natureof the product, and the broker returns the identityof products matching this description;

Ø locate, where the customer obtains from the bro-ker the location and terms of supply for a re-quired item;

Ø order, where the customer requests supply of therequired item from the given location; and

Ø delivery, where the broker causes the item to besent to the customer.

Around these main actions are supporting actions,of which the most important are authentication, tar-iffing and connection to payment systems.

Based on these concepts, a more detailed architec-ture can be developed, first, in terms of functionaldecomposition, and then, in terms of systems archi-tecture.

3. GAIA Functional Architecture

The GAIA Functional Architecture decomposesthe overall functionality of the brokerage system intoa number of components, and describes the roles andrelationships of the components, and the manner inwhich they interoperate. The key elements of theGAIA functional architecture are the GAIA kernel,

( )J. Hands et al.rDecision Support Systems 29 2000 305–321310

Ž .Functional Unit Managers FUMs , Functional UnitsŽ . Ž .FUs , and Abstract Primitives APs . These aredescribed in detail below.

3.1. FUs

The brokerage system provides a number of ser-vices to its users. These services are supported by thefunctions of the brokerage system. These include, forexample,

Ø searching,Ø metadata collection, andØ format translation.

Each of these functions can be provided by anumber of different candidate technologies. How-ever, the operations that are required to be carriedout remain the same — regardless of the selectedtechnologies, the functional requirements do notchange. The required operations are described interms of APs, which can be mapped to the protocolrequests of whatever technology is selected to sup-port the function. A mapping component, called anFU, is defined for each candidate technology, andconverts calls to APs into protocol instructions. TheFU acts as an interface between its particular tech-nology and the rest of the brokerage system.

FUs are defined for each candidate technologythat can be used to fulfil a particular functional needof the brokerage system. An FU accepts AP invoca-tions, and maps them to calls to the particular tech-nology to which it is dedicated. The results of thecalls to the technology are translated into the corre-sponding APs and returned by the FU.

3.2. FUMs

As noted above, a number of different candidatetechnologies can be used to fulfil a particular func-tional requirement of the brokerage system. Depend-

Žing on the details of the GAIA transaction underly-ing network, Customer system capabilities, domain

.requirements, etc. , different technologies may bemore useful during different Transactions. As a re-sult, each candidate technology has its own FU,which is invoked when that particular technology isrequired.

A number of different FUs can exist, which fulfilthe same functional requirement of the brokeragesystem. In order to select the most appropriate FUŽ .and technology , the brokerage system needs toknow which is most useful at any particular time.This is the responsibility of the FUM. Each functionof the brokerage system has a single FUM, which isinvoked in terms of APs by the Broker kernel. ThisFUM selects the most appropriate of the candidatetechnologies, and calls the corresponding FU. Theinterface between the FU and the FUM is defined inan open, platform-independent, programming-lan-guage-independent manner. It is important to noticethat all the FUs subordinate to the same FUM havethe same interface. This holds true even in the caseof considerable differences between the technologiesused to implement these FUs. This hides the inter-nals of particular FUs from the FUM. The specifica-tion of the interface consists of the formal definitionin CORBA IDL and the guidelines for the interpreta-tion of passed parameters. This allows a third partyvendor to develop a new FU, implementing, forexample, some recently emerged search protocol,and incorporate it into the broker without any modi-fication of any other component. This makes thearchitecture easily extensible.

3.3. The kernel and APs

The kernel of the brokerage system acts as abuffer between the FUMs, and as a bus for thetransmission of APs between FUMs. It also acts as arepository of local information and as a shared datastore for FUMs. All calls to APs are executed via thekernel, which exports all the APs imported by thevarious FUMs, and imports all those exported by theFUMs.

As shown in Fig. 2, communication between theGAIA kernel and FUMs, and between FUMs andFUs, is carried out in terms of APs. In a pureCORBA world, we would call them just methods ofparticular published interfaces. However, to allow anon-ORB-based implementation of a GAIA brokerand to keep the interface general, a concept of APswas introduced. These APs correspond to a particularoperation, which a FUM will carry out on behalf ofthe kernel, or which the FUM expects the kernel to

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 311

Fig. 2. Communication between FUM and FU.

carry out. Each FUM imports a set of APs, represent-ing those services, which the FUM expects to receivefrom some other part of the system. The services,which the FUM is prepared to provide to otherelements of the brokerage system, are presented inthe form of exported APs. All APs are importedfrom, and exported to, the kernel. The kernel acts asa bus for APs. APs are also used in communicationbetween the FUM and its FUs. The FU exports APsto the FUM.

3.4. Elements of the GAIA Functional Architecture:description of FUMs

The core activities of the brokerage system in-clude:

Ø searching for and identifying information Prod-ucts that fit a user description,

Ø sourcing information Products the identificationof which is known,

Ø allowing users to order Products,Ø delivering information in file format,Ø delivering information as a continuous media

stream,Ø monitoring use of the system and charging for it,Ø enforcing the security policy of its particular se-

curity domain,Ø collection of information about what is available

Ž .metadata collection ,Ø providing a user interface to the brokerage ser-

vices and alerting users as to the availability ofinformation, using e-mail, mobile terminals, etc.,

Ø interacting with external directory services, andØ allowing the user to provide feedback on a partic-

ular Action or transaction.

This is illustrated in terms of FUMs in Fig. 3.Table 1 contains a brief description of every FUMspecified by the GAIA Functional Architecture.

Fig. 3. GAIA Functional architecture FUMs.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321312

Table 1FUM responsibilities summary

FUM Responsibilities

Search Accepts requests to carry out a search for Products that fit a particular user description. It returns lists ofidentifiers of Products that fit the description.

Locate Accepts Product identifiers, and discovers where they may be obtained. It returns lists of Suppliers and locationsfor the Product.

Order Manages negotiations between a Customer and a Supplier, in order that agreement may be reached on the termsof availability of a particular Product or group of Products. Following the negotiation phase, the order FUMaccepts purchase commitments from the Customer and forwards them to the Supplier. It returns a notificationof the status of the order Action.

Item delivery Manages the delivery of file-structured items to the Customer.Stream delivery Manages the delivery of real-time multi-media data streams to and from the Customer.Payment Provides a mechanism for payment from one actor to another.Authentication Provides a mechanism which allows a user to prove his identity to the brokerage system.Metadata collection Supports the collection of Product descriptions and where they are available.Customer Provides an interface for the user to allow him to interact with the brokerage system. It also alerts him

when a Customer-specified event occurs.Directory services Provides an interface between an external directory service and the brokerage system.

In the event that a GAIA broker is a distributedentity, with different FUs and FUMs running ondifferent platforms to the kernel, inter-module com-munication uses the CORBA model. The internal

Žoperations of the broker the APs imported and.exported by the FUMs are encoded using the Inter-Ž . w xnet Inter-ORB Protocol IIOP 5 inter-ORB proto-

col, along with any data or other variables requiredfor the operation, and then transported among theFUMs. The pilot implementation developed by theGAIA project supports this distributed model.

4. Choice of brokerage protocols

4.1. The GAIA Standard

As previously discussed, the architecture of theGAIA brokerage system is designed so that a num-ber of different technologies can be used to fulfil anyparticular functional requirement of the system and,furthermore, the GAIA Broker can interoperate withnon-GAIA systems, where compatible technologieshave been implemented. However, in order to pro-mote interoperability, GAIA also specifies a AGAIAStandardB, in which one technology is selected foreach FUM.

The criteria for selection reflected the over-ridingneed to specify a workable standard, with the bestchance of producing brokerage systems that are in-

teroperable with other information navigation sys-tems. Key selection criteria include the following:

Ø popularity and acceptance,Ø standards status,Ø functionality, andØ feasibility of integration with other information

navigation systems.

The functionality of a GAIA broker is ratherdiverse, and different interactions in the GAIA sys-tem present varying requirements to the underpin-ning technologies. For the purpose of selection ofappropriate protocols, the operations of a brokeragesystem can be broken into the following three cate-gories:

Ø interactions with the customer,Ø interactions with other brokers, andØ interactions with suppliers.

The first and last of these occur at the two ends ofa supply chain, while inter-broker operations takeplace at other points in the chain. As shown in Fig.4, the supply chain may take a number of differentforms:

Ø A minimal chain, where the customer and thebroker are the ends of the chain, and there are nointervening links. In this case, the broker playsthe role of supplier to the customer.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 313

Fig. 4. Supply chains.

Ø A three-piece chain, where the broker deals withthe customer and the supplier, but not with anyother broker.

Ø A longer chain, with one or more inter-brokeroperations.

4.2. Minimal profile

As specified by the GAIA reference model, aGAIA transaction is composed of a number of ac-tions, such as search, order and delivery. Each trans-action is initiated by the customer, who makes arequest to the broker. In the event that the broker isable to fulfil the request, the transaction involves noother actors. In this simple case, the GAIA transac-tion involves the customer and the broker, and theonly protocol which needs to be standardised is thatbetween the customer and the broker. This is done in

w xa trivial way using the HTTP protocol 19 . TheAGAIA standardB refers to such arrangement as aAminimal profileB.

4.3. Basic profile

In the event that the broker is not able to fulfil arequest, the action may be propagated on to other

brokers, with the original broker playing the cus-tomer role. The supply chain is, thus, made up of asingle customer, one or more suppliers, and one ormore brokers. While some of the existing protocols

Ž .enable chained operations e.g. Z39.50 , none ofthem is suitable for all stages of the trading process.To solve this problem, the GAIA project has intro-duced an external broker interface defined in termsof CORBA and is called the GAIA Customer inter-face. This interface enables access to all actionscomprising the trading process and provides opera-tions for transaction management. The support ofthis interface is required in the so-called GAIA Basicprofile. This profile is defined primarily to facilitateinter-broker communications. If a broker does notsupport the Basic profile, it can take part in chainedoperations using customary protocols, however, thefunctionality of such operations will be limited. Itshould be noted that all properties of transactionŽ .ACID can be fully supported only if they aresupported by protocols involved in this transaction.That is why the GAIA Standard strongly encouragesactors to support the GAIA Basic profile.

4.4. Extension modules

The extension modules in the GAIA standardspecify the profiles to be used for various brokerage

( )J. Hands et al.rDecision Support Systems 29 2000 305–321314

Table 2GAIA extension modules

Extension module Protocols supported

Item delivery FTP, Internet e-mailrMIME, GEDIStream delivery MPEGrRTPSecurity PKIXrGSS, SSL, Java Access

Control SystemPayment SETDiscovery Z39.50Order ISO ILLCustomer Z39.50, ISO ILL, e-mail

Ž .functions see Table 2 , thereby admitting suppliersystems which do not adhere to the GAIA Basicprofile to the wider GAIA Standard. Example proto-cols are Z39.50 for discovery, ISO ILL for ordering,

w xand FTP 16 for item delivery. More extensions canbe easily added whenever necessary.

Search and Locate actions involve the customerfinding a resource or product with the assistance ofthe broker. By default, specification of the actions

w xtakes place via HTTP 7 , with the customer using aWWW interface to the GAIA broker, and the resultsof the discovery are returned to the customer via theWWW interface. However, if specified, results mayalso be returned via e-mail, using the SMTP withMIME extensions. It should be noted that searchesare particularly likely to be initiated on a GAIAbroker by entities which conform only to the Z39.50

protocol in the GAIA Standard. These may bechained using Z39.50 to other non-conformant enti-ties.

Order involves the customer asking that a re-source or product be delivered to him by the brokeror the supplier. Once again, this takes place via aWWW interface, and the order is transported to thebroker via HTTP. If the order needs to be propa-gated, and the basic profile is supported, the order is‘translated’ to APs, encoded with IIOP, which areused for inter-broker communication. At the supplierend of the chain, ISO ILL may be used for orderingfrom libraries. This is depicted in Fig. 5.

The DeliÕery action may either be carried outŽusing a direct supplier–customer delivery where the

broker has only worked as a referral agency, or is.itself the supplier , or via a supply chain of multiple

linked deliveries. As shown in Fig. 6, a delivery tothe customer may make use of a number of different

w xprotocols, including FTP 16 , e-mailrMIMEw x w x Ž14,15,17 , and MPEGrRTP 7,18 in case of con-

.tinuous media delivery .A Broker can choose an appropriate set of Exten-

sion Modules to conform to according to the func-tionality it wishes to achieve. There is one extensionmodule for each of the functional areas, which arenot covered by the Basic and Minimal Profiles, andone extension module for each of the existing areasŽ .Customer, Discovery and Order to allow the use ofprotocols other than IIOP. The extension modules

Fig. 5. Search, Locate and Order action supply chains.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 315

Fig. 6. Delivery action supply chain.

specified and the protocols they are based upon aresummarized in Table 1.

5. Building a CORBA-based brokerage system

As noted earlier, the internal interfaces of theGAIA Functional Architecture were defined inCORBA IDL. This proved to be an excellent choicefor a number of reasons. Subsequently, the decisionwas made to also use CORBA as an integrationmechanism for the pilot development of the GAIABroker. This decision was also venerated by experi-ence, although initially, there were a number ofdifficulties.

GAIA made the decision to use IDL for thespecification of functional interfaces for the follow-ing reasons:

Ø it is widely accepted as a standard;Ø it is rigorously defined, independent of platform;Ø it is easy for systems designers and programmers

to learn;Ø it is readable by technical staff with no CORBA

training; andw xØ it is supported by tools such as AidldocB 13

which can produce documentation useful in acollaborative environment.

By May 1997, an initial set of IDL interfaces forthe FUMs described above had been produced. InJuly 1997, the Consolidated Design for the GAIA

w xBroker 4 was published, which detailed the IDLinterface of the Broker Kernel, and rationalised theinterfaces of the FUMs.

There were some debate as to whether theseCORBA-compliant interfaces should lead to a

CORBA-based implementation of the GAIA Broker,i.e. with functional integration occurring around anORB. The alternative was to use lower level proto-cols to integrate, with higher-level communicationprovided by a combination of proprietary middle-

Žware and GAIA’s own solutions. Note that Mi-crosoft’s equivalent to CORBA, i.e. DCOM, was notin the running, because it does not support yet

.cross-platform interoperability.The early experiments with ORBs were promising

but problematic. A key issue was interoperabilitybetween different ORBs: prior to CORBA v2.0, nostandard for interoperability was defined. Version

Ž .2.0 specifies General Inter-ORB Protocol GIOPw xand IIOP 4 , the latter instantiating the former over

Ž .the Internet Protocol IP . The first v2.0-compliantORBs appeared soon after GAIA started work, butinteroperability was far from assured.

By December 1997, interoperability via IIOP wasestablished. Systems integration of the basic frame-work was 4 weeks behind schedule and someAworkaroundsB were in place to handle some envi-ronment problems, e.g. concerning bugs in namingservices and IIOP incompatibilities. However, withcommercial requirements now mandating the use ofa mixed SolarisrNT platform for a distributed Bro-ker architecture, the use of ORBs was felt to havebeen beneficial. The implementation deployed todemonstrator sites for the GAIA trials makes use ofthe following interoperating components:

Ž .Ø Broker Kernel, built with Orbix from IONA ,running on Solaris or NT;

Ø assorted FUMs built with Orbix, running on So-laris or NT;

( )J. Hands et al.rDecision Support Systems 29 2000 305–321316

Ø Directory Services FUM built with OmniBrokerŽ .a shareware ORB , running on NT; and

Ø Customer FUM interface built with VisiBrokerŽ .from Visigenic , running on Solaris.

Other ORBs that GAIA worked with include ILU,a very early CORBA implementation from XeroxPARC laboratories, and OmniOrb, another sharewareORB. Of the ORBs tried, only Orbix and VisiBrokergave full v2.0 compatibility, with support for multi-threading and for dynamic service activation. Omni-Broker was entirely satisfactory apart from lack ofmulti-threading, which made it suitable for a singly-threaded systems component, such as the DirectoryServices FUM, but not for the Broker or for theSearch, Order or Directory FUMs. Dynamic serviceactivation was considered important for efficiency,rapid start-up response time, and to support servicefulfillment by agents.

Overall, the experience of ORB implementationwas a good one. All components of the FunctionalArchitecture were implemented with less Acompro-miseB than the project expected. The Kernel andFUMs were built from scratch based on their IDLdefinitions, and largely coded in Cqq. The FUswere, at least, partly based on existing code, with a

CORBA wrapper around them to offer the FUMrFUinterface.

In the Spring of 1998, the User Interface architec-ture took shape. A layer of Java classes was built tooffer this interface to diverse clients, and two struc-turally different User Interfaces were produced uponit. The Apure JavaB interface comprises Java appletsor applications, resident or downloaded on the clientmachine, which call the Broker via IIOP. The Ady-namic htmlB interface uses a proprietary webserverAPI to link a site-configurable front end to the Java

Žclasses resident on the webserver. GAIA usedNetscape’s LiveConnect protocol to do this; another

.choice would have been Microsoft’s ISAPI protocol.In addition, a non-Java User Interface was con-structed, which provided access for non-GAIA clients

w xrunning the Z39.50 search and retrieve protocol 23 :this interface, evidently, could not support the fullrange of Broker functions.

As shown in Fig. 7, three User Interface architec-tures were developed for the GAIA demonstrator.

The Apure JavaB interface is highlighted, as thechoice which most readily supports the deploymentof brokerage client software in a heterogeneous envi-ronment and is the solution being used in the GAIATechnical Components Domain demonstrator. At the

Fig. 7. User Interface architectures trialled with the CORBA-based GAIA Broker.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 317

time of writing, binding to Java from ORBs is muchbetter supported than binding to Cqq, Java beingamenable to the provision of simpler arrangementsfor memory allocation, etc.

Fig. 8 concludes the discussion on the GAIAprojects experience in developing and implementinga CORBA-based brokerage system by presenting anexample of the search action as implemented withinthe Technical Components Domain demonstrator.

The simplified operation and implementation ofeach of the shown modules can be summarized asfollows.

Ž .A Customer — the GAIA Technical Compo-nents Domain Client application is loaded on thecustomer’s Windows-based PC. This application hasbeen written in Java and, in addition to user interfacefunctions, it also includes Interaction Agent function-

w xality 8 to assist the user in the operation of thesystem. After being authorized by the system, thecustomer performs a search operation by enteringhisrher search criteria and submitting the request.

Ž .B Customer FU — the GAIA Technical Com-ponents Domain Customer FU has been developedwith VisiBroker from Visigenic and with Java. Call

Back target mechanisms are initiated and used totrack the progress of the issued search request.

Ž . Ž .C Kernel with associated FUMs — the kerneland associated FUMs have been developed in Cqqin conjunction with the Orbix CORBA environmentfrom IONA. The kernel maintains a session for eachactive GAIA transaction. When the kernel receivesthe search request for the transaction, it will movethe session to the search state and pass the request tothe Search FUM. In the demonstrator, there is onlyone Search FU implemented so the request is passedto the Z39.50 Search FU. The kernel transactionmechanisms developed for the GAIA user trials werenot based on any complex ACID transaction controlprocess. Future commercial GAIA-based brokeragesystems would need to internally include such prop-erties using mechanisms such as those provided by

w xthe CORBA Transaction Service 12 . This will beparticularity important for Broker kernels, which of-fer all of the brokerage actions described in thereference model.

Ž .D Search FU — the Search FU uses Z39.50technology to formulate the search request. It wasdeveloped using existing software with an IDL

Fig. 8. Technical components domain demonstrator.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321318

CORBA wrapper. The FU will take the search re-quest from the FUM and convert it into Z39.50format.

Ž .E Supplier Database — the actual technicalcomponents supplier data is stored in a ZEBRAdatabase. ZEBRA is a Z39.50 server developed byIndex Data IS, a partner in the GAIA consortium.The ZEBRA server processes the search request andreturns details of the result set to the Customer viathe above-described modules.

To sum up the ORB experiences of GAIA, it isnoted that cross-platform and cross-ORB interoper-ability is a reality and that the CORBA approachoffers flexibility welcome in the provisioning ofservices in a distributed environment. While CORBAis at present an immature technology, it can beexpected to evolve in the near future and constitute akey enabler technology for Electronic Commercew x22 . Other object-based approaches, such as DCOM,may also become applicable.

GAIA intends to promote its CORBA-based spec-ifications and toolkits. Two areas where CORBAimplementations may provide significant advantagesare:

Ø the Z39.50 search and retrieve protocol, andØ Directory Services.

The advantages of CORBA implementations, asspecified by GAIA, are that service creators need notgrapple with low-level encoding and transport mech-anisms, and can use a much more standardised ap-proach to systems integration based on business-levelobjects.

6. GAIA’s impact on the supply chain

6.1. Customer impact

The heterogeneous nature of a GAIA compliantbroker will ensure that the prospective customer willbe able to use their current computer environmentand telecommunications infrastructure to access theservices of a GAIA compliant broker. Accessing aGAIA compliant broker, as opposed to other currenton-line retail points of presence, will ensure thatcustomers can locate, order and receive delivery of awide range of products and services from suppliers

in a global non-monopolistic environment. The abil-ity of a GAIA compliant broker to add value to theprocess of a customer obtaining goods and serviceswill optimize the ability of customers to select theright product, at the right price, and at the right time.

6.2. Supplier impact

As with the customer, the heterogeneous nature ofa GAIA compliant broker will ensure that a supplierwishing to promote, sell and deliver their product orservice via a GAIA compliant broker will not haveto invest in a new infrastructure. Establishing acommercial relationship with a GAIA compliant bro-ker will allow the supplier to access a larger globalpotential customer base. Better deals are availablevia the broker for financial and distribution servicesthan could be negotiated directly with today’s ser-vice providers. Additionally, the new technologiesoffered by a GAIA compliant broker allow newfunctionality to be implemented to aid the supplier.For example, a GAIA broker operating in the officeautomation domain could use push distribution func-tionality to automatically distribute, on a try and buybasis, new upgrades to a suppliers word processingapplication to all customers who have purchased theproduct via the broker.

6.3. Broker impact

The adoption of the concepts of the GAIA broker-age environment will create business opportunitiesfor entry into new brokerage markets. The value-ad-ded capabilities of the architecture ensure that theperspective broker has the potential to financiallyprosper from their operation. The generic nature ofthe architecture allows the broker easily to move intoan environment supporting multiple domains. Thedistributed heterogeneous nature of the architecturewill allow the broker to establish business relation-ships with other GAIA compliant brokers allowingchained brokerage transactions.

The question arises as to how the AfairnessB ofthe broker can be controlled and guaranteed. Elec-tronic brokerage systems cannot do more in this areathan that which is available in a traditional market-place: in general, life is not fair and the buyer mustalways be aware. Broker reputation will be key. In

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 319

some domains, impartiality can be the broker’s addedvalue, while in other domains, the added value could

Žbe presenting results in a desired biased way thus,.not fair . In all cases, and as in non-electronic mar-

ketplaces, it is the forging of business relationshipsbetween supplier and broker, and the marketing ofproducts and services to the customer, which dictatesavailability and visibility in the supply chain. Thus,the brokerage business is driven not by fairness butby opportunity.

6.4. DeÕeloperr implementers

The documentation and toolkits developed as partof the GAIA project will allow implementers ofGAIA compliant brokers to easily design and imple-ment GAIA compliant brokers in many diverse do-mains.

7. Conclusion

The GAIA project ended successfully in January1999. The project culminated with the successfulrunning of GAIA compliant brokerage user trials inthree diverse domains, thereby validating the feasi-bility of the brokerage architecture and conceptspresented in this paper. The trials were accompaniedwith an evaluation phase where customers, suppliersand brokers completed on-line or paper-based ques-

Ž .tionnaires one per domain demonstrator that ad-dressed various aspects of their experiences and viewson the system. The evaluation criteria focused onusability, efficiency, functionality and the benefits ofthe service. The results of this assessment processare fully detailed in the final GAIA project deliver-

w xable 3 . Key findings from the trials showed that:

Ø A broker must supply domain-specific added valueto ensure commercial viability. Test users werewilling to pay for this added value if its value wasreadily apparent. For example, in the scientificpublishing domain test, users were willing to paya premium for the instant on-line or FAX deliveryof desired articles.

Ø Added value services that test users, identified asparticularly beneficial, were the broker’s ability toprovide products from multiple suppliers and thebroker’s ability to offer the service 24 hrday.

The final achievement of the project was thew xintroduction of RFC 2552 20 , which presents the

GAIA generic architecture for information broker-age.

Uptake of the GAIA approach since completionof the project trials has been encouraging. Mostnotably, the Publishing Trial in Denmark hasspawned a successful, commercial brokerage service.There have been other exploitations of the project,including reuse of subsystems by project partnersŽ .including Search, Payment, and Directory Services ,

Žand follow-up research proposals e.g. for access to.Online Learning , but it is the ongoing international

brokerage service for journal articles which besthighlights the principles of GAIA. The commercialservice is run by the Technical Knowledge Center

Ž .and Library of Denmark DTV , and now offerscomprehensive coverage of articles from five majorsuppliers. There are 12 million records in the brokerdatabase at the time of writing, and seven usergateways serving sectors of the scientific and aca-demic community; expansion is ongoing in bothrespects. The service illustrates well the supply chainbenefits of brokerage in that DTV have been able tonegotiate bulk discount prices on the basis of advan-tages offered to the supplier, thus, better serving thecustomer, and providing a business opportunity forthe broker.

In summary, the adoption of the GAIA supplier-independent generic electronic brokerage concepts,architecture and standards presented in this paperwill allow consumers and suppliers to better capital-ize from the supply chain benefits which ElectronicCommerce has to offer.

Acknowledgements

This work is partly funded through the EuropeanCommission’s ACTS Programme.

References

w x1 M. Bichler, C. Beam, A. Segev, OFFER — a broker-centeredobject framework for electronic requisitioning, in: W.

Ž .Lamersdorf, M. Merz Eds. , Trends in Distributed Systems

( )J. Hands et al.rDecision Support Systems 29 2000 305–321320

Ž .for Electronic Commerce TrEC ’98 ,1998, p. 1402, SpringerLecture Notes in Computer Science.

w x2 S.J. Caughey, D.B. Ingham, P. Watson, 1998. Metabroker: AGeneric Broker for Electronic Commerce. Technical Report635, pp. 1–13, Department of Computing Science, Univer-

²sity of Newcastle upon Tyne, March. See also http:rr:w3objects.ncl.ac.ukrpubsrmbgbecrTR635r .

w x3 H. Dormann, GAIA Deliverable D0202, GAIA Service andStandard Assessment,1998.

w x Ž4 GAIA Project Deliverable D0902 to be updated as D0903 in.December, 98 .

w x5 http:rrwww.omg.org.w x6 InfoWin ACTS Project 1998. Information Brokerage.

Deutsche Telekom Berkom, Berlin.w x7 ISOrIEC IS 13818 Information technology — Coding of

moving pictures and associated audio information, 1996,Geneva.

w x8 D. Koutsabasis, D. Spyrou, Facilitating User–System Interac-tion: The GAIA Interaction Agent, HICSS, Hawaii, 1999,January.

w x9 M.J. Martin, J.E. Dobson, M.R. Strens, 1998. An Architec-tural Approach to Brokerage in Network Based Commerce.Department of Computing Science, University of Newcastle,Technical Report 642.

w x10 Moules, The Middleman Always Knocks Twice, InformationStrategyrEconomist Group, 1998, April.

w x11 OMGrCommerceNet 1997. Joint Electronic CommerceWhitepaper. OMG Domain Technical Committee, Monreal,

² :See also http:rrwww.osm.netruploadr97-06-09.pdf .w x12 OMG Transaction Service: v1.1 Service Description, Nov.

1997.w x13 Ed.S. Plagemann, J. Hands, An enterprise model for broker-

age,Guideline 3 from ACTS SIA Chain, 1997.w x14 RFC821, Simple Mail Transfer Protocol, J. Postel, August,

1992.w x15 RFC822, Standard for the format of ARPA Internet text

messages, D. Crocker, August 1982.w x16 RFC 959 File Transfer Protocol, October, 1985.w x17 RFC1521, Multipurpose Internet Mail Extensions Part One:

Mechanisms for Specifying and Describing the format ofInternet Message Bodies, N. Borenstein, N. Freed, Septem-ber, 1993.

w x18 RFC 1889, RTP: A Transport Protocol for Real-Time Appli-cations, January, 1996.

w x Ž .19 RFC 2068r2069, HTTP v1.1, T. Berners-Lee et al. , Jan-uary, 1997.

w x20 RFC 2552, Architecture for the Information Brokerage in theACTS Project GAIA, M. Blinov, M. Bessonov, C. Cliss-mann, August, 1999.

w x21 M. Smith, A transaction service formulated on an ODPcompliant engineering platform,IFIPrICCC Proceedings,Trondheim, Norway, June, 1966.

w x22 Watson, Distributed Object Technology, a Key enabler forE-Commerce, TREC, Hamburg, Germany, 1998, June.

w x23 Z39.50 Protocol Specification, The Z39.50 MaintenanceAgency, http:rrlcweb.loc.govrz3950ragencyr, 1992 Li-brary of Congress, Washington.

Jenny Hands graduated with a first class Mathematics degree andgained a PhD in Engineering Mathematics. Between 1984 and1992, she worked as a Software consultant for PAFEC, responsi-ble for 3D CAD developments. She joined Fretwell–Downing in1992 to lead the GUI development and subsequently, becameproject leader for Open Distributed Processing applications. Be-tween 1996 and 1999, she was Project Manager of GAIA, an EUFramework Programme collaboration involving 19 partners andsome of Europe’s finest distributed systems practitioners. Cur-rently, she is Project Manager responsible for developing FD’sintegrated on-line learning and education business systems for Ufias part of a Logica-led consortium contract for a UK-wide ICTinfrastructure. This is a key initiative in the UK governement’sstrategy to create a lifelong learning society, and one whichexpounds the principles of brokerage in the education domain.

Mikhail Bessonov received his MSc Degree in Mathematics fromSt.-Petersburg State University, Russia, in 1993. He is currently apostgraduate student in the Department of Computer Science atUniversity College Dublin. His research interests include dis-tributed information retrieval and computer networks. As a mem-ber of project technical team, he took part in the design anddevelopment of library information systems, distributed WEBsearch engine and streaming audio software. His current researchconcentrates on the use of Directory services in large-scale dis-tributed search systems.

Mikhail Blinov is currently a full-time PhD researcher in theDepartment of Computer Science , UCD. He received his MScdegree from St. Petersburg State University in 1993. Prior tojoining UCD, he carried out design and implementation of themultiprotocol network router for Open Systems in Russia. Hisresearch interests include stream delivery, distributed applications,network management and information brokerage.

Ahmed Patel received his MSc and PhD in Computer Sciencefrom Trinity College of Dublin in 1977 and 1984, respectively.From 1978–82, he was responsible for developing the Irish Uni-versities Data Network, and from 1982–85, he developed theEuroKom computer conferencing and electronic mail service usedby R&D projects in Europe. At University College Dublin, he is alecturer in Computer Science and head of the Computer Networksand Distributed Systems Research Group. He is also CentreDirector of Teltec Ireland, a national R&D Centre of Excellencein Telecommunications within the Department of Computer Sci-ence. He is involved in various multi-national R&D projects inESPRIT, RACErACTS, INFOSEC, AIM, TELEMATICS, COSTand the Irish National Telecommunications programmes. His mainresearch interests include network management, security, proto-cols, performance evaluation, intelligent networks, CSCW andopen distributed processing systems. He has published manytechnical papers and co-authored two books on computer networksecurity and one book on group communications. He is a memberof the Editorial Advisory Board of the Computer Communicationsand Collaborative Computing Journals.

( )J. Hands et al.rDecision Support Systems 29 2000 305–321 321

Ron Smith received his MSc Electrical Engineering from theState University of New York at Buffalo in 1979. He has workedin international technical and management positions at Hewlett-Packard and WANG Computers. He is currently a senior consul-tant at KYROS in Athens, Greece. In this role, he has beeninvolved in a number of European Research projects includingGAIA, RENAISSANCE and GESTALT. His main areas of inter-est are Electronic Commerce, computer telephony integration andnetworking.