IEEE Network • January/February 2002
he rapid expansion of the Web and Internet technolo-
gies has created a revolution in the way information is
stored, processed, and delivered. In particular, the
financial sector has seen dramatic changes over the past
decade, especially in relation to the provision of online infor-
mation services (e.g., real-time share trading) and support for
a wide range of financial transaction services. A consequence
of these changes is the move toward new business models such
as global markets, 24-hour trading, and straight-through pro-
cessing. This trend is set to continue over the next decade .
The ability to efficiently and effectively share services on the
Web is a critical step toward the online economy driven by
business-to-business (B2B) e-commerce. Existing enterprises
need to form alliances and join their services to share costs,
skills, and resources in offering value-added services. For these
reasons, there is a trend to provide integrated services, that is,
services that are themselves made up of other services. For
example, an integrated service can automatically check the lat-
est financial information and carry out share trading and settle-
ment in a way that requires minimal user intervention.
The first impediment when considering the provision of an
integrated service is that it requires a formal description of the
business process involved, definitions of common knowledge
and data exchange policies, as well as other considerations such
as contract obligations between the partners involved. This arti-
cle assumes that these issues are already resolved and solely
concentrates on the problem of managing the interactions
between the software components that make up the integrated
service. Since these components may be heterogeneous and dis-
tributed, service integration at the infrastructure level is cur-
rently an ad hoc, very demanding and time consuming process.
It typically requires intimate knowledge of the underlying oper-
ating systems, networks, and programming languages. As the
infrastructure is modified or upgraded, maintaining the
integrity and availability of these integrated services is another
complex issue that needs to be addressed.
Our approach combines fundamental conceptual compo-
nents: a service-based architecture that supports integration in
capital market systems and a set of design patterns that can be
used for building integrated services. In the rest of this article,
we give some background information in the area of capital
markets. The architecture and its associated services are pre-
sented, and our software development methodology is dis-
cussed. Finally, we present conclusions and discuss future work.
An Overview of Capital Market Systems
Capital markets perform three key functions:
• To provide a cost-effective mechanism through which
providers of funds (investors) can meet users of funds
(companies). An example of such a market is the over-the-
counter (OTC) market.
•To provide a cost-effective mechanism through which investors
can readily liquidate their investments, thereby enabling them
to trade in or out of such investments. The Australian Stock
Exchange (ASX) is an example of such a market.
• To provide a cost-effective mechanism through which
volatility (risk) in the previous two markets can be mini-
mized. The Sydney Futures Exchange (SFE) is an example
of such a market.
Figure 1 illustrates the activities related to the trading life-
cycle. These activities are classified into four broad categories:
• Pre-trade: refers to activities prior to conducting a trade.
These include the delivery of historical and real-time infor-
mation about the state of the markets and companies,
together with analytics predicting future trends. They also
0890-8044/02/$17.00 © 2002 IEEE
An Integrated Service Architecture for
Managing Capital Market Systems
Fethi A. Rabhi and Boualem Benatallah, University of New South Wales
This article studies current developments and trends in the area of capital market sys-
tems. In particular, it defines the trading lifecycle and the activities associated with it.
The article then investigates opportunities for the integration of legacy systems and
existing communication protocols through distributed integrated services that correspond
to established business processes. These integrated services link to basic services
such as an exchange, a settlement, or a registry service. Examples of such integrated
services include pre-trade services (e.g., analytics) or post-trade services (e.g.,
surveillance). The article then presents the various levels of integration in capital mar-
ket systems and discusses the standards in place. It establishes that most interactions occur
at a low level of abstraction such as the network (e.g., TCP/IP), data format (e.g.,
FIX, XML), and middleware levels (e.g., CORBA). Finally, the article discusses a soft-
ware development methodology based on the use of design patterns. These design
patterns address the essential aspects of managing integrated services in a technolo-
gy-independent fashion. These aspects are service wrapping, service composition,
service contracting, service discovery, and service execution. The objective of the method-
ology is to facilitate the rapid development of new integrated services that corre-
spond to emerging business opportunities.
IEEE Network • January/February 2002
include selecting the best trading entity for a particular
securities transaction (order routing).
• Trading: refers to the trade itself, which can be achieved
through a number of entities including exchanges (e.g.,
Australian Stock Exchange), market makers (e.g., Nasdaq),
and electronic communication networks — ECNs (e.g.,
Instinet). In some cases, brokers themselves can act as
traders (this is known as internalization).
• Post-trade: refers to activities after a trade has been complet-
ed but not finalized yet. They include surveillance (e.g.,
detecting inside trading), compliance, and risk management.
• Settlement: finalizing the trade by transferring funds
between buyers’ and sellers’ bank accounts. Currently, set-
tlement occurs one or a few days after trading.
• Registry: this is the last part of the trade lifecycle whereby
ownership of securities is transferred to the buyers.
The efficiency of markets depends crucially on the design
of the various market mechanisms and, in particular, the tech-
nological infrastructure used to support the activities of the
transaction lifecycle illustrated in Fig. 1. One of the limita-
tions of the current infrastructure is that it still requires
human intervention at various points in the transition lifecy-
cle. For example, surveillance relies on a computer system to
raise alerts, which are then manually processed. Moving to an
integrated surveillance settlement system would reduce delays
and enable trades to be finalized much earlier, thereby
increasing the markets’ liquidity.
Toward a Service Integration Architecture
Since the ability to efficiently support integrated services is a
critical feature in the capital markets area, we propose a soft-
ware architecture for service integration. In general, the objec-
tives of a software architecture are :
• To enable some software components to offer services and
other software components to make use of these services,
thereby facilitating the development of distributed applications
• To allow software components to interact with each other
regardless of the languages, operating systems, and commu-
nication media used to implement them
• To provide rules for defining new compo-
nents and specify how components inter-
act with each other
Services offered by components typically
implement business functions in a way that
“hides” the underlying data formats or mid-
dleware platforms. For the moment, we will
ignore the issue of how services are defined,
advertised, and made available to the out-
side world. We will discuss this issue later.
We make a distinction between a basic ser-
vice and an integrated service. A basic service
can be entirely processed within one architec-
tural component. The component itself is not
necessarily a single application: it could be an
entry point for an enterprise workflow or ERP
system, but from the architecture’s perspective it is viewed as a
single component. A basic service can typically be a legacy system
with a software wrapper that makes the correspondence between
the system’s interface and the service interface. An integrated ser-
vice is a service offered by one component, but it involves the
interaction between this component and several other compo-
nents that provide “outsourced” services. These services can be
basic services or themselves other integrated services.
In relation to the trading lifecycle illustrated in Fig. 1, we have
identified the following basic services that must be supported
by the architecture (Fig. 2):
• The Exchange Service: transaction-based system that allows
trading of securities such as stocks, bonds, derivatives, and
currencies. Examples include the Stock Exchange Automat-
ed Trading System (SEATS), which operates on the Aus-
tralian Stock Exchange (ASX) , and SuperDot, which
operates on the New-York Stock Exchange (NYSE) .
• The Trading Data Service: manages databases that contain
records of past trade transactions. Examples of existing
databases include TAQ (transaction records from NYSE)
, CRSP , and Datastream .
• The Issuer Data Service: manages databases containing
information about securities issuers (e.g., accounting data,
announcements). Examples of existing systems include
COMPUSTAT , UBS Warburg , and Datastream .
• The Settlement Service: a transaction-based system that car-
ries out funds transfers between buyers and sellers after a
trade has taken place. Examples of existing systems include
CHESS  (operated by the ASX) and Austraclear 
(operated by the Sydney Futures Exchange).
• The Registry Service: completes the registration of shares
with new owners after settlement.
There are several integrated services that can operate during
part of or the entire trading cycle. Here are some examples of
•The surveillance service: in most current systems, it is essen-
tially a data mining and visualization service that operates
offline using transactions data (trading data service) and
company’s data (issuer data service). A technologically chal-
lenging problem is the provision of a surveillance service
that operates using real-time transactions data (from the
•The pre-trading analytics service: also a data mining service
that involves analyzing real-time data from the exchange ser-
vice and correlating with data from the issuer data service to
support buy/sell decisions. This service offers valuable
insights on companies and industry trends.
" Figure 1. The trading lifecycle.
" " Figure 2. A software architecture for capital market systems.
IEEE Network • January/February 2002
• The broker service: brokerage types vary widely in the quan-
tity and quality of the services they provide for customers.
The broker service essentially involves dealing with client
requests throughout the entire trading cycle (e.g., managing
customer databases, routing orders, reporting/accounting).
It involves several outsourced services such as pre-trading
analytics, exchange, surveillance, settlement, and registry.
Integration Levels in the Capital Market System
Figure 3 shows what we consider to be the three levels of
interaction between different software components in an inte-
grated service. In the upper level, the service level is the high-
est level in the hierarchy. It offers business services in a way
that “hides” the underlying data formats or middleware plat-
forms. It represents the appropriate level for defining inte-
grated services that correspond to particular business models.
The middle level is decomposed into two symmetric levels
which are the middleware level and the data format level. The
middleware level defines the interfaces of communication
between the various software components. The data level
defines the structure and format of messages between the
software components. At the lowest lowel is the network level
which provides support for the exchanges of data packets at
the network protocol level.
Network Level — For security reasons, most financial systems
interact with each other using private or dedicated networks.
An example is the SWIFT Transport Network (STN) 
based on the X.25 protocol. As communication software is
non-standard, this is a very expensive solution.
Other than for historical reasons, there is less and less
interest in integration at this level because of the low level
nature of the corresponding programming interfaces. Another
reason is that nowadays every networked platform supports
the Internet Protocol (IP), which is the common reference for
a suite of networking protocols based on TCP/IP. Even pri-
vate networks are now moving towards IP-based solutions
(Intranets and Extranets). For example, SWIFT is now devel-
oping a new generation of interactive services (called SWIFT-
Net) using an IP-based network called the Secure IP Network
Data Level — A data format refers to the content of the data
being exchanged between software components. In particular,
there is a need to represent non-trivial data in particular
application areas. A data format is usually accompanied by
translation software which is used to convert application data
into a standard message, then communicate this message to
another translation software which converts it back into appli-
cation data. This way, two completely different data sources
can exchange data with each other. The eXtensible Markup
Language (XML), which is an emergent set of open standards
managed by the World Wide Web Consortium (W3C), is
gaining widespread industry support for content management,
delivery and presentation at the Internet-based front-ends of
In parallel with XML developments, a number of interna-
tional organizations were already working towards the adop-
tion of common standards in the financial area. One of such
standards is the Financial Information eXchange (FIX) pro-
tocol  for communicating securities transactions between
two parties. Since FIX does not define how data is trans-
ported, an XML version of FIX called FIXML has been
defined . Another standard is FpML  which enables
e-commerce activities in the field of financial derivatives. In
each case, a working group defines a Data Type Definition
(DTD) that defines the XML tags and how they can be
legally combined. These DTDs can then be used with XML
parsers and other XML tools to rapidly create applications
to process and display the stored information in whatever
way is required.
Other related standards include ISO15022  which
defines a standard for messages in banking, securities and
related financial services. This standard is suitable for inclu-
sion within an XML format. Another standard is SWIFT’s
messaging service, FIN , which runs on its private network
(STN) and enables financial institutions to exchange standard-
ized financial messages worldwide.
Middleware Level — Middleware refers to a software layer
whose role is to ensure that a program can invoke operations
defined in another program even if the two programs are run-
ning on heterogeneous machines. The emphasis is that there
must be a common interface of communication between these
two programs. The most common example of a middleware
standard is OMG’s CORBA and its associated Interface Defi-
nition Language (IDL) . A CORBA service component is
a program which typically exhibits a set of operations (ser-
vices) defined in IDL and is accessible from any other compo-
nent in the network. Another popular middleware platform is
Enterprise Java Beans (EJB), only suitable for software com-
ponents written in the Java language. The future CORBA
Component Model (CCM) standard  has several features
of EJB so it is expected that the two middleware standards
will converge into a single one in the long term.
Besides the basic CORBA facilities, the OMG also manages
sets of domain interfaces for key operational domains such as
manufacturing and medical health. In the financial sector, an
OMG Task Force (called FDTF) has adopted a currency stan-
dard. Other financial standards in progress include a General
Ledger Facility, Party Management, and Risk Management.
Another relevant OMG Task Force is the OMG Electronic
Commerce Task Force working on various standards such as
Electronic Payment and Negotiation Facility. For more infor-
mation about CORBA domain interfaces, see .
" Figure 3. Integration levels in capital market systems.
Data level Middleware level
IEEE Network • January/February 2002
Building Integrated Services
There are numerous competing technologies for the definition
and provision of integrated services. One of the main concerns
in choosing a technology is that it must allow the integration of
existing standards and legacy applications. Another problem is
that since technologies evolve all the time, solutions can be out-
dated by the time they are developed and put in practice.
Our approach revolves around the concept of design patterns,
originally proposed by Gamma et al. . The idea of design
patterns is to facilitate the reuse of well-proven solutions based
on experiences from developing real systems. Given a library of
common “patterns” for designing software, developers choose
the pattern most adapted to their needs. Patterns are often
associated with object-oriented systems because of their sup-
port for reusability through classes and objects. One of the
main advantage of patterns is that they describe generic solu-
tions independent of any technology while giving pointers as to
how to implement them in particular contexts.
Design Patterns for Service Integration
Developing financial services in our architecture corresponds
to the more general problem of developing Web services for
B2B collaboration. The following design patterns, proposed in
, are currently being used:
• Service Wrapper Pattern: describes the mapping between an
abstract service description and its implementation, taking
into account heterogeneity of platforms and communication
• Service Negotiation Pattern: since an integrated service dele-
gates some of its service provisioning to other providers,
this pattern deals with the issue of negotiating and enacting
contracts between service providers and suppliers
• Service Specification Pattern: addresses the issue of building
integrated services out of other integrated or basic services
using a high-level notation that facilitates development and
maintenance of new services
• Service Discovery Pattern: deals with the issue of forming ser-
vice alliances on the fly
• Service Execution Pattern: tackles efficient execution of inte-
grated services taking into account considerations such as
performance and communication costs
Below is a brief description of each pattern. For more details,
Service Wrapper Pattern — The purpose of the Service Wrap-
per Pattern (SWP) is to separate a preexisting service specifi-
cation (e.g., service’s interface) from its implementation (e.g.,
a standalone program, an ERP application, or a workflow). A
service wrapper may be composed of a:
• Communication manager: E-services may use different com-
munication protocols (e.g., HTTP, Java RMI, CORBA,
IIOP, and DCOM). The communication manager should
support the translation of messages between heterogeneous
• Security manager: E-services may need to cross corporate fire-
wall and security systems in order to access partners’ services.
The purpose of this module is to handle security issues
including single mutual authentication corporate-wide, fine-
grain authentication, and access auditing and authorization,
communication integrity, confidentiality, and nonrepudiation.
• Content manager: It is likely that e-services use disparate infor-
mation formats and semantics. For example, if an internal
application uses xCBL to represent business documents, and
this application needs to interact with an external service that
expects documents in cXML, the conversion between these
two formats should be handled by the content manager.
• Conversation manager: This is concerned with the conversa-
tional interactions (i.e., joint business process) among e-ser-
vices. For instance, a given service may require a login
procedure to be performed prior to any access to the ser-
vice’s functionalities, while another service with similar
capabilities may provide access to some functionalities of
the service without password verification, and only require
a full login procedure for accessing other functionalities.
This pattern is suitable for the integration of existing capi-
tal market systems into basic services (e.g., integrating the
SEATS system  into an exchange service).
Service Negotiation Pattern — The purpose of the Service
Negotiation Pattern (SNP) is to abstract contracts for a given
service into contract templates to avoid building contracts from
scratch. A contract template is a function that generates a
contract given a set of contract parameter values that capture
the variable part of a class of contracts.
The negotiation between a prospective consumer and a
provider can be manual, semi-automated, or fully automated.
In general, the degree to which a negotiation can be automated
depends on the nature of the negotiable parameters. If the
number of parameters is fixed and their values are numerical, a
high degree of automation can be attained. In the extreme case,
when only one parameter is variable and the domain of this
parameter can be modeled as a set of numbers (e.g., the price),
the negotiation can be reduced to an online auction. If new
parameters can be introduced during the course of a negotia-
tion, or the domain of the parameters is not known in advance,
the negotiation must involve human actors. Still, even if human
actors carry out the actual negotiation, their interactions and
decision-making can be facilitated by software tools.
This pattern can be used in different situations. For exam-
ple, if a settlement service is invoked as part of a broker ser-
vice, it is very important that the contract obligations between
a user of the broker service be maintained during settlement.
Service Specification Pattern — The purpose of this pattern is to
specify the interactions among the components of a composi-
tion service without referring to any implementation or execu-
tion model. The specification of interactions among services
must include descriptions about both control flow and data flow.
The control flow establishes the order in which the component
services should be invoked, the timing constraints, the signals
that may interrupt or cancel their execution, and so on. On the
other hand, the data flow captures the flow of data between
component services. An example notation is statecharts .
This pattern is suitable for the definition of any integrated
service such as surveillance and pre-trade analytics services.
Service Discovery Pattern — The purpose of the Service Discov-
ery Pattern is to facilitate the automatic discovery of services.
Given that services are described using software-interpretable
information (i.e, using meta-data or ontology languages), this
facility provides a means (e.g., service discovery engine) to
locate services based on constraints over their meta-data.
A number of industry efforts to define standards that pro-
vide common building blocks for e-service discovery and inte-
gration emerged recently, including Universal Description,
Discovery, and Integration (UDDI), Web Services Description
Language (WSDL), and ebXML. UDDI provides an XML-
based registry for advertising businesses and services. The
advertisement and discovery of services and businesses in
UDDI exploit keywords categorization. An advertisement of a
business includes name, key information, categorization, and
offered services. An advertisement of a service includes name,
key information, categorization, and multiple bindings.
IEEE Network • January/February 2002 Download full-text
This pattern can be used by a broker service to do order
routing, that is, finding the most appropriate exchange service
to carry a particular transaction.
Service Execution Pattern — This pattern supports two possibil-
ities in executing an integrated service:
• The components of an integrated service are coordinated by
a central scheduler hosted by the provider of the integrated
service (components may be distributed).
• The entities participating in an integrated service coordinate
the execution in a distributed manner (e.g., through peer-
In the former, the scheduler of an integrated service S is
responsible for initiating the execution of the components of S
according to the control flow associated with S. In the latter,
the responsibility of coordinating the execution of an integrat-
ed service is distributed across the providers that host the
components of the integrated service.
Service execution efficiency is a very important issue. For
example, the surveillance service has to deliver adequate
response time despite the huge number of transactions per-
formed by the exchange service.
Software Support for Integrated Services
Based on our previous experience [21–23], we wish to take the
design pattern concept one step further. Instead of each
design pattern being an informal entity, we are proposing to
make it part of a software development tool that captures the
essential characteristics of the pattern and uses pre-imple-
mented and pretested software modules that support the
“generic” features of the pattern (possibly in different lan-
guages and platforms). All that is left to the application devel-
oper is to generate an instance of the pattern through the
provision of some parameters that are specific to their appli-
cation. A similar tool has been developed for distributed
applications in areas as diverse as high-performance comput-
ing , fault-tolerant computing , and distributed real-
time systems . An experimental tool that assists the
application developer in the definition and implementation of
integrated services is currently under development. In particu-
lar, the tool will enable the definition of surveillance and bro-
ker integrated services. This tool is based on the SELF-SERV
prototype , a platform for integrating Web services.
Conclusion and Future Work
This article discusses the design and implementation of dis-
tributed applications in the area of capital markets. It identifies
the different levels of interconnectivity and reviews the emerging
standards. It also proposes a software architecture that allows
components to interact with each other at the service level.
Based on this architecture, it advocates the use of design pat-
terns and associated software tools to facilitate the development
of integrated services. The advantage of this approach is that it
provides the appropriate level of abstraction for the definition
and implementation of services in the face of rapid technologi-
cal changes. To the best of our knowledge, there have been no
previous similar attempts at using a similar approach in the area
of capital market systems. Future work will concentrate on final-
izing the architecture and refining the design patterns according
to existing practices and experiences with a proven track record.
This work was supported by a 2001 University Research Sup-
port Grant from the University of New South Wales (Project
no PS00048). We would like to thank Bill Northcott, Eric
Leach, Jack Hassall, and Mike Aitken for providing advice,
help, and support in the area of capital market systems. We
would also like to thank Marlon Dumas, Marie-Christine Fau-
vet, and Graham Low for their contributions to the architec-
ture and design patterns.
 SWIFT, “Building for Tomorrow: A White Paper on the Features and Benefits of
SWIFT’s Next Generation of Products and Services,” 1999; http://www.swift.com
 L. Bass, P. Clements and R. Kazman, Software Architecture in Practice, Addi-
 The Australian Stock Exchange (ASX): http://www.asx.com.au
 New York Stock Exchange: http://www.nyse.com
 New York Stock Exchange Inc., The Trade and Quote (TAQ)’s User Guide,
 Center for Research in Security Prices (CRSP), Graduate School of Business,
Univ. of Chicago: http://www.crsp.com
 Thomson Financial, Datastream Advance v. 3.0 (Historical Analytic Services),
 Standard and Poor, COMPUSTAT databases (IMS Products),
 UBS Warburge: http://www.ubswarburg.com
 Australian Stock Exchange, Clearing House Electronic Subregister System
(CHESS) — An Introduction, http://www.asx.com.au/about/ pdf/CHESSIntro.pdf
 Sydney Futures Exchange (SFE): http://www.sfe.com.au
 FIX Protocol Ltd., “The Financial Information Exchange Protocol (FIX),” v.
4.2, Mar. 2000, http://www.fixprotocol.org
 FIX Protocol Ltd., “FIXML: A Markup Language for the FIX Application Mes-
sage Layer (White Paper),” http://www.fixprotocol.org
 FpML.org, “FpML v. 1.0, Trial Recommendation,” Sept. 25, 2000,
 ISO, ISO 15022,, http://www.iso15022.org
 OMG, http://www.omg.org
 OMG, “CORBA Component Model Request for Proposal,” OMG doc.
orbos/96-06-12, 1996, http://www.omg.org
 E Gamma et al., Design Patterns: Elements of Reusable Object-Oriented
Software, Addison Wesley, 1995.
 B. Benatallah et al., “Towards Patterns of Web Services Composition,” Inter-
nal rep. TR0111, School of Comp. Sci. and Eng. University of New South
Wales, Sydney, Australia,
 D. Harel and A. Naamad, “The STATEMATE Semantics of Statecharts,”
ACM Trans. Software Eng. and Methodology, vol. 5, no. 4, Oct. 1996,
ACM Press, pp. 293–333.
 P.J. Parsons and F.A. Rabhi, “Generating Parallel Programs from Paradigm-
Based Specifications,” J. Sys. Architectures, vol. 45, no. 4, 1998, pp. 261–83.
 M.E. Outram and F. A. Rabhi, “A Skeleton for the Design of Parallel Fault-
Tolerant Systems,” Proc. DCCS ’2000: 16th IFAC Wksp. Dist. Control Sys.,
Sydney, Australia, Nov./Dec. 2000.
 F.A. Rabhi, H. Cai, and B.C. Tompsett, “A Skeleton-Based Approach for the
Design and Implementation of Distributed Virtual Environments,” Proc. 5th
Int’l. Symp. Software Eng. for Parallel and Dist. Sys., Limerick, Ireland, June
2000, pp. 13–20.
 B. Benatallah et al., “Declarative Composition and Peer-to-Peer Provisioning
of Dynamic Web Services,” Proc. Int’l. IEEE Conf. Data Eng., San Jose, CA,
FETHI RABHI (firstname.lastname@example.org) obtained his first degree in computer science
from Algiers University in 1986 and his Ph.D. in computer science from the Uni-
versity of Sheffield in 1990. He was a lecturer at the University of Hull for 10
years before joining the University of New South Wales as a Senior Lecturer in
April 2000. He held visiting appointments at Allegheny College in 1991 and
Trinity College Dublin in 2000. His research interests are in programming lan-
guages, parallel and distributed systems, and software engineering. He has pub-
lished a book, Algorithms: A Functional Programming Approach (Addison
Wesley) and several papers (including a forthcoming edited book) on software
patterns in parallel and distributed computing. His latest research work involves
the application of information technology in the area of finance.
BOUALEM BENATALLAH (email@example.com) graduated from Oran Univer-
sity of Technology, Algeria, in 1991 with an engineering degree in computer
science. In 1992 he joined Joseph Fourier (IMAG) University at Grenoble,
France, where he received an M.S. in computer science in 1992 and a Ph.D. in
computer science in 1996. Afterward, he held appointments at Queensland Uni-
versity of Technology (QUT) as a research associate and at James Cook Univer-
sity in March 1998 as a lecturer. In March 1999 he joined QUT as a lecturer in
the School of Information Systems and deputy director of the Centre for Cooper-
ative Information Systems. During this period he was also a visiting scholar at
Purdue University. Since July 2000 he is a senior lecturer at the University of
New South Wales. His latest work focuses on electronic commerce, Web
databases, workflow management systems, and mobile databases.