EMP — A Database-Driven Electronic Market Place for Business

Transcrição

, , 1–32 ()
c Kluwer Academic Publishers, Boston. Manufactured in The Netherlands.
°
EMP — A Database-Driven Electronic Market
Place for Business-to-Business Commerce on the
Internet
SUSANNE BOLL, ANDREAS GRÜNER, ARMIN HAAF, WOLFGANG KLAS
{boll, agruener, ahaaf, klas}@informatik.uni-ulm.de
Database and Information Systems (DBIS),
Computer Science Department, University of Ulm,
Oberer Eselsberg, 89069 Ulm, Germany
Abstract.
Electronic commerce systems for business-to-business commerce on the Internet are still in
their infancy. The realization of Internet electronic markets for business-to-business following a
n-suppliers : m-customers scenario is still unattainable with todays solutions. Comprehensive Internet electronic commerce systems should provide for easy access to and handling of the system,
help to overcome differences in time of business, location, language between suppliers and customers, and at the same time should support the entire process of trading for business-to-business
commerce. In this paper, we present a DBMS-based electronic commerce architecture and its
prototypical implementation for business-to-business commerce according to a n-suppliers : mcustomers scenario. Business transactions within the electronic market are realized by a set of
modular market services. Multiple physically distributed markets can be interconnected transparently to the users and form one virtually central market place. The modeling and management
of all market data in a DBMS gives the system a solid basis for reliable, consistent, and secure
trading on the market. The generic and modular system architecture can be applied to arbitrary
application domains. The system is scalable and can cope with an increasing number of single
markets, participants, and market data due to the possibility to replicate and distribute services
and data and herewith to distribute data, system, and network load.
Keywords: electronic commerce, electronic market place, trading, relational database management system, JDBC, Java, Internet, WWW
1.
Introduction
Today, international trading of products, i.e., goods and services, by small companies is mainly carried out via traditional communication channels. Suppliers
address customers by means of mail, phone, fax, and direct personal contact. Customers find suppliers by means of the various kinds of advertising, by yellow pages,
and even by hearsay.
International business-to-business trading becomes even more difficult for small
and medium-sized companies, suppliers and customers, in rural and remote regions.
In this case for both suppliers and customers it is hard to identify international business partners; time of business, location, language are only some of the additional
barriers to be overcome. Comparison of different offers on the international market,
strategic placement of offers according to market dynamics and the like are difficult,
expensive or even impossible.
2
Hence, a common international electronic market place dedicated to a particular
vertical market could overcome these difficulties in trading especially for small companies, the place on which suppliers can place offers and meet their customers, the
place on which customers find a variety of offers of one or many suppliers and on
which they can compare, select, and negotiate offers. Preferably, for those parties
this market place should be easy to find and to enter and should be independent
of time, place, and trade.
To make an electronic commerce system attractive for the clientele addressed
above electronic commerce systems should demand neither expensive hardware nor
expensive software prerequisites. These companies need a simple but comprehensive
software solution that easily opens them the door to a possibly well populated open
electronic market place to trade on. Hence, the usage of the Internet, Web browser,
and Java applets lays near at hand. The users will demand the system to be secure
and this calls for consistent data management and the consideration of security
aspects at multiple levels in the system.
Today, business-to-business commerce is mainly based on Electronic Data Interchange (EDI), a standard for conducting business over electronic networks. It
enables companies to order products, bill customers, track accounts receivable, trace
product shipments, and transfer funds electronically.
EDI differs from other types of electronic commerce in that two parties who want
to transact business must have some kind of business relationship first. EDI transactions are generally carried out over secure value-added networks built specifically
for EDI, such as IBM’s Global Network and the network operated by GE Information Services.
Because such networks are quite expensive, most EDI customers are large companies. Although EDI has traditionally been available only on value-added networks,
it is becoming available on the Internet [4]. For example, GE Information Services
recently introduced a secure link between its network and the Internet, so businesses using the GE Information Services network can exchange private documents
such as purchase orders and invoices with companies over the Internet. However,
although the link to the Internet is secure, anything sent over the Internet is not
secure unless it is encrypted. Current work in the context of EDI tries to overcome
these limitations in linking EDI networks together with the Internet.
Although EDI is the most successful form of business-to-business electronic commerce available today, it is still quite costly and causes too much overhead and
difficulties for being used by small and medium-companies.
Most major IT vendors have announced and/or developed individual Internet
commerce platforms. Prominent examples are IBM CommercePOINT [9], Microsoft Site Server 3.0 Commerce Edition [16], Oracle Internet Commerce Server
[17], INTERSHOP [12], Sun/ JavaSoft JECF (Java Electronic Commerce Framework) [21]. These systems provide interesting services like security, payment, directories, and catalogs to be integrated with existing systems and the Web, but all
of them are largely proprietary. Only a few basics like HTTP, HTML, and SSL
serve as de facto standards. INTERSHOP for example is a quite static system
based on templates and pre-configured settings, where Microsoft Site Server en-
EMP — AN ELECTRONIC MARKET PLACE ON THE INTERNET
3
ables through its pipeline technology the extension of the commerce system and
commerce functions.
We will briefly look at the different degrees to which todays Internet commerce
systems support trading on an international market.
•
On many places in the WWW, in addition to advertising and offering products
on an HTML page, orders can be made online which is then processed at the
WWW server, e.g., via cgi-scripts (e.g., Lehmanns Online Bookstore (LOB)
[13]). Acknowledgment of the order is often made per separate mail. Sometimes
additional order confirmation is to be made by the customer per separate fax,
mail, or phone call.
•
A first step into the direction of the integration of payment into the electronic
Internet commerce is the (secure) submission of a user’s credit card number,
e.g., within the online Amazon Bookstore [1]. But this only brings the initiation
of the payment into the system, payment itself still takes place off-line.
•
An example of the integration of payment into the electronic Internet commerce
system is realized by my-world, the online shopping mall of Karstadt AG [15].
The mall offers integrated online payment based upon IBMs CommercePOINT
Payment[10] solution which uses Secure Electronic Transaction (SET) protocols.
Todays Internet commerce systems, however, still do not really cover the various
aspects of trading within the system. Although, there are many development and
research projects going on (e.g., SEMPER [7], OSM [8], NetBill [11, 20], ICETEL [6]) which address particular issues like payment schemes and security, these
projects do not aim at the development of an integrated electronic market place.
We identify the following deficiencies of current electronic commerce systems:
•
Electronic commerce systems are often only an electronic realization of a traditional shop scenario. Only some places in the Web reconcile shopping information of a set of shops but this does not necessarily form a real market place.
The shops must often be entered separately and comparative selection of offers of different suppliers is not possible (e.g., Electronic Mall Bodensee (EMB)
[5, 25]). Many companies have simply placed their product catalogs in the Web.
In the case of WizNet [23] one supplier forms a market with n (sub)suppliers and
brings together multiple catalogs of suppliers but with this system the user can
not order online. What is still missing is an integrated electronic market place
realizing an n-supplier-m-customer scenario for business-to-business trading.
•
Electronic shops are not easy to find. Generally a user has to find the electronic
shop or mall by his/her own, though search engines partwise support lists of
shopping malls, e.g., Yahoo! [24].
•
Electronic commerce systems often lack comprehensive search facilities. Real
useful search facilities are often lacking since search is often carried out only
on the basis of pattern matching or existing search engines available on the
4
web such as Altavista [3]. Even if malls do offer search over all the shops, e.g.,
SNAP [19], Yahoo! [24], ShopHotBot [18], and Bodenseemall [5], searching very
often results in many irrelevant and useless hits. Nevertheless, the shops provided by SNAP, Yahoo!, and ShopHotBot, which are based on Junglee’s Virtual
Database (VDB) [14], are interesting for their technology in turning webpages
into a virtual database. Of course, they have to deal with the limitations and
differences of the covered sites. An approach which allows searching dependent
on specific attributes is Jango (see e.g., www.jango.com). Jango allows for example to search for a wine produced in a distinct year. The results are only
products which meet exactly the criteria given by the user. This is similar to
our approach for searching products.
•
Electronic commerce systems have only limited support for online dynamic changes
to the market data. The systems generally allow only the site administrator to
administer the suppliers’ offers. Adding new product types into a running system is not possible.
•
The trading process is only partially supported by electronic commerce systems.
Functionality for handling contracts, logistics, financing, negotiation between
customers and suppliers, and other more sophisticated issues for trading including multi-language support are lacking.
In this paper, we propose a new approach for a comprehensive solution for an
electronic market place for business-to-business trading via the Internet trying
to overcome most of the deficiencies mentioned above. We present key concepts,
functional description, system architecture, and prototypical implementation of a
DBMS-based electronic market place using existing Internet and WWW infrastructure.
The system architecture proposed is generic and can be applied to an arbitrary
application domain for electronic markets with one solitary supplier but also a community of many suppliers and the respective customers, realizing an n-supplier-mcustomer scenario. The system is designed to offer a comprehensive set of market
services supporting the whole process of trading on the electronic market place
independent of the application domain. The management of market data by underlying DBMS technology gives the system a solid and consistent basis that allows
for scalability of participants and traded products. The system combines the accessibility of the Internet with reliable relational database technology for the electronic
market place.
With a layered and modular design of the market we aim at developing an electronic commerce system that is not bound to a specific proprietary solution, but is
open in the sense that existing advanced products and approaches under development can be integrated into the system, i.e., an approach comparable to the eCo
System, a “framework of frameworks” for electronic commerce proposed in [22].
To evaluate our approach in terms of flexibility, openness, and fast adaptation of
the system in different application domains, various prototypes have been developed
in different application domains. The initial basis for all these developments is
5
the Electronic Market Place (EMP) system which we report on in this paper in
more detail. The EMP prototype served as the basis for the implementation of
the RMP application [2] developed in the context of the European project Rural
Market Place (RMP1 ). In turn, the RMP project provided user and application
requirements for EMP. RMP aims at the realization of an n-supplier-m-customer
scenario for international business-to-business trading between companies in rural
regions. Currently RMP is released to users in particular regions and will become
accessible worldwide later in 1998. RMP is hence the first commercial instantiation
of the EMP approach.
The remainder of the paper is organized as follows: Section 2 presents the key
concepts behind our Electronic Market Place. Thereafter, in Section 3, we give a
functional description of the market place along the building blocks, that is the
users and their roles in the electronic market, the various services available in the
market, and their cooperation. Section 4 describes the system architecture and
the exploitation of database technology for the Internet-based electronic market
place system. Section 5 describes the prototypical implementation of the Electronic
Market Place. The paper concludes with a summary and gives an outlook to further
research in our project.
2.
Conceptual Framework for the Market
In this section, we present the concepts behind the DBMS-based electronic commerce system in the Internet proposed in this paper. These concepts are based
upon the user needs elaborated in the context of the RMP project. They aim at
an integrated electronic commerce solution that adds value to traditional trading
and that gains the users’ confidentiality into the value, validity, and the security of
the electronic commerce system. We developed generic concepts that address the
particular problem area of overall support for trading in the Internet.
We designed an electronic market place that is easy to access, easy to use, and
useful. It offers a comprehensive set of market services that support the whole
process of trading and follow a modular design. The market place is dynamic,
extensible, and stable. It gives a unified view to all market data that is transparently
managed by the underlying database system. The market place is virtually central
but consists of transparently distributed markets and is designed to be interoperable
with other vertical markets. And finally, the market place provides secure and
serious functionality to earn the users’ confidentiality.
2.1.
Easy to access, easy to use
The system architecture is targeted at an easy access to the market. Especially
small companies do not have much experience in selecting non-standard platforms
and software and are cautious with investing in expensive, possibly business specific solutions. Therefore, we decided to base our system on existing WWWInfrastructure and make use of the platform independent language Java. With the
6
usage of Java applets the participants are releaved from installing and maintaining
the electronic commerce software on their local platform.
A unified graphical user interface provides easy usage of the system. A user has
the possibility to tailor the usage of the electronic market place to personal needs.
2.2.
Comprehensive and integrated set of market services for trading
Internet commerce systems today only partially support the whole process of trading. The concept of our market, hence, is to offer a wide range of market services
that, altogether, offer comprehensive trading functionality on one electronic market
place and thereby support most of the trading process within one single system.
Additionally to the basic services of a traditional market, buying and offering, they
are integrated within the system with value-added services like the intensive market
search. Hereby, comparison of offers and selective filtering of all the offers in the
market is provided to narrow down all the available offers to those of interest. A
customer can compare prices and selling conditions of the different suppliers of one
or more products, a service which can only be realized with a tremendous effort in
a traditional international market. The market offers a seamless integration of all
available services. For example, the market offers the possibility to directly call for
a logistic service within the buying service, or call a financing service of a bank.
2.3.
Dynamic and extensible market
The suppliers on the market may want to place new offers and to adjust offers to
changes on the market at any time. Therefore, the electronic commerce system
should allow each customer to insert and update his own offers and not only the
administrator. Customers want to see only up-to-date offers. Hence, there should
be no delays between the point in time when changes to market data are released
and when these changes become visible to the other market participants. If, e.g., the
electronic market was a stock exchange such delays were unbearable as in this case
the actuality of the market’s data is the most important aspect. On the electronic
market place, competitors want to dynamically react to the market and adjust
prices, payment conditions, or the like. Therefore, the market allows suppliers to
place and maintain offers online and changes are visible to customers immediately.
To achieve the genericity of the market the market services must be extensible
and adjustable. Therefore, the seamless integration of new services like a logistics
service into the system must be possible. If services of the electronic market place
used by a vertical market are replaced or new services are added the system neither
have to be recompiled nor reinstalled. A new service can be integrated into the
running electronic market system - the services can just be plugged in and pulled
out into and from the running system. If a new service is available it simply is
engaged and that becomes available to all users immediately.
2.4.
7
Consistent data management
With the trading carried out on the electronic market place , associated market
data arises which are to be reliably managed by the market’s DBMS. This does
not only apply for the data describing products but also for information about the
organization of this data, about offers and trading in general, about user and service
specific data and security information like access rights.
All market data, e.g., the price or the available quantity of a product, must be
up to date and reliable. For example, the available quantity of a product must be
consistently reduced if some units of the product have been sold. To establish a
trustworthy system access to the market and its data must be controlled. Therefore,
access rights must be maintained, i.e., which participant on the market can access
and change which market data. As to support an individualized user interface to
the market place user profiles need to be stored and maintained. The up-andrunning market place stores information about which service is currently available.
Each running service relies on a reasonable amount of information, e.g., the access
rights of the user currently using the service. The product data must be organized
in a way that the search services perform well on the underlying storage system.
Therefore, information about the organization of the products must be stored as
metadata so that it can be exploited when searching the market.
The management of all market data by a relational DBMS gives the system a
solid and consistent basis that provides the scalability of participants and traded
products. Section 4 will discuss the database schema design in detail.
2.5.
Transparent distribution of a virtually central market place
The electronic market place works on a virtually central electronic market place
server, whereas the services and the data can be distributed over different market
servers. For the users the electronic market place is a virtually central place somewhere in the Internet. Users are connected via a lean Java front-end running in a
browser on a user’s machine to the electronic market place’s back-end. The latter,
however, need not to be central but can be transparently distributed. It consists
of a collection of interconnected uniform market servers. The electronic market
system handles the mediation between the user and the market services running on
the distributed market servers. The distribution applies for the market data which
is only meant to be managed by relational DBMS technology but not necessarily
stored centrally. The degree of distribution and the degree of location transparency
depends on the special instance of the system and the size of the market. The market architecture has an extensible design allowing for the incorporation of CORBA
and the Internet Inter-ORB Protocol (IIOP).
2.6.
Interoperability
Market services may not be restricted to be used only within the market. One could
think of agents that knock on the market’s door and ask for some offers on the
8
market. Also the sneaking out of market services to other markets can be thought
of. The electronic market place should be designed such that it can further be
integrated and it can interoperate with existing conventional HTML-based web sites
and with new services built on existing proprietary electronic commerce platforms.
An important feature of this approach is that the resulting system is not bound
to a specific proprietary solution, but is open in the sense that existing advanced
products and approaches under development can be integrated into the system.
When used with CORBA and IIOP the electronic market place offers the services
to the world by means of interface definitions of the services. The Object Request Broker (ORB) knows the interfaces and location of the services and mediates
between service users and the distributed market services.
2.7.
Security
From a user’s perspective it is very essential that the market is serious and secure.
To assure this the market must employ several layers of security. First of all access
to the market can be limited to authorized users by means of a registration in
the first place and an authorization check each time the market is entered. A
classification of users into user groups allows for a more fine grained association
of privileges to user groups. Depending on the privileges the user holds, a user
is allowed to perform a distinct action, e.g., a customer can not place an offer,
only a supplier can do so. Access restrictions when writing and/or reading data
from and to the market database must be enforced. For example, a supplier must
not change, e.g., the price of an offer of any other supplier. Furthermore a lot of
quite obvious security mechanisms are integrated into the system such as secure
data transmission between the client and the server side of the market as well as
between the multiple market servers.
The market place needs to offer its services reliably. Therefore, mechanisms are
provided to ensure that the available services are always up and running and if not
so that they are made available again while the system is still running.
3.
Users and Services of the Electronic Market Place
In this section, we give a detailed description about the users and the services of
the electronic market place system. Section 3.1 identifies the different user types
of the market and how they participate in the electronic market place in detail.
Section 3.2 describes the modular design of the services of the electronic market
place and their functionality and gives some examples of the services.
3.1.
Classification of participants of the market
We have developed a classification of user types of the electronic market place based
upon requirements of the end users of the RMP project. Figure 1 illustrates our
classification which is described in the following.
9
Vertical Market Users
Non-registered
Users
Registered Users
Administrators
Visitors
Customers
Suppliers
Content
Admins
System
Admins
Figure 1. User types of the electronic market place
The different types of users that participate in the market show special requirements in which users of a specific type want to take part in the market. The main
distinction that can be made is that between non-registered and registered users.
This allows for a non-registered visit of the market place but at the same time
ensures limited access to the actual trading. A registration mechanism can provide
for the seriousity of suppliers and customers and supports the confidentiality of all
participants of the system. To have the option of plugging in any future commercial
electronic payment services later on, a distinction of registered and non-registered
users significantly facilitates the integration of such services.
The only type of non-registered users we consider is a visitor that can be anyone
who surfs the net and (accidentally) enters the market place. This user type allows
people to get in touch with and become involved into the electronic market place
without forcing them to register in the first place. In addition, it allows to track nonregistered users’ interest in the market and adjust the attractivity of the market
correspondingly. Visitors can use only limited functionality of market services,
mainly services on information about the system and the available content.
Given the business-to-business scenario the electronic market place system has to
provide and maintain status information about users, their business transactions,
orders, delivery, etc. In such a scenario, the business partner are very sensitive
to trading in a trustworthy environment. This calls for the implementation of a
concept for registered users. Which services, however, users can use and which
they can not is determined by the respective user type to which a user belongs.
Therefore, a more detailed classification of users is necessary that describes the
different types of users and how they take part in the electronic market place.
We identify three different groups of registered users: customers, suppliers, and
administrators. Customers are users who are interested in buying some of the
market’s products. Suppliers are users who offer products to all (registered) users
of the market place. Users can be members in multiple groups, e.g., be suppliers
and customers of the market. Administrators are users who have to maintain
and run the system. A further distinction can be made between operational staff
that maintain content provided by the market services, e.g., general information
services, and system administrators are users who are allowed to use specific system
administration services needed to operate the entire system.
10
This user concept calls for a management of user types, their associated properties
and access rights, and of user profiles, and the association of user types and even
user groups to services. The user concept is part of the security mechanisms of the
system.
3.2.
Examples of services of the Electronic Market Place
A service is a part of the EMP system which provides some kind of functionality to
the user or the system itself. They form the functionality of the electronic commerce
system. The design of the available services is modular to make the service modules
reusable like in a unit construction system. We distinguish three layers of services
in the system:
•
Market Services are the sophisticated services the users get in touch with. They
comprehensively support trading on the market, e.g., offering, buying. They
build upon basic and business services.
•
Business Services are small reusable modules that realize some market functionality. They are designed so that several market services can make use of
these modules.
•
Basic Services realize all basic functionality needed by the system. They handle
all sensitive actions in the system like database access to product data, trading
data, user data, etc.. Also most of the authentication is realized at the level
of the basic services, e.g., check whether a user or a service is allowed to use a
specific service. So it is not possible to access a basic service without the proper
authentication and access rights.
Figure 2 illustrates the layered design of the services.
In the following, to illustrate the layered service architecture, we give some examples of the services of the three layers.
3.2.1. Sample market services Some of the market services are available to all
kinds of market users. The different user types, however, also have different views
to the market and therefore, some market services can be used only by a specific
user type. Sample market services provided for all user types are:
•
Registration service and authentification service. The registration service allows
a user, generally a visitor, to once register to the system in one of the user types,
e.g., as a customer. Registration results among others in a user identification
and password. These are used for the authentification service each time the
market is entered as a registered user. Visitors need not to register when they
enter to the electronic market place via a special visitor user account. These
services implement part of the security mechanisms of the system.
11
Services
Registration
Authentification
Buying
Offering
Maintenance
Help
Information
Management
...
Market Services
Service Profiling
User Profiling
Notification
Search for suppliers
Editing
Search for offers
Visualization
...
Business Services
Encryption Authentication verification
Authorization verification
Product data organization
Product data access
...
Basic Services
Figure 2. Service architecture of the Electronic Market Place
•
Assistance or help service. This service can be used to obtain system help
and documentation regarding the operation of the market place. It is available
throughout the entire market place that is for the usage of all market services.
The help and assistance information is provided in the language selected by the
user.
Sample market services for specific user types are:
•
•
Offering service - a market service provided for suppliers. Suppliers are users
who offer products, i.e., goods or services, on the market place. The market
service offering serves for this business and comprises functionality like:
–
Offer placement, the central operation used to build up and extend a range
of products with any number of offers. This service allows to collect product
data and to insert it into the hierarchically organized product data of the
market. Offers can be addressed to one user as well as to groups of users.
After releasing, offers are immediately visible to the aimed customers of the
electronic market place.
–
Offer maintenance and modification allowing for online administration and
modification of offers by the suppliers themselves.
Buying - a market service provided for customers. Customers are users who
search, order, and buy products on the market place. The market service buying
serves for this business and comprises functionality like:
12
–
Search functions: The system provides a variety of search functionalities
depending on the different information needs of customers. As a default,
the system allows to comprehensively and selectively search for suppliers
and products. In the future, the system may provide additional search
functionality on specific information needs of customers, i.e., a user can
search for inquiries for products not yet offered within the market but asked
for by customers.
–
Order functions: Ordering allows a customer to contact a specific supplier,
to order a product according to an offer, to explicitly request further negotiations, and, if possible, to complete the business transaction under the
given business terms.
–
Negotiation functions: A customer can initialize a negotiation process. A
negotiation process starts with an initial offer. Both parties, customers and
suppliers, can modify the offer. During negotiation special offers can be
added which reflect the modifications of the initial offer. A customer can
compare different special offers created during a negotiation process and,
if confident with a special offer, he can choose the one as the basis for an
order.
Payment is a very sensitive part of a business transaction. The typical way how
payment is realized in current business-to-business transactions is by invoice.
Customers are used to pay their goods after they received them or maybe even
later. This is exactly the payment scheme which is supported by EMP, although
the architecture is open to include well-established electronic payment schemes
at a later point in time, when they are mature.
•
Agent services may be used to ask specialized agents to perform specific tasks.
For example, search agents may be used by customers to inform them about
new products and offers which are added to the system, asynchronously. The
customer specifies a filter (like a normal search filter as used in the buying
service) to the agent. The agent queries the database on regular time intervals
and sends back an e-mail to the user if it finds an appropriate entry. The
notification includes a detailed description of the found entries.
•
Administrative services provided for administrators include content maintenance
services and site, user, and system management services.
3.2.2. Sample business services Business services are reusable modular components. The different market services employ one or more of the business services in
their service specific context. For example, the offering service allows a supplier to
browse his offers, the buying service allows a customer to browse offers of different
suppliers. Both market services use the same business service for searching and
browsing offers.
•
Service profiling allows to specify for each market service a set of service specific
settings which can be stored for the usage by each individual user.
13
•
Search for offers allows to search for any product offered on the market. The
service takes as input any attributes describing the product in question. The
selective attributes can be logically combined, range values of attributes can be
given for this search.
•
Visualization services are responsible for generating a graphical/textual representation for different (complex) data types like the product data or the hierarchical product classification (e.g., as a tree). This allows to react fast to user
requests for a different representation, without changing code, just by adding a
new visualization module.
3.2.3. Sample basic services Basic services are small basic units the layer of
business services builds upon. Examples are:
•
Security service provides basic security mechanisms for all basic services. It
also includes the mechanism to check whether a user/service is allowed to use a
method of a service he/it wants to invoke. This service uses the identification
and privileges of the user and the service privileges to check the privileges of
the user/service combination.
•
Authorization verification service verifies if a user is allowed to use the requested
(market, business, basic) service.
•
Product data access service provides all operations necessary to retrieve, add,
change, and delete product data in the database.
4.
4.1.
Architecture — Distribution Aspects — Database Design
Architectural overview
The Electronic Market Place (EMP) system has a multi-client/multi-server architecture as illustrated in Figure 3. An EMP client is a computer system connected to
the Internet with a Java-enabled WWW Browser running on it. A client connects
to the electronic market place via the market’s home HTML page. The trading
itself is carried out via the Electronic Market Place’s front end, namely the GUI
realized with applets running in their browser.
The Electronic Market Place system presents itself to the users as one central
market place. From an architectural point of view, however, it is a collection of interconnected EMP market servers. When a client enters the electronic market place
it in fact contacts one of the EMP market servers, it’s home market server. Each
market server in the EMP system has the same system components. The market
place’s trading functionality is formed by the services running on each server. The
Service Information Center (SIC) administers the market’s services, and mediates
client requests for services and the actual service modules. Each market server has
associated a local relational database management system for the maintenance of
14
market data. This data in the underlying relational DBMS is managed and accessed
via the DBMS’s JDBC Driver.
The transparent interconnection of the many market servers of the system is
realized by two system components, the Distributed JDBC Driver (DJDBC) and
EMP’s Binding Server (EBS). Each market server can read from any database in
the market. This unified view of the market servers to all databases in the system is
established via a Distributed JDBC component at each market server. The binding
service ensures that each market server knows the location of the currently available
market servers in the system.
Client
Client
Client
WWW
Browser
WWW
Browser
WWW
Browser
WWW
Server
Market
Server
Distributed JDBC
Greece
SIC
Binding
Server
SIC
Market
Server
WWW
Server
Distributed JDBC
JDBC-Driver
JDBC-Driver
Rel. DBMS
Rel. DBMS
DB
Spain
Binding
Server
Internet
DB
Figure 3. System Architecture of the Electronic Market Place
In the following sections, we present the aspects concerning the design of the
database schemas, the distribution of data and services, and distributed data access
in more detail.
4.2.
Database design
We describe in the following how the different types of market data, i.e., product
data, offer data, trading data, product hierarchy, user specific data, service specific
data, and access rights, are modeled in the database schema. We use the relational
data model for the modeling of the market data, make use of the DBMS inherent
15
security and consistency mechanisms and let the market services exploit the DBMS
technology for querying market data.
4.2.1. Modeling the organization of product data Product data describe products
but do not include the data which describe offers and data concerned with trading.
The purpose is to separate general product descriptions, which do not change very
often, from offers that might change frequently. For example, if a farmer offers milk
the product description does not change very often, but the offers may change often
depending on the season.
Each product is characterized by its product specific attributes. One problem
with existing systems covering the e-commerce part of the electronic market place
system is that they do not support flexible and dynamic product descriptions. They
build up a model or even database schema for the expected product types and their
attributes however are limited to those. In our system products are organized in a
hierarchy. The generic type product forms the root of the product type tree. Every
node in that tree represents a specific product type. Each node has associated the
name of the product type it represents and some product type-specific attributes.
In addition to these it inherits all the attributes from its parent product type in
the tree and the insertion of new products by means of a new node is still possible.
Hence, product data are strongly related to data describing the organization of the
product data. Figure 4 illustrates the product organization.
The database representation of this product tree, that is the metadata about the
organization of the products, is realized in a single table with three attributes. It
stores the name of the product type, refers to its parent product type in the table
and stores the table name in which the data of products of this type are stored.
4.2.2. Modeling the product data The database representation of the product
data follows the organization in the product tree. Each node in the tree has associated a table. Only the attributes specific to this product type are modeled in
this table. To logically connect the data of a product of a specific product type which is spread over several tables each keeping a part of the product’s attributes
- a special attribute in each table is used. This special attribute is a unique key
of all products. The tables containing the data for a specific product are joined
together exploiting the hierarchical structure of the product tree (these tables are
used in the join) and the special key attribute. An example of a SQL statement to
read the data of the product type wine is:
SELECT
FROM
WHERE
p.name, p.baseunit, f.genmanipulated, l.volume,
a.alcoholcontent, w.quality, w.grapetype
Product p, Food f, Liquid l, Alcohols a, Wine w
p.id = f.id AND p.id = l.id
AND p.id = a.id AND p.id = w.id
The attribute id is a unique key. The product attributes used in the sample query
are those shown in Figure 4. Figures 4 and 5 a) illustrate the product organization
16
and the mapping to the relational database schema. Figure 5 b) shows the resulting
table when querying wine with the sample SQL statement above.
Product
name, base-unit
gen-manipulated
Food
a)
Solid
Product
id
package-type
name base-unit
Food
milled
Corn
id
Vegetables
biological
Liquid
origin
Fruit
Liquid
gen-manipulated
id
volume
volume
Alcohols
Alcohols
alcohol content
Wine
Beer
Non-Alcohols
Juice
id
alcohol content
quality, grapetype
Wine
id quality grape-type
purity reuqirement
no special attribute
flavour
b)
id name
base-unit
gen-manipulated
quality grape-type
Non-Food
Figure 4. Hierarchical organization of product
types
Figure 5. Mapping to relational schema: (a)
Product organization of wine with a set of tables (b) Resulting table when querying wine.
The splitting of product information into smaller units increases the number of
tables but lets us search non-leaf product types that are represented by inner nodes
in the product tree. For example, if somebody wants only non-gen-manipulated
solid food, he searches for non-gen-manipulated solid food in the products of type
solid food. The result will be all the products of the (sub)types corn, vegetables,
and fruit that are non-gen-manipulated. Otherwise, a user had to search each of
the leaf product types, corn, vegetables, fruit for non-gen-manipulated products.
4.2.3. Extensibility of the product hierarchy The organization of the product
hierarchy lets us add new product types dynamically. So in the first place a structuring must be prepared for the specific application domain. Then the tree can be
arbitrarily refined. For example, to add a new leaf in the tree, (1) the metadata of
the product tree must be updated and (2) a new table with the new product type’s
attributes is created. Another advantage of the chosen organization of product
data is that we can easily remove or insert a new attribute which will be “inherited” to all of the sub product types. The only limitation is that attributes of each
of the single tables in one path in the product tree have to use differently named
attributes. For example, in the path product-food-solid-corn there can not be an
attribute “biologically grown” in the table representing the product type food as
well as in the table for the (sub)product type corn as the table resulting from a
17
selection of the entire product data of corn would then have two columns with the
same column name.
If new product types are inserted into the product hierarchy a new product hierarchy “package” is generated and distributed to all market servers by the organizational institution of the Electronic Market Place that maintains the product types.
As regards the database schema, the package contains the new create table instructions for the new product type and the insert and update instructions to
introduce the new type in the table storing the product organization.
4.2.4. Offer data Offer data are all data which describe an offer. Figure 6 shows
the relationship between products and offers and a rough outline of an offer. A
supplier can maintain multiple offers per product whereas an offer always belongs
to exactly one product, obviously. Although packaging, delivery, and quantity
are modeled here as attributes they are complex objects and may represent even
multiple attributes. For example, packaging is divided into several layers: unit
level (e.g., milk measured in liters), product level, the minimum packing unit for
this offer (e.g. milk bottle 0.75 liters), and package level (e.g., carton of 6 bottles).
Only products on offer can be traded on the market. The products can be part of
different offers with different offer data like a different price and quantity.
4.2.5. Trading data Trading data describes all attributes and actions related
to the actual process of trading, that means related to negotiating, ordering, and
buying a product. Each offer is stored in an offer table in which one attribute
refers to the offered product’s id. All orders are stored in a table and each relates
to exactly one offer.
1
Product
...
1
Offer
1
n
0,1
Negotiation
1
Agreement
Quantity
n
Offer
Calling Condition
Order
Quantity
1
Calling Condition
Producer Response
Packaging
Price
Suggested Price
n
Quantities
Figure 6. Offer data
Delivery Time
Delivery Type
Quantities
1
Delivery Time
Delivery Type
Price
Business
Transaction
...
Figure 7. Trading related data
18
In addition to the storage of information about offers and orders in the system
it is necessary to allow negotiation on various attributes of an offer. This enables
customers as well as producers to act very user specific. To increase this flexibility
even more the system handles customer specific offers. This allows suppliers to
maintain and supply different offers for, let us say, both a wholesaler and a tiny
shop. A customer can negotiate the offer with the supplier. A negotiation is always
started by a customer. Negotiation is carried out by exchanging offer data with
changed values between customer and supplier until they both agree on the final
offer. An initial negotiation can be followed by any number of negotiation steps.
Not only the final offer they agreed on but also the process of negotiation is modeled
and stored in the system. The negotiation is completed with a special offer or the
cancellation of the negotiation process.
For legal reasons order agreements must be stored in a separate table containing
all the information on the business transaction. This allows easier monitoring of
any actions following this business transaction. This is done in a separate table,
optionally even in a separate table space to support security and trustworthy of the
system. Figure 7 sketches the relationships and characteristic attributes of offers,
orders, business transactions, and negotiations.
4.2.6. Security data We support several security levels in the system as indicated
in Table 1. The most obvious is the authentication of users. Each market service is
furnished with privileges that are needed to use it. So it can be used only by users
that have the necessary privileges. At a lower level all basic services are bound
to the authorized usage by a market service. Basic services check whether the
market service - and that implicitly also means the user - is allowed to process the
requested action. All connections to the database include a username/password
combination. This gives each connection distinct rights and privileges. Part of
the security mechanisms rely on security data/information which we model in the
database system like user access rights and service privileges:
Table 1. Security Levels
•
Security Level
Security Mechanism
Users
Market Service
Basic Service
Database Security
Authorization
Authorization
demand privileges from users/market services
demand privileges from basic service
User access rights. Users are identified in the market place via a market place
unique identifier. Users have to provide a username/password combination
at registration time to the electronic market place organizational authority2 .
This information is encrypted and stored in the database. Whenever users
19
login to the system their authentication is checked. This restricts the market
to authorized users. Depending on the privileges the user holds the system
decides if a user is allowed to perform a distinct action (e.g., if a user is allowed
to modify product data).
•
Service privileges. All sensitive actions take place within basic services. Basic
services do check at invocation time the privileges the invoking service holds
and additionally the privileges the user using that service owns. Therefore, not
only the users’ access rights are stored in the database but also the privileges
of every market service running on the market server. These rights are mapped
to a privilege for a specific user/service combination. Therefore, the system
provides service authorization, e.g., only authorized market services can use the
basic service to access offer data. Furthermore, the system ensures at the lower
levels of the core system that no evil market service can access basic services or
sensitive data. This is realized by each basic service which checks if a market
service is allowed to use it.
•
Restricted database access. To achieve restricted access to the database each
basic service holds a set of privileges. Therefore, only a few basic services have
access to the database system.
4.2.7. User and service profiling To adapt the system’s appearance and functionality to specific users, user profiles are implemented. They are modeled as a
set of attribute-value pairs and are stored at the home market server. User profiles
contain attribute values to adapt the appearance of the market’s front-end like the
background color. Additionally, profile values like the language adjust the presentation to the user-preferred language. And, furthermore, attributes related to the
user specific interest may be used to narrow down search results. For example, if a
customer is interested only in biologically grown products so he will not be offered
any other than biological products. The protection of the privacy of profile data is
achieved by the security mechanisms of the basic services and the database system
so that nobody except the user owning the profile can read and update the profile.
Besides attributes characterizing a specific interest a user can define search filters.
They are used to give a better overview of products or offers. For example, a user
selects red wine via the GUI. There are many red wines and many offers to that
products. The user, however, wants to see only red wine with attributes like “price
below 5 DM”and “alcoholic content less than 13%”. He fills in these constraints in
a search filter for red wine and gets a filter that suits his personal needs. Search
filters are stored in the user profile, so the user can reuse them. When reused, the
corresponding SELECT string is constructed from the search filter. If the result of
the user query using that search filter is empty, the filter can be used to install a
kind of search “agent” of the Electronic Market Place to regularly look for an offer
matching the constraints of the search filter. This “agent” then notifies the user by
e-mail about the newly arrived product or offer.
Also services can be tailored to user preferences. For instance, the buying service
stores the currency the user prefers to pay with. Therefore, each service can store
20
service specific user profiles. These profiles are modeled in the database schema like
the user profiles mentioned above. Additionally, only the service which created the
profile is able to read and update the user-specific data. This mechanism is again
implemented by the basic services.
4.3.
Distributed JDBC
The DJDBC Driver of each market server encapsulates multiple JDBC Drivers.
One of these is the JDBC connection to the local database of the market server.
The others are JDBC connections to the other market servers in the system. Every
database system for which a JDBC Driver is available and which is compliant to the
SQL standard can be used with this approach. The DJDBC handles the unified
access to both remote and local market data. As the distribution and also the
replication of data has consequences on the realization of the DJDBC driver we
consider this first before the database access via the DJDBC driver is explained.
4.3.1. Distribution of data The distribution of data is realized following a “write
local and read distributed” policy. The data that changes very often within the
system are the offer data, the user data, trading data, and service data. To be able
to write this data only local the data must be local, too. If this data in addition
was replicated on all the market servers we would run into the typical problems
of keeping replicated market data consistent. Therefore, we decided to partition
the data that changes frequently non-replicated over all the market servers in the
system but avoid data replication. Each market server holds only that data that
are associated with a specific set of customers and suppliers. This market server is
the home server of these users and they enter the market via this market server.
The only replicated data in the system are the hierarchy of products which do
not change very often. The product hierarchy determines the organization of the
product data in the entire Electronic Market Place system. The information about
the product organization is essential for each of the market services on each server.
For example, a product of a specific type can not be inserted into the local database
if the associated product type describing the attributes of the product type is not
contained in the hierarchy. The same applies for the retrieval of products. Therefore, it is necessary to have the metadata about the organization of the product
data available at each market server. Even though product organization is the
same at each market server the available product data may differ because of the
unique assignment of users to a home server. All market servers know the attributes characterizing a specific product although this product may not be stored
at each market database. Because of the homogeneous view on products, i.e., all
EMP Market servers have the same product hierarchy and consequently the same
database schema for the organization of the data, user queries to a market server
are simply handed over to all other market servers to retrieve the overall result.
If new product types are to be introduced to the market place the respective new
entries are made by the one organizational institution that maintains the product
21
types. This institution then generates and distributes a new product hierarchy
“package” to the market servers. On receipt of the package a market server creates
the new tables, updates the product hierarchy representation and inserts the new
Java product classes that are necessary to access and use the new products types
in the services. This does not necessarily need to be a synchronous distribution
as long as only one organizational institution changes and distributes the product
hierarchy. The market server that has not received the new product hierarchy
simply can not yet insert and retrieve product data of that new type. If a market
server receives a query on a product type that has not yet been inserted into the
product hierarchy the initiating DJDBC handles the exception.
SELECT * FROM products, food WHERE genmanipulated = ’1’
SELECT * FROM product, food
WHERE genmanipulated = ’1’
T-1
JDBC
Driver
Rel. DBMS
T-ROOT
T-2
Distributed JDBC Driver
JDBC
Driver
T-n
JDBC
Driver
Rel. DBMS
Rel. DBMS
.......
Remote EMP
Databases
Local Database
Figure 8. The Distributed JDBC parallelizes queries to multiple JDBC drivers. T-ROOT: Supervisor of all connection threads. T-i: Thread controlling JDBC connection.
4.3.2. Retrieval of local and distributed data In order to query the Electronic
Market Place and retrieve product data located on the different EMP Market
Servers the Distributed JDBC has been realized which is available at each market server. The DJDBC driver behaves like regular JDBC driver. The usage of this
DJDBC is that of a JDBC driver as it implements the same API. The DJDBC driver
parallelizes the queries to the databases of the market. To access the databases the
DJDBC holds a JDBC connection to each of the databases. A query is sent in parallel to all market servers constituting EMP and the DJDBC driver waits for the
results. This is done by spawning a thread for each of the JDBC connections the
DJDBC holds. Each thread executes the same query on its connection (see Figure
8). This is possible as each EMP market server has the same product hierarchy
and consequently the same database schema for the organization of the data, as
explained before. As the DJDBC posts the query in parallel and waits for the query
results in parallel there is no delay caused by waiting for the result of one remote
22
market server before the next one can be queried. This imposes net load to the local
market server due to the many open network connections. A strategy to reduce this
load is to hold a connection to another DJDBC driver on another market server.
This DJDBC encapsulates again some of the JDBC drivers of market servers in the
system and by this some of the network load is distributed to this server.
On receipt of the query each market server’s local JDBC driver handles the request
on the local relational database and delivers the result (a JDBC ResultSet) to the
DJDBC driver that has initiated the query. The different result sets are collected
by this DJDBC driver on its local market server. The asynchronous reading of the
remote databases by the local market server makes it independent of slow network
connections. If a market server does not respond to a query in a reasonable amount
of time, a time out mechanism terminates waiting for a result from this server. The
result sets from the different JDBC drivers are collected in a result pool. This pool
of result sets is a buffer, e.g., a FIFO or any other type of buffer. As soon as the
first query result is returned to the market server initiating the query the user can
iterate over the result set until there are no more entries. As a consequence, the
overall query result can not be ordered or sorted by SQL statements like ordered
by within the final result set as only the query results of each of the single databases
are ordered. However, users get quick access to parts of the query result and do
not have to wait before all market servers have returned their result.
The query result set contains only those results from the market servers that were
available and answered to the query in a reasonable amount of time. Product data
on servers that are not available or connected over slow network may not be in the
result set even though, e.g., this would contain the cheapest offer currently on the
market. But at least loss of a network connection causes only temporarily loss of a
part of the available product data but not loss of the system functionality.
4.3.3. Update of local data All write actions are directed to the local database.
The create, insert, and update requests are also handled by the local DJDBC but
are simply handed over to the local JDBC driver for execution by the local DBMS.
4.4.
Binding Server
To allow the DJDBC to retrieve product data from all market servers in the system
an instance is needed that glues the universe of market servers together. We define
that this market universe consists of those market servers that are known by all
individual servers, that is the union of the currently known servers at each individual
market server (transitive closure). The instance that realizes the interconnection is
the electronic market place’s Binding Server (EBS). An EBS instance is located at
each individual market server.
At start up time of a market server the EBS is supplied with at least one address
of another market server. Then it starts to build up its individual set of known
market servers. Therefore, it queries the other server(s) known so far and asks
them for information about further market servers they know and adds the result
23
to its local set of known servers. From then on the EBS will periodically query the
known market servers about changes of the available market servers and adjusts
the local set of known servers correspondingly.
The EBS is used by the DJDBC to locate the other market servers in the system.
On a request of the DJDBC it returns the information about the known market
servers to address with a query and about the database connections for reading
from that market server. The EBS in combination with the DJDBC makes all
the product data in the currently reachable set of market servers for a user query
available. As each market server can operate independently the universe could
consist of only one market server.
4.5.
Interoperability
Since EMP manages its own data set on products and offers, it offers the possibilities
to connect legacy data repositories on client side in order to allow for the integration
of existing data maintained, e.g, by an existing merchandise planning and control
system. This can be realized by using the interface to the EMP system. In analogy
to importing data into EMP, the system also allows to export data for further
processing by other applications.
5.
Electronic Market Place - The Prototype
In this section, we present the prototypical implementation of the Electronic Market
Place following the architectural design as presented in Section 4.1. Each market
server site consists of a WWW server and a relational database management system
managing the local data. For the realization of a market server we have implemented
a core software component, a set of market services processing the client requests, a
Distributed JDBC (DJDBC) Driver, and a Binding Server (EBS). First, we describe
the functionality that has actually been realized in the prototype in Section 5.1.
The Sections 5.2 and 5.3 present some implementation details about the market
server, the core component of a market server, the market services, and market
clients. Database schema implementation and security mechanisms are presented
in Sections 5.4 and 5.5.
5.1.
Functionality of the EMP prototype
The functionality of the current EMP prototype can be summarized as follows:
•
Services. The current EMP version implements a selected set of those services
outlined in Section 3.2. For customer EMP realizes a buying market service.
This services makes use of generic business services for visualization of products, the product hierarchy, and offers. Additionally, we implemented search
functions that can exploit each invididual attribute of a product and/or an offer. Furthermore maintenance of search patterns/filters in a user profile, and
24
maintenance of user chosen product palettes in the profile is possible. For suppliers EMP realizes an offering market service and within that the placement of
offers, maintenance of offers, and maintenance of the supplier’s product palette.
The user profile maintenance module allows each user to specify some user specific parameters like the language and some other parameters for their local
environment.
•
Underlying database technology. The prototype is based on a relational database
system which stores user data, product description data, product offers, etc.
•
Distribution. The EMP prototype brings together a set of interconnected market servers. For the transparent distribution in the the DJDBC and the EBS
component have been implemented. The DJDBC driver collects the different
results in a priority controlled buffer. The EBS queries the other market servers
on a regular, adjustable basis with an algorithm based on a probe-echo algorithm.
•
Extensibility. The system has been developed to be able to integrate new services in the market place at runtime without shutting down EMP (Hot Plug &
Play). A service registers at a market server and from then on it is available in
the system. The EMP prototype provides a GUI based tool, the Product Class
Generator (PCG), which allows to easily introduce new product types into the
EMP. When creating a new product type an administrator has to identify the
node in the product type hierarchy and to specify the additional characteristic
attributes. The new product types can be inserted online into the system. For
changes to attributes of existing product types, however, the system must be
shut down.
•
Profiling. Registered users have associated user profiles which allows to maintain their personal look & feel of the user interface and the language to be used
for the user interface.
•
Security. Users and market services must authenticate at the Electronic Market
Place. A service authenticates with a certificate, users with a username/password
combination. In the authentication process both users and services get assigned
their respective privileges. The system implements a secure data communication protocol upon the Internet protocol. For access control to data database
security mechanisms are exploited. The core software and the authentication
services hold database connections with more privileges than the other services
of the market.
5.2.
Market server
To implement the core functionality of the market server a central core component
called Service Information Center (SIC) has been developed. A market service
consists of a lean client module and a back-end of the service, which is a Java
program running on the market server. Each service has to register at the SIC to
25
become one of the available market services in the system. The SIC administrates
all the EMP services and serves as a contact point for clients. It receives all requests
for invocation of services. To ensure a secure environment an authentication service
checks whether a user is allowed to perform an action or not. After it checked
whether a user is allowed to use this service it informs the client about the exact
address of the service module at the server.
At start-up time of a market service at an EMP server the service informs the SIC
about its name and location, which is then stored in the local database. According
to this information the SIC returns for each service invocation request from a client
the address of the matching market service module. Multiple clients can request
services at the same time as for each client a market service is executed in a different
thread. Figures 9 and 10 illustrate how the SIC of a market server operates.
Client/
Browser
1
Client/
Browser
...
Client/
Browser
4
3
Clients
Client
Internet
Internet
2
SIC
2
SIC
Server
some
Service
...
some
Service
Figure 9. SIC works like a naming service.
When a client wants to connect to some service (including authentication service) a request to the SIC is fired (1). The reply (2)
informs the client about the address of the requested service, to which the client then connects (3). Multiple clients can request services
at the same time (1,4).
1
Server
new
Service
...
some
Service
DB
Figure 10. If a new Service wants to become a
member of the EMP it sends a request-message
with information about it to the SIC (1). The
SIC registers the new services and stores all
associated data in a database (2). Requests for
this service are later processed based on this
data.
The SIC “pings” all registered services on a regular basis to check whether they
are up and running. If the ping times out, the SIC assumes that the service is down
and either starts the service again or just deletes the registry entry in the database,
depending on the service profile. Additionally, using the SIC allows to remove, and
modify services and/or their location during runtime.
Furthermore, it is possible to replicate the same service on different machines.
This allows for specific access methods like alternately sending requests of a client
to server A and B, i.e., distribute a service on multiple servers. This approach
allows to dispatch requests to different servers with the same functionality for load
balancing. Obviously, it would be more efficient to dispatch requests depending on
the actual free capacity of an EMP server. This approach allows load balancing
as well as flexible reaction to problems at a specific site. However, this approach
requires to use trusted (as defined in the Java context) applets.
26
5.3.
EMP clients
The core component at the client side is the service-selection applet. Its visible
interface to the user is a navigation bar which resides all the time the EMP is
active at the top of the browser window (see Figure11). It enables the user to
easily choose services offered by the market. At start up it is invoked by the applet
tag included in the HTML-Start-Page of the EMP. At the beginning of an EMP
session the user is prompted for a username/password combination. This is sent
to the EMP Server for verification. The client receives a ticket from the server
which makes it possible to authenticate the user in all follow-up requests, until the
navigation bar is disposed (e.g., the browser is closed or another WWW page is
loaded). More details on tickets are given in Section 5.5.
Figure 11. EMP front end with running buying applet. The foreground shows a buying service
running in the English language environment, the background shows the same service running in
the German language environment.
27
After a user logged in, the market’s home page is automatically loaded. It consists
of two HTML frames. In the top frame the service-selection applet presents the
navigation bar which allows to select the offered market services. The lower frame
of the page is reserved for the applets which are the front ends to the market service
currently selected.
Each market service consists of a lean client module which handles user I/O and
realizes the GUI and a server module which processes the client requests. All service
front ends are HTML pages which include Java applets which are presenting the
market place’s GUI. These are stored on the EMP WWW server and downloaded on
demand. The client applet communicates with the back-end of the service, which is
a Java program running on the market server. Communication between the client
and server modules is realized using secure data streams based on sockets.
Figure 11 shows the navigation bar and the running buying service. This service
consists, like all services dealing with products, of a visualization of a product
hierarchy at the left side and a service specific part at the right side. We have
chosen a tree representation for the product hierarchy. Usually, a user selects one
or more leaves or nodes of the tree. It is also possible to choose a previously
(named) stored selection of nodes via the choice list above the tree. The buying
service represents each selected leaf with a tab at the right side. This makes it
easy to view different products at once. Each tab corresponds to a product type
and provides a filter mechanism prior to downloading the full product description.
The mechanism provides a way to filter products by attributes using minimum,
maximum, and ranges for integer attributes, currencies, and dates, patterns for
strings, and multiple selections from choice lists. This limits the number of hits for
a request with a view to greater clarity. In addition, this makes it more efficient
especially for users with low-bandwidth-connection to the Internet. After a user
found one or more products which he selected in the corresponding tab, he may
press the buy button. The client prompts for a confirmation dialog and displays the
selected product list and the total bill.
For experimental purposes we plugged in a simple financing and logistic service.
Of course, we are not able to provide a fully fledged financing or logistic service.
Therefore, these services emulate these providers simply by assuming one fixed
financing rate and one common price per good, not taking care about the differences
like goods which need to be transported frozen. These services enable a user to get
logistical and financial assistance for each product he wants to buy.
5.4.
EMP market data - management and access
All data like user data, product description data, product offers as well as system
data of a market server is stored in a relational database system. The implementation does not depend on a specific database system as long as it offers a JDBC
driver and implements the SQL92 standard. The current prototype uses the Oracle
relational database system version 7.3, but has also been used on Microsoft Access
97 and Yard. Database access is realized via an implementation of the DJDBC
which allows to connect to the JDBC drivers of the databases of the EMP.
28
5.4.1. Product data As indicated earlier, we organized the product data with
hierarchy of product types. In the database schema product types are realized with
a set of relational tables as described in Section 4.2. We have built up a product
hierarchy for the application domain of the RMP project. It has been based on
the product classification scheme of the Austrian statistical federal office. For an
illustration of part of the product types of the test scenario see the presentation
of the product hierarchy in the buying service in Figure 11. A product catalog
relation represents the product hierarchy itself.
At the client side the product types are modeled as inheritance tree of java classes,
products are instances of these classes.
The Product Class Generator (PCG) which provides a GUI for simple maintenance of the product type hierarchy. This tool allows to create new and change
existing product types with all the associated attributes in the product type hierarchy (see Figure 12). The PCG automatically generates all Java code needed to
process the visualization of data in the system and creates the necessary tables and
makes the necessary database entries. The PCG also allows for integration of new
product types at runtime, e.g., adding a new product type French red wine.
Figure 12. The Product Class Generator
29
5.4.2. Profiles There are two distinct types of profiles characterizing a user: The
first type is the personal profile with which the user makes general decisions such as
colors, user interface language, or button style to be used. The second profile type
is called service profile which allows to specify service-specific features. Therefore,
a service decides which service parameters are adjustable via a service profile. In
the special case of the offer and buying service, the user is able to define and store
search filters for goods he is interested in. Additionally, the buying service allows
to store user generated filters on product selections, e.g., show all products less
expensive than 100 Euro.
Each profile is realized as a set of <attribute, value> pairs. This allows to
extend the set of values a user can tailor to his personal needs. There is one table
storing the personal profile of the market users at each market server. Additionally
for each of the service running at the market server a table stores the service-specific
user profile with the respective set of <attribute, value> pairs.
5.5.
EMP market security
EMP uses well established and proven security mechanisms. Throughout the communication EMP uses a Secure Socket Layer (SSL) as the communication basis.
Authentication, the most important initial security feature is described in more
detail in the following.
Each client which wants to connect to an EMP market server first has to connect
to the market’s SIC. From there a client gets the information needed to connect to
the Authentication Service. Then the client authenticates using a slightly modified
Kerberos protocol. The lack of global time made the slight change necessary. The
protocol guarantees a secure authentication. At the end of the authentification
the client receives a personal ticket. This EMP ticket is similar to the Kerberos
ticket, but in our special case a ticket has no global time and is not persistent at
the client side. The ticket is hold within the Java Virtual Machine and is valid for
some maximum period of time (currently set to 12 hours) or until the user logs out
from EMP. All further EMP client requests are accompanied by the ticket. So all
services are able to check if a user is allowed to use the service. After a service has
verified the ticket, a secure stream is established between the server and the client.
This secure stream is based on DES encryption and MD5 signature.
Access of services to data and core functionality is controlled by basic services
which are using access control lists (ACL). Both services and users have associated
privileges. These privileges are exploited to manage the access to the data at a very
fine granularity.
The implementation of the prototype’s security system including techniques like
the RSA and the Digital Encryption Standard (DES) encryption prevents all standard intruder attacks like eavesdropping, masquerading, tampering, or replay.
30
6.
Conclusion and further work
In this paper we have presented a new approach toward an open and flexible system
realizing an electronic market place on the Internet, which brings together companies, i.e., suppliers with customers, in an n:m business relationship. We aimed
at a solution for business-to-business electronic commerce feasible for small and
medium-sized companies which can not afford to participate in a typical EDI-based
environment. The functionality of the market place is organized in terms of a modular set of market services like buying and offering which are provided online for
the participants of the electronic market place.
The services are built up in terms of layers which provides for a well-structured
composition of services and which allows for scalability and extensibility of the
market.
The implementation of the market is based on existing Internet/WWW infrastructure. Database technology plays a central role in the overall architecture as
all trading data and system control data are stored and managed by a database
system. Access to the various databases assigned to each market server is realized
by the distributed JDBC driver (DJDBC) which allows to read data from local and
various remote databases and to update data in local databases assigned to the
home market server of a user only.
The data model is highly flexible and generic which allows to support any kind
of product type hierarchy and dynamic schema evolution during runtime of the
system.
The system can be applied in any thinkable application domain in which a market
can consist of one solitary supplier but also a community of many suppliers. The
system can easily be adapted to specific application needs by means of changing or
introducing individual market services.
Our approach has been taken to realize the commercially operated Rural Market
Place (RMP) [2] which is currently released to small and medium-sized companies
participating in the pilot project3 Another application currently built on EMP is
the regional electronic event market place of the City of Ulm which allows us to
explore the evolution of the market services for usage by private consumers, which
significantly impacts the end-user interface and the instantiation and combination
of market services.
Our current work focuses on the distribution of the market services needed to
allow for the operation of a network of EMP servers in the Internet. Furthermore,
we work on the exploitation of CORBA/IIOP technology in this framework. We
did not make use of CORBA so far because the integration of Java technology with
CORBA technology was not yet developed and stable during the implementation
phase of our system. The functionality of the SIC component is heavily based on
the usage of databases which is more complicated to realize with CORBA.
Future work will include the incorporation of payment schemes in cooperation
with a bank which participates in the RMP pilot project. Furthermore, evaluation of the RMP pilot will provide useful feedback for the realization of two other
applications already planned on the basis of the EMP approach.
31
Notes
1. RMP is partially funded by the European Union under article 10 of the EFRE development
program RISI2. The many partners come from Austria, France, Greece, and Spain; coordinating partner is telesis, Austria. Details are available under URL www.rmp.at.
2. The organizational authority may be a dedicated office to be contacted or may be part of the
software system in terms of automatic processing. This depends on the individual application
of the system.
3. The current system can be tested on request under URL http://www.rmp.at/market.
References
1. Amazon.com Inc. Amazon.com Bookstore, 1998. URL http://www.amazon.com.
2. Susanne Boll, Wolfgang Klas, and Bernard Battaglin. Design and Implementation of RMP
- A Virtual Electronic Market Place. ACM SIGMOD RECORD, 27(4), Dec 1998.
Altavista search engine,
1998.
URL
3. Digital Equipment Corporation.
http://www.altavista.com.
4. Electronic Commerce on the Internet, volume 9 of EDI Forum: The Journal of Electronic
Commerce. The EDI Group.
5. EMB GmbH. Electronic Mall Bodensee, 1998. URL http://www.emb.net.
6. Project No. RE1005 European Research Project partially funded by the European Comission in the “Telematics Applications” Programme. ICE-TEL — Interworking Public Key
Certification Infrastructure for Europe. 1998. URL http://www.darmstadt.gmd.de/ice-tel.
7. European Research Project funded by the European Commission Project “Advanced Computing and Telecommunication Systems” (ACTS), Project No. AC026 . Secure Electronic
Marketplace for Europe, 1998. URL http://www.semper.org.
8. European Research Project funded by the European Commission, Project “Advanced Computing and Telecommunication Systems” (ACTS), Project No. AC211 . Open Service Model,
1998. URL http://osm-www.informatik.uni-hamburg.de/osm-www/index.html.
9. IBM Coporation. Commercepoint, 1998. URL http://www.internet.ibm.com/commercepoint.
10. IBM
Coporation.
CommercePOINT
Payment,
1998.
URL
http://www.internet.ibm.com/commercepoint/payment.
11. Information Networking Institute. NetBill. 1998. URL http://www.ini.cmu.edu/netbill.
12. Intershop Communications, Inc. Intershop 3, 1998. URL http://www.intershop.com.
13. JF-Lehmanns Berlin. Lehmanns Online Bookstore (LOB), 1998. URL http://www.lob.de.
14. Junglee. Junglee Virtual Database, 1998. URL http://www.junglee.com.
15. Karstadt AG. my-world, 1998. URL http://www.my-world.de.
16. Microsoft Coporation. Internet Commerce, 1998. URL http://www.microsoft.com.
17. Oracle Coporation.
Oracle Internet Commerce Server,
1998.
URL
http://www.oracle.com/products/asd/ics/ics.html.
18. ShopHotBot. Electronic Mall, 1998. URL http://shop.hotbot.com.
19. SNAP. Electronic Mall, 1998. URL http://www.snap.com.
20. M. Sirbu and J. D. Tygar. NetBill: An Internet Commerce System Optimized for Network
Delivered Services. IEEE Personal Communications, August 1995.
21. Sun Microsystems.
Java Electronic Commerce Framework (JECF), 1998.
URL
http://www.javasoft.com/products/commerce.
22. Jay M. Tenenbaum, Tripatinder S. Chowdhry, Kevin Hughes, and Andre Schiper. Eco
System: An Internet Commerce Architecture. IEEE Computer, 30(5):48–53, May 1997.
23. Worldwide Internet Solutions Network, Inc. WizNet, 1998. URL http://www.wiznet.net.
24. Yahoo! Corporation . Yahoo! search engine, 1998. URL http://www.yahoo.com.
25. Hans-Dieter Zimmermann. The Model of Regional Electronic Marketplaces - The Example of
the Electronic Mall Bodensee (EMB) . Telematics and Informatics — International Journal
on Telecommunications & Information Technology, 14(2):117–130, 1997.
32
Contributing Authors
Wolfgang Klas is currently Professor at the Computer Science Department of the University of Ulm, Germany. Until 1996 he was head
of the Distributed Multimedia Systems Research Division (DIMSYS)
at GMD-IPSI, Darmstadt, Germany, and directed many research
projects and industrial collaborations in the fields of object-oriented
database technology, multimedia information systems, interoperable
database systems, and cooperative systems. In 1991/1992 Dr. Klas
was a visiting fellow at the International Computer Science Institute
(ICSI) at the University of California at Berkeley. His research interests are currently in multimedia information systems and Internetbased applications of database systems. Dr. Klas serves currently on
the editorial board of the VLDB Journal and he has been a member
and chair of program committees of many conferences.
Susanne Boll is a member of the scientific staff in the Database
and Information Systems (DBIS) department at the University of
Ulm, Germany. Her research interest lies in the area of multimedia
database systems and she works on the integration of flexible presentation services into multimedia database technology. In 1996 she
began her Ph.D. at the Integrated Publication and Information Systems Institute (IPSI) of the German National Research Center for
Computer Science (GMD), which she is now continuing at the University of Ulm as a doctoral student of Wolfgang Klas. She obtained
her diploma degree in computer science at the Technical University
of Darmstadt, Germany, in 1996.
Andreas Grüner is a graduate student in the department of Database and Information Systems (DBIS) at the University of Ulm,
Germany. Since 1994 he’s working as a research assistant on several projects including a Java-based database layer for a workflow
system and databases and distributed systems. From 1995 to 1996
he studied at the University of Connecticut (USA) where he mostly
worked on network and distributed system topics. During his stay he
also gave lectures for undergraduate students in the field of engeneering. His main research interests are database technology, workflow
managment, distributed systems, and Java.
Armin Haaf is a graduate student in the department of Database
and Information Systems (DBIS) at the University of Ulm, Germany.
Since 1993 he’s working as a research assistant for the department
as system administrator (Unix, Lotus Notes, Oracle, Informix) and
supported several department projects especially in the workflow
managment field. He’s currently preparing his master thesis in the
databases and distributed systems area. Among his research interests are database technology, Internet security, distributed systems,
and Java.

EMP — A Database-Driven Electronic Market Place for Business

Transcrição

Documentos relacionados

Department of Commerce and Consumer Affairs

Commerce Resources: making sense of rare earth elements

Goultarminator II – the rules Qualifying Round

Total tv cardsharing

75ms - CloudConf

WEIVES WEIVESDOWNLOAD THUYET MINH TRUYEN MA

santander data center, campinas, brazil

Using SQL from Programs SQL and Programming Languages SQL

State of Mobile Commerce.

REGISTRATION OF FOREIGN STUDENTS ON FEDERAL POLICE

REGISTRATION OF FOREIGN STUDENTS ON FEDERAL POLICE