an application of the reference model for open distributed processing to electronic brokerage

An application of the Reference Model for Open Distributed

Processing to electronic brokerage

Mikhail Blinov, Ahmed Patel*

Computer Networks and Distributed Systems Research Group, Department of Computer Science, University College Dublin,

Belfield, Dublin 4, Ireland

Abstract

This paper presents the design of an Architecture for Electronic Brokerage Systems (AEBS). This architecture is based on

the Reference Model for Open Distributed Processing (RM-ODP) model. It specifies a brokerage system from five RM-ODP

viewpoints. AEBS include a generic model of electronic brokerage. It defines protocols and interfaces between actors. It enables

communication between actors via an advanced object-oriented interface (defined in terms of the Common Object Request

Broker Architecture (CORBA) technology) as well as using traditional trading protocols. These interfaces allow a broker to

operate in both the rapidly developing object-oriented CORBA environment and the electronic markets based on customary

protocols. CORBAwas also used for the design of the internal object model and internal interfaces of a brokerage system. This

paper focuses primarily on the specification of the AEBS architecture from the enterprise and computational viewpoints of the

RM-ODP model.

D 2003 Elsevier Science B.V. All rights reserved.

Keywords: Electronic commerce; Brokerage; CORBA; Software architecture; RM-ODP

1. Introduction

During the early days of Internet commerce, a

number of researchers claimed that there would be

no need for intermediaries in the electronic market-

place. Dramatic reduction of transaction costs in elec-

tronic methods of doing business, independence from

geographic location, and the availability of the infor-

mation infrastructure to a wide range of customers

were supposed to cause a prevalence of direct links

between customers and suppliers and hence the elim-

ination of intermediaries.

However, subsequent experience in electronic com-

merce has proven the opposite. The huge number of

suppliers offering their goods and services in the elec-

tronic marketplace made it virtually impossible for a

customer to communicate with every supplier directly

in order to find the product they need and to get the best

deal. So, the need for a broker emerged. Brokerage

systems can assist a customer during the trading pro-

cess and hide the diversity and distribution of informa-

tion from a customer.

To provide the maximum benefit from the intro-

duction of brokers to the electronic market, the de-

velopers of brokerage systems should have a common

architecture. This architecture should define the over-

all framework for brokerage. It should establish the

public interfaces of brokers to ensure their interopera-

0920-5489/03/$ - see front matter D 2003 Elsevier Science B.V. All rights reserved.

doi:10.1016/S0920-5489(03)00011-4

* Corresponding author. Tel.: +353-1-716-2476; fax: +353-1-

269-7262.

E-mail address: [email protected] (A. Patel).

www.elsevier.com/locate/csi

Computer Standards & Interfaces 25 (2003) 411–425

tion with other actors in the electronic marketplace,

such as customers and suppliers. These interfaces

should provide rich functionality required for broker-

age and cover all phases of the trading process. Since

customers and suppliers are known to be reluctant to

switch to new technologies, the architecture should

ensure that a broker is able to operate using traditional

trading protocols. The architecture should be scale-

able; it should facilitate communication between

brokers in order to create a distributed brokerage

service.

In the past years, there were several research pro-

jects that aimed at creating a brokerage architecture.

They differed in their coverage, their depth, and the

approaches they used. Unfortunately, none of the sug-

gested architectures met all the requirements for a

brokerage system.

The Common Brokerage Architecture (COBRA)

project [10] created a comprehensive framework for

electronic brokerage architectures. However, it did not

go any further. It did not define any protocols and

interfaces between actors and did not address related

interoperability issues. It also did not pay significant

attention to a possible federation between brokers.

An Open Service Model for Global Information

Brokerage and Distribution (OSM) project [6] tar-

geted at creating a framework for electronic com-

merce in general and addressed brokerage as part of it.

Unfortunately, the scope of the brokerage facility

defined by OSM is very limited and does not include

negotiation and delivery phases. The OSM architec-

ture is also inseparably bound to the Common Object

Request Broker Architecture (CORBA) model [14],

and so, it is limited to the CORBAworld. This model

does not define how a broker can communicate with

existing customers and suppliers who use traditional

trading protocols.

The Object Framework for Electronic Requisition-

ing (OFFER) project [2] extended the brokerage ser-

vices of the OSM architecture to cover the negotiation

phase. This project still did not go beyond CORBA

and the delivery phase was left out.

The Metabroker project [3], in contrast to the

OFFER project, aimed to provide a framework that

allows the integration of existing trading protocols

and data formats. Such a broker would adapt to the

needs of customers and suppliers rather than require

them to adapt to the capabilities of a service. Unfortu-

nately, the Metabroker project did not address the

related interoperability problems. It also considered

only the discovery phase of the trading process.

Object Management Group (OMG) established a

special Domain Task Force in Electronic Commerce

(ECDTF), which produced a working version of the

Electronic Commerce Reference Model [17]. This

model is largely based on the results of the OSM

project. Unfortunately, the ECDTF model inherits

certain disadvantages of the OSM architecture. It

limits the activity of the broker only to the discovery

stage of the trading process. Although the model itself

is generic, ECDTF has decided to specify the inter-

faces and protocols between the objects using only the

CORBA model. This does not address interoperability

with customers and suppliers who are already on the

market using traditional trading protocols.

In the past few years, a number of electronic auc-

tions, e.g. eBay (http://www.ebay.com), were created

on the Internet. These sites claim that they can operate

as brokers between customers and suppliers. Although

the popularity of these sites is growing, the function-

ality they provide is actually very limited. They are

heavily web-oriented, i.e. they provide only web-

based interfaces to both customers and suppliers and

they do not support any of the existing trading

protocols. This is acceptable for customer-to-customer

trading, but is hardly suitable for business-to-customer

or business-to-business trading. Existing electronic

auctions are also inherently unscalable since they

use only a centralised model and they do not make

any provision for distribution or communication

between brokers.

Recently, a number of attempts have been made to

solve the problems of electronic commerce using the

Extensible Markup Language (XML) technology

[24]. Some of the initiatives to mention are Commerce

XML (cXML) [11] from Ariba, XML Common Busi-

ness Library (xCBL) [4] from CommerceOne, XML/

EDI [25], RosettaNet [26], Electronic Business Exten-

sible Markup Language (ebXML) [5] from UN/

CEFACT and OASIS, and BizTalk [12] from Micro-

soft. None of them managed to become a predominant

solution by now, but ebXML and BizTalk seem to

have the most support from the industry at present.

These projects are mostly concerned with the second

half of the trading process, which corresponds to

order, delivery, and post-sales activities of the Archi-

M. Blinov, A. Patel / Computer Standards & Interfaces 25 (2003) 411–425412

http:\\www.ebay.com

tecture for Electronic Brokerage Systems (AEBS)

architecture. Unfortunately, these projects see XML

as a panacea for all problems. They expect all com-

panies to play by their rules and support XML-based

interfaces defined by a particular project. However, in

practice, it is highly unlikely that only one technology

wins. Usually, there are several (often many) compet-

ing technologies, and companies select those that are

the most suitable for their needs. So, the brokerage

architecture should be open and be prepared to use

different technologies for communications with differ-

ent suppliers.

This paper presents the Architecture for Electronic

Brokerage Systems (AEBS). The goal of the AEBS

design was to create a brokerage architecture that starts

with a generic reference model of brokerage and then

refines it into a precise specification of interfaces be-

tween actors. The AEBS architecture enables commu-

nication between actors via an advanced object-

oriented interface as well as using traditional trading

protocols.

The AEBS architecture is based on the Reference

Model for Open Distributed Processing (RM-ODP)

model [8]. This model defines a standardised way of

defining complex distributed systems. It identifies five

specific viewpoints (abstractions) from which a dis-

tributed system should be considered. These five view-

points are:

� enterprise viewpoint (the purpose and scope of

brokerage, model of the electronic marketplace);� information viewpoint (semantics of information

and information processing);� computational viewpoint (functional decomposi-

tion of brokerage system into objects that interact

at interfaces);� engineering viewpoint (infrastructure required to

support distribution);� technology viewpoint (system structure in terms of

hardware and software components).

These viewpoints represent different levels of

abstraction starting from the generic framework and

down to the breakdown of a system into hardware and

software components. This approach ensures that all

levels of the architecture design are defined. This

paper focuses primarily on the specification of AEBS

from the enterprise and computational viewpoints.

AEBS uses CORBA technology for defining the

computational and engineering specifications of the

brokerage system.

The conceptual ideas of AEBS were implemented

in the Generic Architecture for Information Availabil-

ity (GAIA) project to demonstrate the viability of the

architecture.

The following sections present the design of the

AEBS architecture from each of the RM-ODP view-

points. Section 2 specifies a brokerage system from the

enterprise viewpoint. Section 3 describes the informa-

tion viewpoint. Section 4 presents the computational

specification of a brokerage system. Section 5 consid-

ers the engineering viewpoint. Section 6 explains the

technology aspects of a brokerage system. Section 7

describes the implementations of AEBS and evaluation

results. Section 8 concludes the paper.

2. Enterprise specification

This section presents the specification of a broker-

age system from the enterprise viewpoint. This view-

point focuses on the purpose, scope, and policies for

the system. This specification defines a model of the

electronic marketplace and the trading processes

occurring there. It identifies the roles that can be

played by participants in the market and the activities

undertaken by them.

2.1. Brokerage definition

First of all, we have to specify what we mean by

brokerage. There are a number of definitions of

brokerage suggested in the literature. This research

work adopted the definition from the ACTS Guideline

for Enterprise Models of Electronic Brokerage [18]

since it was the most generic.

Broking takes place when market actors other

than the transacting parties are involved in the

organisation, presentation and publication of

information about market offers, leading to

managed transactions between offers and res-

ponders which may include mechanisms for post-

sales recourse. The term market includes public

services and administration as well as commerce

in goods and services.

M. Blinov, A. Patel / Computer Standards & Interfaces 25 (2003) 411–425 413

2.2. Roles

The policies of the brokerage services are derived

from the parties involved. These parties can be clas-

sified according to their roles. The first step of the

enterprise specification is the identification of the

roles that can be played by the enterprise objects

comprising the electronic market community.

There are a number of models of the electronic

marketplace proposed by different projects and organ-

isations. They suggest different sets of roles and

activities that are supposed to describe the electronic

marketplace. To identify which set of roles is the most

suitable for describing the processes in which a

broker is involved, the requirements for a broker

and its environment were studied [23]. It was found

sufficient to identify three principal roles played by

actors on the electronic market, namely customer,

broker, and supplier.

� Customer. The aim of the customer is to obtain

some product or information about some product.

The customer role initiates the brokerage oper-

ations and receives the results of them. The

customer may deal with actors who are playing

either of the other two roles: the broker or the

supplier.� Broker. The broker provides brokerage services to

the customer and the supplier. It responds to

requests from the customer to provide products, or

information about products. The products that the

broker supplies to the customer may originate from

one or more suppliers and/or brokers.� Supplier. The supplier is the source of the product

supplied to the customer. The supplier provides the

broker with information about the products that it

can supply. The supplier may supply the product

directly to the customer, or to the broker for

forwarding to the customer.

For the purpose of system representation, the

enterprise language of RM-ODP defines the concepts

of community and federation. A community is ‘‘a

configuration of objects formed to meet an objec-

tive’’, and a federation is ‘‘a community of domains’’

[8]. This enterprise specification defines that custom-

ers exist in the customer federation, suppliers exist in

the supplier federation, and brokers exist in the

broker federation. Some models comprise customers

or suppliers in the community. However, in the real

world, different groups of customers or suppliers can

belong to different domains (e.g. management or

organisational), which is a characteristic of the fed-

eration.

This definition is illustrated in Fig. 1. Although

RM-ODP defines comprehensive languages for each

viewpoint, it does not provide a graphical notation.

So, we will use the graphical Unified Modelling

Language (UML) notation [13] in this paper to

represent the design decisions.

An actor participating in the market can play

different roles while communicating with other actors.

Fig. 1. Roles in the electronic market.


For example, a broker enterprise can play the role of a

broker when it provides brokerage services to a

customer. It can also play the role of a customer when

it uses the services of other brokers.

Enterprise objects playing different roles in the

market can interact with each other in a number of

ways, each representing different supply chains:

� The minimal supply chain involves one customer

and one broker only. Each operation is initiated by

the customer, who makes a request to the broker.

The broker may have enough information to fulfil

the request if, for example, it has a local product

database. In this case, the broker does not need to

communicate with other participants and the chain

involves no other roles.� In a more complicated three-piece supply chain,

the broker deals with the customer and the supplier,

but not with any other broker. In this chain, a

broker collects information from a number of sup-

pliers and represents it to the customer. However, a

broker performs all brokerage operations in

isolation and does not use services of any other

brokers.� The full supply chain involves inter-broker com-

munication. Brokers are organised into a brokers’

federation so that they can use each other’s

services. In the event of a broker not being able

to fulfil a request, the request is propagated on to

other brokers, with the original broker now playing

the customer’s role. Each of these brokers may in

turn propagate the request if they cannot fulfil it.

Eventually, if the action is successful, a supplier

will be found who can fulfil the request. The

supply chain is thus made up of a single customer,

one or more suppliers, and one or more brokers.

The possibility of inter-broker connections in this

architecture dramatically enlarges the potential of

brokerage. This feature makes the architecture scale-

able. Brokers can specialise in different domains

(either by application or geographic meaning). How-

ever, a customer does not have to search for an

appropriate broker. The nearest broker that supports

inter-broker communications can accept the request

and fulfil it using the service of a broker specialised in

the area of request. If a new application domain or

area is available, it can be covered by the new broker,

which will propagate its services to all the members of

the federation. Some areas can be covered by different

brokers simultaneously. This creates competition

between brokers.

2.3. Activities

The next step of the enterprise specification is the

definition of the behaviour of the identified roles and

the activities undertaken by them. Following from the

results of the requirements capturing process [23], the

behaviour of the actors can be separated into the

following activities:

� Search. The search activity is carried out when a

customer asks a broker to find some information on

his behalf. To facilitate this, the customer provides

the broker with some description of the product

that he requires. On the basis of this description,

the broker carries out a search on behalf of the

customer and returns the results to him. The result

of a search activity is a set of unique identifiers

referencing the products matching the description

provided by the customer.� Locate. The locate activity is carried out when a

customer asks a broker to provide him with

information regarding the location of some product.

The customer provides an unambiguous identifica-

tion of the product, which may be the result of a

search activity. The broker returns information to the

customer about a source or sources of the product.

This data include the provisional terms of avail-

ability information such as methods of delivery

available, time of delivery, costs, etc.� Order. The order activity is carried out when a

customer asks a broker to obtain a product on his

behalf, or asks a supplier to sell the product directly

to him. The customer provides the broker/supplier

with product source information, which may be the

result of a locate activity. The order activity

consists of a negotiation phase and (possibly) a

purchase phase. During the negotiation phase, the

customer negotiates the terms of availability for the

(batch of) products. If the customer finds them

satisfactory, he commits to the purchase.� Delivery. The delivery activity is carried out when

a broker provides a customer with some requested

product. The product may be information, some


physical object, or metadata. The delivery activity

may be in response to an order activity, a search

activity, or a locate activity.� Post-sales. The post-sales activity is carried out

when a customer is not satisfied with a product.

The customer may complain about the quality of

the received product or indicate problems with the

delivery.

The normal sequence of activities is presented in

the collaboration diagram in Fig. 2.

The activities presented in this section normally

form an integrated sequence. However, this is not

necessarily the case. Activities may take place inde-

pendently. For example, order and delivery activities

may occur on the basis of information obtained by a

customer using some other mechanism than the search

and locate activities.

During any of the primary activities outlined

above, it may be necessary to carry out some support-

ing activities. Examples are security, payment, and

directory services. It is expected that the services

required to carry out the supporting activities will be

provided by the market environment.

3. Information specification

The information viewpoint is concerned with the

information that needs to be held and processed by a

brokerage system and other actors in the marketplace.

The detailed information specification of AEBS is

quite large since there is a significant amount of

information involved in the trading process. Since

this paper is intended to describe primarily the enter-

prise and computational specifications of AEBS, it

was decided to include here only a very brief outline

of the approach used for the design of the AEBS

information specification.

The AEBS information specification is defined

using the concept of schemata introduced by RM-

ODP. AEBS identifies information objects, defines

their states at various points in time (static schema),

evolution of information (dynamic schema), and con-

straints on the information objects (invariant schema).

These schemata are defined for each stage of the

trading process:

� Search phase specification defines such informa-

tion objects as query specification and product

description.� Locate phase specification utilises the product

description object defined at the search phase and

defines an information object for the product

location description.� Order phase specification includes an information

object that holds order details and status.� Delivery phase specification includes an item

identification information object for discrete deliv-

ery and stream management objects for stream

delivery.� Post-sales phase specification utilises item identi-

fication and order details information objects.

In addition, a global schema is defined, which

specifies information objects involved in the overall

management of the trading process such as session

information objects.

4. Computational specification

The computational specification defines the func-

tional decomposition of the system into objects that

interact at interfaces. This definition is performed in a

distribution transparent manner.

An initial requirement for the AEBS architecture

was that a brokerage system should support existing

application level protocols and data formats to com-

municate with existing customers and suppliers. How-

ever, during the analysis of the existing trading

protocols, it was found that they could not provide

the full functionality required for an electronic bro-

kerage service. A brokerage federation, for example,

can only be realised in part based on existing tech-

Fig. 2. Collaboration diagram of activities.


nologies. Therefore, a new special purpose protocol

for electronic brokerage was also required.

To satisfy both requirements, i.e. to support both

existing protocols and full brokerage functionality, it

was decided to design a dual interface for the broker-

age system (see Fig. 3).

One of the interfaces of the brokerage system is

defined in terms of existing protocols. This interface

provides the basic functionality of the brokerage

system to customers and suppliers who already oper-

ate on the electronic market. This allows easy inte-

gration of a broker into the existing electronic market

infrastructure.

A second interface to the brokerage system has

been created to provide the full functionality of a

broker. This interface has been designed according to

an object-oriented CORBA model [14] and using an

object-oriented methodology (see Section 4.1 for

discussion).

This approach provides both a good coverage of the

electronic marketplace (because of support of existing

protocols) and access to the rich functionality of the

brokerage system (using the advanced object inter-

face). Since a broker can support any protocol that is

currently in use on the market, it can communicate with

any existing actors in their own language. So, no

modifications are required on the customer or supplier

side to use the benefits of brokerage services. Only if

some actor wishes to use an advanced service is the use

of the object interface (via CORBA) encouraged.

When (and if) the CORBA technology becomes

supported by all customers and suppliers and the

CORBA services are exploited to their full potential,

the use of traditional protocols will become redundant.

However, at present, the CORBA technology is still

considered as new and most companies do not hurry to

deploy it. Even if CORBAwas a dominant technology,

there would be some alternative technologies as well

and there would be customers and suppliers that use

them. Therefore, it is very important for a broker to

keep ‘‘an open mind’’ and to support non-CORBA

technologies in addition to the CORBA interface.

Unfortunately, a single paper is not enough to

cover both external interfaces of the brokerage sys-

tem. So, in this paper, we will primarily focus on the

design of the external object interface of a broker.

In addition to the external interfaces of a brokerage

system, the AEBS architecture also utilises the

CORBA technology to define the internal object model

of a brokerage system and specify its internal inter-

faces. This provides a common framework for de-

velopers of such systems. The precise definition of

interfaces between objects allows different objects of

the broker to be developed independently. A broker

with the desired functionality can then be built by

connecting appropriate objects through the defined

common interfaces. This enables high broker extensi-

bility and provides a consistent method for dealing with

the heterogeneity of the environment. However, the

design of the internal model of a broker is out of scope

of this paper.

4.1. External object interface

This external interface was designed to provide

access to the full functionality of a brokerage system.

Although RM-ODP defines a framework for distrib-

uted system design, it does not impose any particular

methodology that should be used for the design of a

system from a particular viewpoint. The Object Mod-

elling Technique (OMT) methodology [21] was

selected by authors for the design of the external

object interface of a broker. The UML notation [13]

was used for graphic representation of the design

decisions. The CORBA technology [14] was used

for the actual definition of the interfaces. The high-

level class and sequence diagrams of the interface are

shown in Figs. 4 and 5, correspondingly.

The broker interface was built using the concept of

user sessions. To access the services of a broker, the

user has to start a session by logging into the broker.

The user session concept allows proper authentication

of users and access control. It also allows the system

to keep the current state and current properties of the

trading process for each user, and provides the neces-Fig. 3. Levels of functionality on the external interface.


sary information for logging, auditing, and tariffing. If

the services of a broker are publicly available, or if

personal information about the users is not required,

anonymous sessions may be allowed.

Having opened a session with a broker, a user can

start a trading process and go through its various

phases. This functionality is provided by the Trading

object. Several trading processes can be controlled by

the user in the scope of one session. They can be

performed sequentially or in parallel. For example, the

user may wish to search for different but related items,

or they can start a search based on the results of the

previous purchase. All these processes share the same

session context. However, they can target different

items, or serve different purposes for the user.

Each Trading object guides the user through differ-

ent phases of the trading process. Each of these phases

is controlled by the corresponding manager object,

such as search, locate, order, delivery, and post-sales.

The Trading object provides operations to advance

from one phase to another, rollback to the previous

phase, and jump to a particular phase. A rollback may

be required, for example, if a user is dissatisfied with

the results of a negotiation on the order phase; so, they

can rollback to the locate and search phases in order to

find another but similar product. Some phases of the

trading process can be skipped. For example, if a user

knows the identifier and location of the desired

product, they can start the trading from the order

phase and skip the search and locate phases. The

Fig. 5. Sequence diagram of the external object interface.

Fig. 4. Class diagram of the external object interface.


Trading object binds together various trading activ-

ities within one trading process. It is responsible for

synchronising them and for passing parameters

between them.

It should be noted that although delivery is one

activity from the enterprise viewpoint, it was decided

to represent it by two interfaces at the computational

level, namely DiscreteDeliveryManager and Stream-

DeliveryManager. The main reason was that these two

types of delivery (delivery of discrete items and real-

time streams) have significant differences in their

requirements, algorithms, and methods of support.

So, it was considered inappropriate to combine both

of them into one generic delivery computational inter-

face.

It is important for a broker to support not only

‘‘pull’’ information flow (a customer requests infor-

mation) but also the ‘‘push’’ model (a supplier dis-

seminates information). This is represented at the

interface by the AlertingControl object. It enables a

user to specify which kind of information the user

would like to receive.

4.2. Activity manager objects

Each activity of the trading process is controlled by

a manager object. Design of the manager objects was

based on the study of technologies existing in the cor-

responding areas. Design of the SearchManager and

LocateManager interfaces of the broker (the sequence

of operations and data structures) was largely based on

the ideas of the Z39.50 [1] protocol as one of the most

elaborated search protocols existing today. OrderMan-

ager, DiscreteDeliveryManager, and PostSalesMan-

ager interfaces were based on the operations of the

ISO ILL [7] protocol. StreamDeliveryManager inter-

face was influenced by the approach proposed by a

draft version of the Audio/Video Streams OMG spec-

ification [16].

Let us consider the design of a manager object

using the example of the SearchManager object. The

high-level class and sequence diagrams of the inter-

face are shown in Figs. 6 and 7, correspondingly.

A requirement of the search subsystem is that it

should provide a flexible way of searching. It should

allow several searches simultaneously. It should pro-

vide methods for both synchronous and asynchronous

searching. When synchronous search mode is

selected, user’s calls are blocked until all the results

are available. When asynchronous search mode is

selected, a user does not have to wait until the search

process is finished. The user can then initiate the

search and then receive notifications about its pro-

gress and results.

When a user needs to perform a search, they should

first specify a search query. This is performed by

creating an instance of the QuerySpec object and

instantiating it with the search parameters. Two types

of query should be supported: one for searching the

content of a target database and another one for

obtaining the description of metadata supported by a

target database (the ‘‘explain’’ query). Therefore, two

methods are provided to create these types of query:

NewQuery and NewExplainQuery, respectively.

To provide a simultaneous search, search agent

objects have been introduced. A search agent object

Fig. 6. Class diagram of the search interface.


(SearchAgent) is created for every search process and

is responsible for all the operations required to get the

subsequent results. The SearchAgent interface pro-

vides operations to start the search process. It can be

started in either synchronous or asynchronous mode.

Since the number of returned search results can be

large, a designated interface is required to deal with

the results list. The SearchResult interface has been

defined to provide this functionality. This object

provides access to all the hits returned for a given

search.

To support the asynchronous search mode, it has

been decided to use the Call-Back Target (CBT)

technique. The CBT objects are created by the user

on the user’s side and provide methods for asynchro-

nous notification of the user about new events during

the search process. Two different CBT objects were

defined: one for the search agent and another for the

search result object (SearchAgentCBT and SearchRe-

sultCBT, respectively). They provide different levels

of notification details, which provide more flexibility.

The remaining manager interfaces (i.e. LocateMan-

ager, OrderManager, and PostSalesManager) are

designed using a similar approach. The only excep-

tions are DiscreteDeliveryManager and StreamDeli-

veryManager interfaces.

As a result of considering different techniques for

discrete delivery, it was found that the existing proto-

cols (e.g. File Transfer Protocol [FTP] [19] or e-mail

[20]) are better developed in this area than the object

services. They are well known, widely supported, and

provide good functionality. For example, existing

delivery protocols are more suitable for the transfer

of bulky data than the protocols used in object environ-

ments. As for the stream delivery, the protocols used in

most object environments (e.g. CORBA) are not suit-

able for real-time stream delivery at all. Therefore, it

was decided to provide only delivery control function-

ality at the delivery object interfaces. The delivery itself

will be provided by traditional protocols, e.g. e-mail for

discrete delivery or RTP [22] for real-time stream

delivery.

Fig. 7. Sequence diagram of the search interface (asynchronous).


This approach also provides a unified way for

handling digital and physical products. The difference

is only in the negotiated transfer protocol. For exam-

ple, the ‘‘Post’’ protocol may be negotiated for phys-

ical products and ‘‘e-mail’’ or ‘‘FTP’’ for digital

products. All the rest (i.e. searching, locating, order-

ing, delivery control, post-sales activity) is exactly the

same for both digital and physical products.

4.3. Alerting control

This section describes objects supporting alerting

functionality at the user interface of a brokerage

system.

As defined in the high-level object model of the

interface discussed in Section 4.1, control of the

alerting operations is performed using the alerting

control object (AlertingControl). The main objective

of the broker’s alerting control interface is to allow a

customer to specify which kinds of events they are

interested in. The event is described in the form of a

query. It is considered that the event has occurred

when a query is satisfied. This interface also provides

customers with methods to indicate their preferences

as to how they should be notified about new events.

Internally, the AlertingControl object can provide

accumulated information about the user preferences to

other objects in the system. This information can be

used to personalise user access to the service. For

example, the SearchManager can use this information

to optimise searching for a given customer. However,

this is not visible at the external interface of the broker

discussed here. The external interface provides the

required methods, such as authentication of users and

managing user profiles. However, the exact way of how

the personalisation is implemented may differ between

different implementations of the brokerage interface.

5. Engineering specification

The engineering viewpoint focuses on the mecha-

nisms and functions required to support distributed

interaction between objects in the system.

In this research project, the technologies for com-

munication between distributed objects were consid-

ered. As a result, CORBA technology [14] has been

selected as the most suitable. This technology makes

physical distribution of communicating objects trans-

parent for these objects. The communicating objects

can exist in one address space, in different processes

on the same computer, or on different computers

connected by a network. In all the cases, the invoca-

tions of remote methods will be performed using the

services of Object Request Brokers (ORBs) trans-

parently for the objects themselves. The ORB resolves

all issues related to the transferring interface calls

between objects distributed over the network and

possible format conversions. CORBA does not

impose any requirements for the programming lan-

guage, operating system, and platform that are used to

implement particular objects. The interoperability

issues are addressed by the CORBA specification so

that systems can communicate with each other even if

they use different implementations of ORB. The

Internet Inter-ORB Protocol (IIOP) protocol used for

carrying requests over the network [14] was designed

to suit the requirements of both local and wide area

networks.

The remote method invocation process using the

CORBA technology is illustrated in Fig. 8.

As required by the CORBA technology, the speci-

fication of the External Object Interface of a broker was

mapped on to the OMG Interface Definition Language

(IDL) language [14]. This is a standard way of defining

interfaces in CORBA.

Fig. 8. Interface invocation process using CORBA.


For the initial location of objects, OMG has defined

two common object services: the Naming Service and

the Trading Service [15]. The Naming Service enables

a client to get a reference to the required object only if

they know the precise name of it. The Trading Service

is more advanced. It enables the location of objects by a

description. However, this service is still not widely

deployed. The alternative approach (or they can be

used in parallel) is the use of directory services. Today,

the Lightweight Directory Access Protocol (LDAP)

[27] and X.500-based [9] directory services are becom-

ing increasingly popular. They provide both locating by

a name and searching by a description. It is recom-

mended for a broker to publish a reference to its

external object interface in the broker’s entry in the

directory. The reference should be stored in the format

of an Interoperable Object Reference (IOR) defined in

Ref. [14].

It should be noted that, in contrast to other archi-

tectures, selection of the CORBA technology for the

implementation of the advanced broker object inter-

face in AEBS does not mean that no other technolo-

gies will be supported. All existing customers and

suppliers can still communicate with a broker via the

alternative basic level interface (Fig. 3) using tradi-

tional trading protocols. So, the AEBS broker, while

using the advantages of CORBA, does not get limited

to the CORBA world. It rather operates as a gateway

between CORBA and non-CORBA worlds. Fig. 9

shows how a broker can communicate with different

actors on the market using different protocols.

The engineering specification of the AEBS archi-

tecture defines also engineering aspects of the Exter-

nal Protocol Interface of a broker. This enables a

broker to communicate with existing customers and

suppliers using traditional trading protocols. However,

as stated in Section 4, the External Protocol Interface

of a broker is out of scope of this paper.

6. Technology specification

The technology specification describes the imple-

mentation of the distributed system in terms of the

configuration of objects representing the hardware

and software components of the implementation.

The AEBS architecture presented in this paper

does not explicitly define the technology specification

of a broker since this specification depends on a par-

ticular implementation of a system. The prototype

implementations of AEBS brokers performed during

the research project can serve as examples of possible

technology specifications for the AEBS architecture.

7. Implementation and evaluation

Now let us compare the designed AEBS architec-

ture with other architectures mentioned in Section 1

using requirements for a brokerage architecture out-

lined there. The results of the comparison are pre-

sented in Table 1.

Fig. 9. Bridging the CORBA and non-CORBA domains.


To demonstrate that the designed AEBS architec-

ture is generic and does not depend on any particular

domain of operation, implementation language, or

platform, four brokerage systems have been imple-

mented. Three of these brokers specialised in three

diverse application domains, namely publishing,

music, and technical data domains. The fourth imple-

mentation, called the reference implementation, was

created to demonstrate optional features that were not

required in the domain-specific brokers. The selection

of components implemented in different brokers was

based on the requirements of the particular domains.

Some broker components were also included to dem-

onstrate particular aspects of the architecture.

A number of experiments have been carried out

during the implementation of the prototype systems to

insure interoperability between systems. Different

programming languages (C++, Java), different operat-

ing systems (Solaris, Windows NT), and different

ORBs (Orbix, VisiBroker, OmniBroker) were used

for the implementation of different components. The

overall results of the tests were impressive. The con-

figurations, where different modules of a brokerage

system (stream delivery and directory services com-

ponents) were installed separately from the rest of the

system on the designated computers connected by a

network, were also tested successfully. In general, the

implementation experience proved that the CORBA

model enables independence from the implementation

language and platform, and it was also found to be a

suitable technology for assembling a complex and

heterogeneous system.

The prototype brokerage systems were installed on

five sites around Europe and tested during the public

trials. The trials were then evaluated using surveys,

input logging, and interviews.

The overall result of the public trial was positive.

Most users found the offered brokerage service val-

uable and easy to use. However, users also submitted

some comments and suggestions, which will have to

be addressed in the future work.

The most interesting feedback was from the music

domain trial. The music domain users suggested that

more functionality should be provided during the

awareness creation phase at the beginning of the trad-

ing process, more types of customer buying behaviour

should be supported. At present, the enterprise speci-

fication of the AEBS architecture includes the search

activity, during which a customer can identify what

they actually need. However, the corresponding com-

putational interfaces are mostly tailored to the search in

a catalogue of items. This is fine in, for example, library

domain. However, other domains, e.g. music, require

support of more implicit methods. An example is

impulse purchasing, when a customer is not explicitly

searching for a particular product, but buys a product

that they come across by some internal impulse. Some

users pointed out that buying music products, e.g. CDs,

Table 1

Comparison with other architectures

Project Brokerage

framework

External

interface

definition

Coverage Support for

traditional

protocols

Support for

inter-broker

communication

AEBS yes yes search, locate, order,

delivery, post-sales

yes yes

COBRA yes no awareness creation,

customer decision support,

sale transaction, post-sales

not mentioned no

OSM yes yes discovery only no yes

OFFER uses

OSM

yes discovery and

negotiation

no yes

Metabroker yes no discovery only yes no

ECDTF yes yes discovery only no yes

Web auctions no only

web-based

discovery and

negotiation

no no

XML-based direct

connections

prevail

yes order, delivery,

post-sales

no yes


is influenced by many things such as mood, surprise,

seeing, hearing, and touching. Therefore, more atten-

tion should be paid to influencing the needs of a

customer by a supplier or a broker, e.g. using advertise-

ment of a product. Results of psychological research in

this area should also be considered to provide users

with more appropriate shopping conditions.

8. Conclusion and future directions

The RM-ODP model was found to be suitable for

the design of the architecture. The defined viewpoints

covered all aspects of the architecture specification.

However, the computational viewpoint, due to the

large number of objects involved, was found to be too

wide and had to be further divided into subviews that

concerned external and internal models of a brokerage

system.

CORBA has proved to be a good technology for the

definition and implementation of the external and in-

ternal interfaces of a brokerage system. However, some

limitations of CORBAwere encountered in the areas of

stream delivery and bulk data transfer. Customary

protocols such as RTP or FTP were found to be more

suitable in these areas than protocols used in CORBA.

On the other hand, even in these areas, CORBA

interfaces could successfully complement the existing

protocols by providing delivery control functionality.

The OMT methodology enhanced by the UML

notation was found to be a convenient tool for the

design of the object models. It should be noted, how-

ever, that the terminologies used by UML and by RM-

ODP are different, which can lead to misunderstanding

at some points. However, these differences are not

critical and can be overcome. Since OMT was created

primarily for the design of applications, not all the steps

of this methodology can be applied to the design of the

generic architecture. Therefore, this methodology was

used mostly as a guideline for the design process.

The results of the public trials showed that most

customers were satisfied with the services provided by

AEBS brokers. However, further refinements and

improvements have to be done. The following future

directions can be identified:

� Support of the initial awareness creation phase of

the trading process should be enhanced. Other

types of customer buying behaviour, e.g. impulse

purchasing, should also be studied.� Support of the ‘‘push’’ model should be improved.

The AEBS architecture provides the alerting func-

tionality. However, a broker needs more methods to

influence the customer’s decision. This includes

advertisement and recommending products that

might be interesting to a customer according to

their user profile.� At present, the AEBS architecture defines interfaces

between actors in the electronic marketplace. To

complete the picture, interfaces with providers of the

supporting services, such as security, payment,

directory, and logistics, should also be considered.

Interviews with suppliers who participated in the

trials showed that they were mostly satisfied with the

technical aspects of the prototype brokerage services.

However, they stressed that the commercial aspects of

brokerage should be examined more carefully. This is

required to convince more suppliers to use the serv-

ices offered by a broker.

Acknowledgements

We wish to express our gratitude to Teltec UCD-

CS and the EU’s ACTS programme for research and

technological development for supporting this work.

We also wish to thank all members of the CNDSRG

group and the GAIA consortium for their co-ope-

ration, lively discussion, and valuable comments as

well as direct and indirect input to the development

process of the brokerage architecture.

References

[1] ANSI/NISO, Information Retrieval: Application Service Def-

inition and Protocol Specification, ANSI/NISO Standard

Z39.50, 1995.

[2] M. Bichler, C. Beam, A. Segev, OFFER—a broker-centered

object framework for electronic requisitioning, in: W. Lamers-

dorf, M. Merz (Eds.), Trends in Distributed Systems for Elec-

tronic Commerce, Lecture Notes in Computer Science vol.

1402, Springer, Heidelberg, Germany, 1998, pp. 154–165.

[3] S.J. Caughey, D.B. Ingham, P. Watson, Metabroker: A Ge-

neric Broker for Electronic Commerce, Technical Report

635, Department of Computing Science, University of New-

castle upon Tyne, Newcastle upon Tyne, UK, 1998. See also

http://w3objects.ncl.ac.uk/pubs/mbgbec/TR635.


http:\\w3objects.ncl.ac.uk\pubs\mbgbec\TR635

[4] CommerceOne, XML Common Business Library (xCBL),

version 3.5, World Wide Web, http://www.xcbl.org/xcbl35/

xcbl35.html, 2001.

[5] ebXML Consortium, Enabling Electronic Business with

ebXML, White paper, World Wide Web, http://www.ebxml.

org/white papers/whitepaper.htm, 2000.

[6] InfoWin ACTS Project, Information Brokerage, Deutsche Tel-

ekom Berkom, Berlin, 1998.

[7] ISO, Information and Documentation—Open Systems Inter-

connection—Interlibrary Loan Application Protocol Specifi-

cation, International Standard ISO 10161, 1997.

[8] ISO/IEC, Information Technology—Open Distributed Pro-

cessing–Reference Model: Overview, International Standard

ISO/IEC 10746-1, 1998.

[9] ITU-T, Information Technology—Open Systems Interconnec-

tion—The Directory: Overview of Concepts, Models and Serv-

ices, Recommendation X.500, 1997.

[10] M.J. Martin, J.E. Dobson, M.R. Strens, An Architectural Ap-

proach to Brokerage in Network Based Commerce, Technical

Report 642, Depatment of Computing Science, University of

Newcastle upon Tyne, UK, 1998. See also http://www.cs.ncl.

ac.uk/old/research/trs/abstracts/642.html.

[11] M. Merkow, cXML: A New Taxonomy for E-commerce, In-

ternet.com, Insights—EC Outlook, February, 1999. See also

http://ecommerce.internet.com/news/insights/outlook.

[12] Microsoft, BizTalk Framework 2.0. World Wide Web, http://

www.microsoft.com/biztalk/techinfo/framwork20.asp, 2001.

[13] OMG, UML Summary, version 1.1, OMG Technical Docu-

ment ad/97-08-03, 1997.

[14] OMG, The Common Object Request Broker: Architecture and

Specification, Revision 2.2, OMG Technical Document for-

mal/98-07-01, 1998.

[15] OMG, CORBA Services, OMG Technical Document formal/

98-12-09, 1998.

[16] OMG, CORBATelecoms, OMG Technical Document formal/

98-07-12, 1998.

[17] OMG/CommerceNet, Joint Electronic Commerce Whitepaper,

Technical Report EC/97-06-09, OMG, 1997.

[18] Plagemann et al., Enterprise Models of Electronic Brokerage,

Draft A, Guideline SIA-G3, ACTS, 1998.

[19] J. Postel, J.K. Reynolds, File Transfer Protocol, RFC 959,

Network Working Group, IETF, 1985.

[20] J. Postel, Simple Mail Transfer Protocol, RFC 821, Network

Working Group, IETF, 1982.

[21] J. Rumbaugh, M. Blaha, W. Premerlani, F. Eddy, W. Loren-

sen, Object-Oriented Modelling and Design, Prentice-Hall,

New Jersey, USA, 1991.

[22] H. Schulzrinne, S. Casner, R. Frederick, V. Jacobson, RTP: A

Transport Protocol for Real-Time Applications, RFC 1889,

Audio–Video Transport Working Group, IETF, 1996.

[23] R. Smith, D. Maroulis, GAIA Requirements Statement and

Assessment Criteria (Revision), Deliverable D0302, GAIA

ACTS project (AC221), 1997.

[24] W3C Consortium, Extensible Markup Language (XML) 1.0

(Second Edition), W3C Recommendation, World Wide Web,

http://www.w3.org/TR/2000/REC-xml-20001006, 2000.

[25] D.R.W. Webber, Introducing XML/EDI frameworks, Elec-

tronic Markets, vol. 8, No. 1, 1998. See also http://www.

electronicmarkets.org/netacademy/publications.nsf/all pk/

804.

[26] P. Yendluri, RosettaNet Implementation Framework (RNIF)

2.0, White paper, World Wide Web, http://www.rosettanet.org/

rosettanet/Doc/0/TAO5O8VV3E7KLCRIDD1BMU6N38/

RNIF2.1.pdf, 2000.

[27] W. Yeong, T. Howes, S. Kille, Lightweight Directory Ac-

cess Protocol, RFC 1777, Network Working Group, IETF,

1995.


http:\\www.xcbl.org\xcbl35\xcbl35.html

http:\\www.ebxml.org\white papers\whitepaper.htm

http:\\www.cs.ncl.ac.uk\old\research\trs\abstracts\642.html

http:\\ecommerce.internet.com\news\insights\outlook

http:\\www.microsoft.com\biztalk\techinfo\framwork20.asp

http:\\www.w3.org\TR\2000\REC-xml-20001006

http:\\www.electronicmarkets.org\netacademy\publications.nsf\all pk\804

http:\\www.rosettanet.org\rosettanet\Doc\0\TAO5O8VV3E7KLCRIDD1BMU6N38\RNIF2.1.pdf

an application of the reference model for open distributed processing to electronic brokerage

Documents