E-negotiations | People | About |  Projects | Announcements | Resources

E-negotiations > Projects

 

Project 4:   Computer Aided Market Engineering & Design Patterns Library

Team

Coordinators:  

M. Bichler, Technical University of Munich, C. Weinhardt, University of Karlsruhe

     
Key researchers:  

M. Benyoucef, G. Kersten, University of Ottawa, M. Stroebel, BMW; R. Vahidov, Concordia University

Summary

This project has two main components:

  1. Computer aided market engineering, and
  2. Pattern library for decentralized coordination & negotiation protocols.

1. Computer aided market engineering (CAME) (revised Sept. 1, 2003)

Electronic markets are not just evolving, but they have to be carefully engineered. In electronic markets, not only the trading rules but also the system design (IT infrastructure), the fee structure, as well as the product being traded has a deep impact on the overall market performance. Even small failures in design decide on the overall success or failure of a marketplace. Trading rules, information technology and the fee structure are the result of distinct processes, namely the market microstructure design, system design and business design, respectively. An interdisciplinary analysis of those interdependent processes is missing and state-of-the-art theory fails to answer the questions, what exactly these design issues in electronic market engineering are, and which concepts and tools are necessary to guide the market engineer to high quality market performance.

For practical reasons the concept of Computer Aided Market Engineering (CAME) gave rise to the implementation of the e-FIT system (Electronic Financial Trading) that embodies the concept of CAME (see Figure 1). Basically, the core of the system is a market server that is as generic as possible in a way that it supports the automated construction of electronic negotiation protocols. The construction is thereby based on the conceptual foundation of the Montreal Taxonomy. In its current release the core provides the negotiation process; but offers no normative insights how the construction should be done. Having in mind, the difficulties in market design the pure market server cannot assure sustained success.

This project aims at creating a market engineering process and associated computer-aided tools to successfully guide market engineers in their design tasks. A necessary step towards a normative design is thus the development of a library that collects the scattered information about (electronic) negotiation protocols and makes it accessible for a market engineer in form of design patterns. The component pattern library is represented as one of the hulls around the core in Figure 1. However, with the pattern library the tool suite is not yet completed, as the patterns show the communication flow but not when preferably to use them. A decision support system should accordingly support the market engineer in selecting the appropriate pattern. Another hull of the architecture represents both, an experimental evaluation shell and an agent based simulation environment, which is intended to evaluate the patterns by means of laboratory experiments and simulations.


Figure 1: Overview of the CAME architecture

The gist about CAME is that its components are not bound to the e-FIT system, but can be used in all market engineering problems. For example the pattern library is independent of the system but can be coupled if necessary. It is, however, convenient to demonstrate the power of the CAME tool set in market engineering.

2. Pattern library for decentralized coordination & negotiation protocols

The online pattern library will contain an online glossary and a collection of frequently used design patterns for the solution of decentralized coordination / negotiation problems. This should enable researchers and practitioners to communicate effectively about particular protocols. The patterns are written from the point of view of a systems engineer, but draw on the results of other disciplines such as social choice theory, mechanism design theory or group decision and negotiation theory.

The project will deploy a generic schema for the description of negotiation protocol patterns and provide a first collection of patterns on the web. Project partners can provide new patterns, which can then be easily added to the pattern library. A search facility should be provided as well. The site can be linked with the e-negotiation project site.
A design pattern describes a proposed solution of a permanent recurring software design problem. Design patterns have become a wide-spread means to transfer knowledge about successful designs. They are more or less formalized descriptions of solutions to certain problem classes, and are well suited to establish a body of knowledge for a particular application domain. Currently, "negotiation" covers a huge, unstructured domain of coordination problems. A pattern language of negotiation protocols could establish a language to communicate about successful protocol designs.

A negotiation protocol design pattern contains:

  1. Intent: Describes the underlying coordination problem and the basic principle of the design solution. Also known as: Other names of the pattern, if existing.
  2. Motivation: Depicts a scenario of a concrete design problem and gives a solution.
  3. Applicability: Itemizes the situations or conditions, in which the pattern can be applied, including:
    • Participants characteristics
    • Resources
    • Other environmental factors
  4. Structure: Describes the interaction of the participants, which are participating.
    • Protocol rules: interaction rules and allowed negotiation/bidding language
    • Allocation rules (if existing)
    • Payment rules (if existing)
  5. Participants: Lists the classes and objects, which are described by the design pattern.
  6. Collaborations: Describes the interactions between the objects to fulfill the task of the software.
  7. Consequences: Discusses the advantages and disadvantages of the pattern, and makes suggestions about variations.
    • Solution goals (e.g. efficiency, fairness, speed of convergence)
    • Computational properties
  8. Implementation: Gives some implementation details, which may be language-dependent.
  9. Variants: brief description of variants, extensions or specializations of the design pattern.
  10. Sample code: A sample code, if necessary.
  11. Known uses: Examples of applications, in which the design pattern is used.
  12. Related patterns: Lists patterns, which describe a similar task, and shows the relations to other patterns.

Reports

Computer Aided Market Engineering progress report, Sept. 26, 2003.


 


February 8, 2004