A Framework for Composing Electronic Marketplaces – From Market Structure to Service Implementation

(1)

A Framework for Composing Electronic Marketplaces – From Market Structure to Service Implementation

Daniel Rolli, Stefan Luckner, Christof Momm, Christof Weinhardt University of Karlsruhe, Information Management and Systems,

Englerstr. 14, 76131 Karlsruhe, Germany {rolli, luckner, momm, weinhardt}@iw.uni-karlsruhe.de

Abstract

In coordination theory, markets stand for flexibility and dynamics. Today’s implementations of electronic marketplaces, however, limit the flexibility in a sense that processes along the market transaction are rigid and the provided functions proprietary. In order to further foster flexibility in market coordination, we propose breaking down marketplaces into services. These services can then be composed to custom- ized market processes that trace proven company-internal business processes instead of prescribing a least common denominator for all marketplace participants. This turns a marketplace operator into a service-broker who provides merely the very fundamental infrastructure. All other functions can be deliv- ered by independent specialized providers and flexibly assembled to processes. The marketplace opera- tor’s main contribution is then to guarantee reliability and quality of service levels for the providers’

products. Our paper presents a framework that enables the configuration and implementation of a ser- vice-based electronic marketplace. Step by step high-level market processes are decomposed into man- ageable and autonomously implementable components. As a proof-of-concept we built a prototype using BPEL4WS and Web Service technology.

Keywords: Electronic Marketplaces, Service-Oriented Architecture, Business Process Management, Web Services, Auction Reference Model

1. Introduction

Electronic marketplaces have fundamentally shaken up supply chains in the last couple of years. The advantages of electronic market coordination, like the reduction of transaction costs, a wider range of potential suppliers and an increase in the level of transparency have sufficiently been motivated and praised [3].

The downside of lacking support for individual processes within different companies is also a well-known problem [5, 9]. After many small revolutions and experiments in the way companies connect along the supply chain, there is still no prevailing overall solution that manages the tightrope walk between the effi- ciency of electronic marketplaces on the one hand and the sustained quality and smooth processing that grown relationships promote on the other hand.

Nonetheless, the trend towards electronic marketplaces is unfractured and will be strengthened by a further shift towards virtual enterprises, where small units focus on their delimited core competence and are linked in flexible supply networks. Electronic marketplaces are the instrument of choice in tackling the increasing need for coordination in that scenario.

One way to develop the appropriate means for better market coordination is a stronger emphasis on the services idea, process orientation and reusability. Well-known platforms like Covisint¹ and SupplyOn² nowadays do not explicitly support the concept of business processes. They rather prescribe an inflexible sequence of steps for completing a procurement or sales process. Companies however want to make sure that all of their employees involved in a series of steps work off a predefined business process. This proc-

1 http://www.covisint.com

2 http://www.supplyon.com

(2)

ess should be capable of following the company’s individual needs like specifics in the organizational structure and the integration of additional process steps.

As the proprietary implementation of electronic marketplaces by a single provider turns out to be inappro- priate to master these challenges, we employ the business process idea to systematically break the functions in the process down to elements that can be easily interchanged. Then, an electronic marketplace participant is not restricted to the functionality offered by the monolithic operator, but can substitute functions by the solutions of alternative providers. The independent provision of more than one market mechanism that is often hard-coded to a great extend within a marketplace is just one approach for unleashing the potential advantages.

We propose the application of the service-oriented architecture to electronic marketplaces, which supports the ideas mentioned above. Our main contribution is a framework for marketplace composition, the identi- fication and classification of services constituting marketplaces and how the services are best structured internally to realize the potential of service-orientation. We will focus on the theoretical discussion of the market mechanisms as the core of every marketplace and present a prototype implementation.

The paper is structured as follows: In section 2, we briefly review related work. Section 3 relates the service-oriented architecture to electronic markets. In section 4 we will present our marketplace framework in detail. Having depicted the implementation of the framework with BPEL and Web Services technology in section 5, we will conclude this paper with a summary and a brief outlook to future work.

2. Related Work

Kim and Segev present a Web Service-enabled marketplace architecture for negotiation process management [5]. They observe that most of the processes supported by marketplaces cannot easily be changed and propose BPEL4WS for making the processes more flexible. They focus their deliberations on “complex negotiation processes” [4, 5] and draw on the classification scheme from [6] to describe an example.

This scheme is also applied in [5] to derive a component-based negotiation process composition tool. With the scheme in mind, the tool should be applicable to negotiation processes in a narrow sense, namely those that do not allow an automatic result determination. Yet, for the detailed description of auctions, let alone their implementation, it is not sufficient, because it lacks a way for describing essential aspects like rules for price and winner determination as well as the information revelation.

So, when integrating the implementation of auctions we have to make use of a more comprehensive description methodology capable of vanquishing the abovementioned shortcomings. Parameterization ap- proaches [13, 14] are suitable for the specification of auctions while Stroebel and Weinhardt [13] even comprise the wider scope of trade negotiations. However, parameterization remains on a conceptual level and is not immediately suitable for our purposes of detailed description, componentization and implementation. Therefore, we apply an alternative approach for the specification of market mechanisms that has a strong focus on auctions, namely the Auction Reference Model [9].

3. Service-Orientation and Markets

Information systems of the future will be combinations of loosely-coupled services rather than appearing as monolithic pieces of software. The underlying paradigm is the service-oriented architecture (SOA). In SOA [1, 11], service providers publish their services in a registry. Service requestors can search the registry for suitable services and utilize them. The service-oriented architecture aims at dynamic discovery and usage of services at run-time.

The advantages of the SOA are manifold. First of all, up-to-date software applications are getting more and more complex. This complexity can only be achieved by combining highly specialized software components. Their provision as services promotes distributed and autonomous development as well as operation of components. The services can then be integrated into different applications as “black boxes”. Only this separation of concern allows for the complexity of today’s software.

In order to achieve our goal of flexible markets, we suggest a marketplace framework based on the service idea. The SOA enables both, the easy integration of the market processes into a company’s application

(3)

landscape and of market services into the market processes. In contrast to proprietary markets, this enables the reuse of services that implement general functionality suitable for various marketplace scenarios.

Secondly, the individual configuration of services allows for customized processes that meet the varying requirements of different companies. This will break up the rigid corset known from monolithic marketplaces. Not the enterprise has to adjust its business processes to the existing software, but the software can be adapted to facilitate established business processes that have proven their competitive advantage. By using our framework, companies can rapidly build and deploy their custom business processes. We will further exemplify how market services themselves can be decomposed into services on a lower level to foster a large variety of different implementations.

A market operator in our system has a role that is very different from an operator in a proprietary market.

In our service-oriented setting, he only provides a registry for services that can be integrated into the business processes of a company. Being the entry point for market configuration – an intermediary between service providers and requestors – and ensuring the trustworthiness of services are the main benefits the operator contributes to the system. Access to the registry is offered as a subscription-based service.

4. A Marketplace Framework

Our framework for building marketplace processes is based on a layer architecture. According to the following Figure 1, the market processes on the top layer are composed of service operations from the second layer. Each market service represents a function of a marketplace and consists of components that are specific for each service. These

specific components then in- voke basic services. Figure 1 depicts the layer structure and fills the layers with the examples that we will explain in the following subsections. At the Market Processes Layer, the major functions of processes are typically the initiation of a market mechanism as well as buying and selling. The steps of the processes are operations provided by the layer below.

On the Market Services Layer, these operations are tied to-

gether within services. The services are not restricted to the use within a certain process, but can rather be accessed by market initiation, buying, selling or general processes. Every service is made up of components.

The Service-Specific Components Layer contains the components that are specific for each service and can typically not be reused by any other service.

The Basic Services Layer provides services that are invoked by the components of the layer above. They are of general nature and not specific to the different components.

The following subsections will explain the elements of each layer in detail and give examples.

4.1 Market Processes

As illustrated in section 3, supporting company-specific business processes is crucial for the success of electronic marketplaces. For that reason we provide the Market Processes Layer where companies can either make use of predefined business processes “as is”, customize them according to their specific needs or build individual processes from scratch that incorporate the operations provided by the market services.

Market Processes

Shipping Market Mechanism

Transition …

Procurement

Timer

MathSolver

Market Services

Service-Specific Components

Basic Services

… Reputation Mechanism

AgreementG.

Validation

View

Figure 1: Layer Architecture

(4)

There are two types of processes on marketplaces. The market processes are those that involve the initiation of a market mechanism, buying or selling. The second type comprises general processes of electronic platforms, like a registration process, login and logout. What we call marketplace processes is the combi- nation of market and general processes. We give one example for a market process in

Figure 2, namely the procurement process.

Receive Material Requirements

Choose Market Mechanism

Fine Tune Auction Parameters

Specification

of Buy Offer Auction

Initiation

Answer Supplier Request

Get Buyer View Receive

Agreement Store

Agreement Receive

Bill Specify new

Product

Choose

Existing Product Send Buy

Offer

Pay Bill Wait for

Receipt of Goods Rate

Business Partner

Choose Suppliers XOR

AND Receive available

Market Mechanisms

Register Auction Instance

Figure 2: Procurement Process

One major benefit of this process is that the purchasing agent can choose and fine-tune the market mechanism most suitable for his needs. Once the agent submits a buy offer the new auction is registered at the Market Mechanism Instance Registry. There it can be found by potential suppliers. While the auction is running the purchasing agent can monitor the auction process. After an agreement has been generated, the settlement phase takes place.

4.2 Market Services

On the Market Services layer, services represent the different functions of a market. They provide operations that are invoked by the Market Processes Layer. We distinguish between two basic types of services:

platform services and market services.

The platform services constitute the infrastructure of the marketplace and are provided by the marketplace operator. Besides general platform services like login, logout, registration etc, there are two services for managing the different types of market mechanisms and their instances: The Market Mechanism Service Registry lists all market mechanisms that can be chosen by an initiator whereas the Market Mechanism Instance Registry lists all running market mechanism instances accessible for a requestor.

The second type of services, the market services, is offered by specialized providers. In the remainder of this paper we will focus on these market services. They can be categorized according to the shell model in Figure 3.

The core of the shell model in Figure 3 represents the essential service that links all participants of one market transaction. This core service provides the market mechanism that is constituent for every market process [cp. 6]. The shell around the core comprises optional services that also connect all participants involved in one transaction. If the initiating participant employs such a service, it affects all other participants involved in the same market transaction. Examples for such services are billing - where the bill is transferred from the sender to the receiver - , payment - where the money is transferred - and shipping for the transfer of goods.

The outer shell of Figure 3 contains all market services that are individual for the participants. A participant can use any of these services without affecting his transaction partners. All of the services in the outer shell are also part of the market in the sense that their input, output or subject of interest is directly connected to the marketplace. The reputation management, for instance, provides

Reputation Mechanism

Payment Billing

Shipping

Contact Management Sales

Force …

… Market Mechanism

Figure 3: Services Shell Model

(5)

information about potential transaction partners and thereby supports their selection.

Examples for services that can be added to a market process but are not actual market services in any of the shells of Figure 3 are currency converters, weather forecasts etc.

In order to exemplify how a market service itself is structured, we elaborate on the core market service, the market mechanism. As electronic auctions have gained significant importance in the field of e- procurement [12], we apply the Auction Reference Model [9] to model a reverse English auction. The Auction Reference Model (ARM) allows for a cohesive description of an auction mechanism that forms the framework for implementation. As the ARM is applicable to different auction types it addresses a wide range of market mechanisms that can be applied as market core services. Its simple uniform communication protocol that applies to all auctions addressed enables the easy interchange of auction types in market processes.

The foundation of the ARM in Figure 4 is the data basis. It contains the market instance data that is made up of intentions, agreements and stage information. Assuming that an auction is – like a market in general – “the impartial structured condensation of participants’ intentions into exchange agreements”

[10], then “an intention represents the smallest closed entity of purpose within a market” [10] and therefore also in auctions. “An agreement comprises two intentions that concur with each other and indicates that the involved participants have

committed themselves to exchanging the products of the respective intentions.” [9] The structure for both intentions and agreements is explained in detail in the two papers [9, 10]. The results of the deliberations there are used to accordingly implement the data structure for intentions and agreements in section 5.2.

Building on this data basis are the four main components of an auction: view, validation, transition, and agreement generator. Instances of these are gathered in stages. The auction flow coordinates the set of stages in sequences or loops. Thereby, the number of stages is individual for every auction. For the reverse English auction we identify three different stages. Stage 1 receives the intention of the buyer who also initiates the procurement auction in our scenario. Stage 2 collects the bids submitted by the competing buyers and stage 3 generates an agreement that contains the auction winner and the price to be paid.

Any number of views greater or equal zero can belong to a stage. Views are active throughout the com- plete duration of the stage they belong to. The views take all market instance data as input and deliver the result of specific operations on this data to certain roles of participants. The bidding sellers of our reverse English auction, for example, see the current lowest bid amount in the view leadingOfferPrice.

Internal views, namely those that are assigned to the auctioneer, are also the basis for validations, transitions, and agreement generators, which will be explained in the following as the respective components are described. These internal views are, however, not visible on the stage level.

There is always one validation component in every stage. This component is active throughout the entire duration of a stage and checks every intention that it receives for syntactical and semantic correctness.

Only valid intentions are passed on to the data basis for storage. In the second stage of a reverse English auction the validation checks, for example, if an incoming intention contains a bidding price that is lower than the current leading price.

There is exactly one transition in every stage that ends it according to a certain condition. This condition is either based on a change in the view that is assigned to the transition and/or a timeout event. The transi-

Auction Mechansim

Auction Data Auction Participants

agreement generator

data basis

intention intention

transition view

validation

auction flow active stage

participant of type 1 (buyer) participants of type 2 (suppliers)

Figure 4: Auction Reference Model Overview

(6)

tion is closely connected to the auction flow. As a transition ends a stage, the flow either starts the next stage or the auction ends.

Zero or more agreement generators belong to one stage. They use the results of their assigned views to fill them into an agreement data structure and store it in the data basis. An agreement always contains the result of the winner and price determination.

These four components are the ones specific for those market mechanism services implementing auctions.

The embodiments of views, validation components, transitions and agreement generators will be explained in the following sub section 4.3.

4.3 Service-Specific Components

As mentioned at the beginning of section 4, the components of this layer are specific for each market service. This enables reusing predefined service-specific components from a repository when designing a market service. In Table 1 we describe the four auction-specific components for our example of a reverse English auction.

Validation AgreementGeneration Transition View

Stage

Auctioneer InitParticipant

(Buyer) Participant

(Seller) Participant (Winner) 1

outgoingProduct = ”money” with attributes “minAmount” >= 0 and

“maxAmount” >= “minAmount”

incomingProduct specified participant specified offer submitted within stage 1

On change of openingOffer

validOfferStage1 openingOffer

2

incomingProduct = “money” with attribute “amount” > reserve price (seller) and “amount“ > max

“amount” in previously submitted offers

incomingProduct = outgoingPro- duct specified in opening sell offer participant specified

participant is not seller offer submitted within stage 2

Timeout Timer reset on change of leadingOffer

validOfferStage2 leadingOffer

leadingOffer openingOffer leadingOfferPrice

3

Agreement =

{Intentions1 :=

openingOffer.intention, Intention2 :=

winningOffer.intention, Timestamp}

For Intention1 the price is concretized to the winner’s bid

Timeout winningOffer openingOffer

agreement openingOffer winningOfferPrice

agreement

Table 1: Auction-Specific Components

According to Table 1, four roles are provided with different views in every stage. As the auctioneer is con- ceptually responsible for all internal operations of an auction, the views needed for validation, agreement generation and transition are assigned to him and will be explained in the context of the respective components. In stage 1, the roles of the buyer, seller and winner receive an empty view. In stage 2, the buyer sees the current leading offer. The seller, on the other hand, is provided with the lowest bid. Additionally, he sees the buyer’s opening offer in order to gather information about the desired item. The opening offer represents the first valid buy offer submitted within the scope of stage 1 whereas the leading offer is determined by retrieving the sell offer with the lowest specified amount of money. The seller’s view only returns this amount of money. In stage 3, the buyer and the winning seller are informed about the reached agreement. Other bidders only see the seller’s opening offer and the winning price.

The validation component checks each offer sent to the auction. If the offer is valid, it is stored in the data basis, otherwise discarded. The validity criteria for offers are stage dependent and described in Table 1.

The transition component determines the end of a stage. Therefore it monitors an auctioneer’s view and/or listens to a timeout signal triggered by a basic timer service. In stage 1, the transition draws on the auc-

(7)

tioneer’s view providing the opening offer. Once this view changes – from empty to the first offer – the transition immediately finishes the first stage. In stage 2, the transition sets a timer component to a certain timeout and starts it. Thereafter it waits for its associated view on the current leading offer to change. A change of this view induces the transition to reset the timer. When the timeout is triggered, stage 2 ends.

In stage 3, the transition sets a timeout again. When the timeout is triggered, stage 3 and the auction ter- minate.

The agreement generator is executed at the beginning of stage 3. Two auctioneers’ views are therefore required - on the winner’s offer and on the opening offer. The intention of the winner’s offer is extracted and inserted into an agreement template as intention2. The buyer’s intention, retrieved from the opening offer, becomes intention1 after the auctioneer has concretized the specified price range to the determined price of the auction. This means that the attribute “amount” of the incoming product “money” within the winning seller’s intention is appended to the attribute “amount” of the buyer’s outgoing product “money”.

Furthermore, the auctioneer adds a timestamp to the agreement and stores it in the auction’s data basis.

4.4 Basic Services

The basic services layer comprises services which are not specific to a market service, respectively a service-specific component. They provide general functionality and can be used in various contexts. An example is the timer service used by transitions. In combinatorial auctions a math solver like CPLEX³ repre- sented as a service is another possible example for a basic service.

5. SOMA – Prototype of a Service-Oriented Marketplace

In this section we will describe the prototype implementation of the above-mentioned layers. Our implementation is based on the Java 2 Platform, Enterprise Edition (J2EE 1.4), the Web Services technology and the Business Process Execution Language for Web Services (BPEL4WS or BPEL, see [2]). Enterprise JavaBeans (EJB) are used to implement the functionality that is then published and used by employing Web Services standards. BPEL is XML-based and facilitates the integration of elemental Web Services into business processes.

In general, Web Services are said to be the technology for intra- and inter-organizational integration of software components in the future [7]. We chose the Web Services technology because it allows for a high degree of interoperability. Using the functionality of a Web Service is completely independent from its implementation. For that reason Web Services are often referred to as virtual components [8].

5.1 Market Processes

In Section 4.1, we discussed the procurement process as an example of a company-specific business processes and identified some of the services that are therefore needed in 4.2. Figure 5 now shows the procurement process together with the invoked services.

Receive Material Requirements

Choose Market Mechanism

Fine Tune Auction Parameters

Specification of Buy Offer

Auction Initiation

Answer Supplier Request

Get Buyer View Receive

Agreement Store

Agreement Receive

Bill Specify new

Product

Choose Existing Product

Send Buy Offer

Pay Bill Wait for

Receipt of Goods Rate

Business Partner

Choose Suppliers XOR

AND Receive available

Market Mechanisms

Product Catalogue

Auction Registry Auction Registry

Auction Auction

Supplier Request Supplier Request Agreement

History Agreement

History Billing Billing

Payment Payment Reputation

Reputation Production Scheduling Production Scheduling

Warehouse Management

Market Mechanism

Instance Registry Market Mechanism

Instance Registry

Register Auction Instance

Contact Management

Contact Management Reputation

Reputation

Figure 5: Composition of Procurement Process

3 http://www.cplex.com

(8)

To implement the business processes, we chose BPEL for linking groups of Web Services into workflows run by a workflow engine. The composite services [8] are in turn Web Services. BPEL enables the so- called two-level programming [7, 8]: “Programming in the small” for implementing elemental services and “programming in the large” for composing elemental services. Reuse is not only applicable to the level of elemental services but also to the business process model level. Since BPEL processes are Web Services, their interface can be described using WSDL, the Web Service Description Language [1]. In the following, we present a code snippet from the WSDL document of the procurement process. There you can find some of the operations the procurement process offers.

</operation>

</operation>

</operation>

…

</portType>

…

<plnk:partnerLinkType name="ProcurementProcess">

<plnk:role name="ProcurementProcessProvider">

<plnk:portType name="tns:ProcurementProcess"/>

</plnk:role>

</plnk:partnerLinkType>

…

</definitions>

These operations are invoked by our presentation layer. We provide a web-based user interface for man- machine communication. Synchronous calls from the Java Server Pages (JSP) are used to interact with the BPEL process via the Java Business Delegate Interface.

5.2 Market Services

As stated in section 4, we go into detail on the core market service, the market mechanism. Therefore, we present an exemplary implementation of the reverse English auction as one embodiment of the core service. For the realization we chose BPEL, in particular the BPEL engine “Oracle BPEL Process Manager”⁴. The auction service data model is defined by employing XML Schema Definitions⁵ (XSD). All required data types are declared within the WSDL file of the process. They also define variable types and the con- tent of messages for the service’s communication with the “outer world”.

We will draw on the ARM [9] to model our data structure. Accordingly, offers and agreements which both refer to intentions have to be explained. Intentions are defined as follows:

</sequence>

</complexType>

</element>

</element> … </sequence>

</complexType>

4 http://otn.oracle.com/products/ias/bpel/index.html

5 http://www.w3.org/XML/Schema

(9)

Thus, an intention contains incoming and outgoing products, a participant and the attribute binding.

The participant has to specify the products he wants to give away and the ones he wants to have in return.

In our sample auction, we only support intentions with a single incoming and outgoing product. One of those must be of type “money” with an attribute “amount”. If the incoming product is “money”, we speak of a seller’s intention, otherwise of a buyer’s intention. Furthermore, our implementation only accepts binding intentions.

An offer adds a timestamp to an intention and is defined by the following XSD:

</sequence>

</extension>

</complexContent>

</complexType>

An agreement comprises the buyer’s and the winning seller’s intention as well as a timestamp element:

</sequence>

</complexType>

Within our market mechanism service, the participant’s intentions are collected in a data basis and finally condensed into agreements. For storage, our BPEL process provides twoglobal XML variables: offer- Container and agreementContainer. Both are declared as an unbounded sequence containing elements of the particular data structure. The manipulation of these variables is accomplished by using XPath⁶.

Figure 6: BPEL Auction Process - Overview Stage

In compliance with the auction illustrated in section 4, the BPEL process comprises an auction flow with three stages executed in a sequence. The process logic for each stage is encapsulated in a scope.

6 XML Path Language, http://www.w3.org/TR/xpath

(10)

Principally, all stages follow the same pattern with a <pick> activity waiting for either a view request, a newly submitted offer or a transition message. This activity is embedded within a <while> loop, triggered by the local boolean variable stageFinished. Only if a transition message arrives, this variable is set to ‘1’ and the process proceeds to the next stage.

After receiving a newly submitted offer, it is checked for validity. If it passes the validation, it is added to the offer container and the transition service is notified. Due to the fact that transitions – in contrast to theoretical assumptions – need calculation time, the process flow is interrupted at this point until the transition service is completed. This synchronization is required to guarantee a proper auction flow.

In case a participant requests a view, the accordant view is generated and sent back to the requestor. We thereby decided on a synchronous polling mechanism. The process terminates with the completion of the last stage. Figure 6 allows a deeper insight on how stages are implemented.

5.3 Service-Specific Components

After this top-level demonstration of the reverse English auction BPEL process, we now proceed with an explanation on how its specific components are implemented. The illustrations provide one example for each type of component, namely validation, transition, view and agreement generation. The validation of new offers is accomplished by executing the XQuery⁷ expression validNewOfferView whereat a new offer is passed as an input parameter. This particular view returns the offer itself if it is valid or an empty set otherwise. For instance, the validity criteria for stage 1 as presented in 4.3 are implemented by the following XQuery:

{$newOffer[

binding = "true" and participant/participantID != "" and outgoingProducts/product[name="money"] and outgoingProducts/product[name="money"]/attribute[attName="maxAmount"] and

outgoingProducts/product[name="money"]/attribute[attName="minAmount"] and

number(outgoingProducts/product[name="money"]/attribute[attName="minAmount"]/attValue) >= 0 and number(outgoingProducts/product[name="money"]/attribute[attName="maxAmount"]/attValue) >

number(outgoingProducts/product[name="money"]/attribute[attName="minAmount"]/attValue) and incomingProducts/product and timeStamp gt $stages//stage[stageID=1]/startTime and

timeStamp le $stages//stage[stageID=1]/endTime]

}

</offerSet>

The transition component of stage 2 constitutes a very good example of how they are designed and implemented. Within a <pick> activity, the transition awaits two types of messages: a newOffer message sent by the auction process and a timeout message posted by the timer service. Once the newOffer message handler is triggered, which due to the validity criteria implies that the leadingOfferView has changed, a ResetTimer message is sent to the timer service. The transition calls back the auction process as soon as a timeout arrives and thus finalizes stage 2.

Views are implemented in a pull-manner by ap- plying filters and transformations on the data basis upon request. For instance, a seller in stage 2 is provided with the price specified in the current leading offer.

7 http://www.w3.org/XML/Query

Figure 7: Overview Transition

(11)

Therefore, the following XQuery expression is employed:

let $so :=

for $c in //offer where

$c/timeStamp gt $stages//stage[stageID=2]/startTime and $c/timeStamp le $stages//stage[stageID=2]/endTime

order by number($c/incomingProducts/product[name="money"]/attribute[attName="amount"]/attValue) return $c

return

{if ($so[1]) then <priceSet>

<price>

{data($so[1]/incomingProducts/product[name="money"]/attribute[attName = "amount"]/attValue)}

</price>

</priceSet>

}

</leadingOfferPrices>

Initially, all offers submitted within stage 2 are retrieved in ascending order of the specified amount of money. The first element is the leading offer whose amount of money is returned. If no offer has been submitted yet, an empty set is returned.

The agreement generation generally comprises the winner and price determination, as well as the creation of the agreement XML document. The winner’s offer and the price he has to pay are provided by auctioneer views whose results are assembled to an XML document by XQuery expressions in the agreement generator:

{$openingOffer/participant}

<binding>{$openingOffer/binding}</binding>

{$openingOffer/incomingProducts}

{$openingOffer/outgoingProducts/product[name="money"]/pID}

{$openingOffer/outgoingProducts/product[name="money"]/name}

{$openingOffer/outgoingProducts/product[name="money"]/attribute [attName!="amount"]}

<attName>amount</attName>

<attValue>{data($winningOfferPrices//price[1])}</attValue>

<attType>String</attType>

</attribute>

</product>

{$openingOffer/incomingProducts/product[name!="money"]}

</outgoingProducts>

</intention1>

{$winningOffers//offer[1]/participant}

<binding>{$winningOffers//offer[1]/binding}</binding>

{$winningOffers//offer[1]/incomingProducts}

{$winningOffers//offer[1]/outgoingProducts}

</intention2>

<timestamp>{current-dateTime()}</timestamp>

</agreement>

</generatedAgreements>

5.4 Basic Services

The timer service used by the transition component represents the only basic service within our example.

It is also realized as a BPEL process and facilitates the operations start, stop and reset.

6. Summary and Future Work

In this paper, we motivated and presented our framework for service-based marketplaces. This approach systematically condenses the characteristic interdependencies of markets to the interplay of the two levels Market Services and Service-Specific Components. As an example for tackling the structural challenges

(12)

within these two levels, we incorporated a design for the core services – the market mechanisms. In compliance with the Auction Reference Model, we structured the auction service to encourage a broad range of embodiments. We incorporated the concepts of service-oriented architectures on multiple levels ex- ploiting known advantages like flexibility, reusability, etc.

BPEL and Web Services were chosen as the enabling technologies that firstly facilitate the realization of a service-based marketplace on all presented layers in this consequently service-oriented manner.

The actual implementation of a running proof-of-concept system was presented and explained. However, many aspects remain that call for further elaboration and examination. We particularly plan on implementing other interchangeable auction services of different auction types and to research into the structure of market processes. In order to facilitate the customization of market processes according to their specific requirements we plan to provide a tool that assists companies in specifying their business processes.

7. References

[1] Christensen, E., Curbera, F., Meredith, G., Weerawarana, S. “Web Services Description Language (WSDL) 1.1.”, W3C Note March 2001. http://www.w3.org/TR/wsdl, 2001, Download 2004-07-09.

[2] Curbera, F., Andrews, T., Dholakia, H., Goland, Y. Klein, J., Leymann, F., Liu, K., Roller, D., Smith, D., Thatte, S., Trickovic, I., Weerawarana, S. “Business Process Execution Language for Web Ser- vices”, BEA Systems & IBM Corporation & Microsoft Corporation.

http://www.106.ibm.com/developerworks/library/ws-bpelwp, 2002

[3] Kaufmann, R., Mohtadi, H. “Proprietary and Open Systems Adoption in E-Procurement: A Risk- Augmented Transaction Cost Perspective”, Journal of Management Information Systems, 2004, Vol. 21 Issue 1, pp. 137-167

[4] Kim, J. B., Segev, A., Patankar, A., Cho, M.G. “Web Services and BPEL4WS for Dynamic eBusiness Negotiation Processes”, Proceedings of the 1^st International Conference on Web Services, Las Vegas, USA, 2003 (ICWS '03)

[5] Kim, J. B.; Segev, A. “A Web Services-Enabled Marketplace Architecture for Negotiation Process Management”, accepted, Decision Support Systems, Special Issue on Web Services and Process Man- agement

[6] Kim, J. B., Segev, A. “A Framework for Dynamic eBusiness Negotiation Processes", Proceedings of IEEE Conference on E-Commerce, New Port Beach, USA, 2003 (CEC '03)

[7] Kossmann, D., Leymann, F. “Web Services“, Informatik Spektrum, Vol. 27, pp. 117-128, 2004

[8] Leymann, F. “Web Services: Distributed Applications without Limits” Business, Technology and Web 2003, Weikum, G. (Edt.), pp. 2–236.

[9] Rolli, D., Eberhart, A. “An Auction Reference Model for Describing and Running Auctions”, To ap- pear in: Proceedings of the Wirtschaftsinformatik, Bamberg, Germany, 2005.

[10] Rolli, D., Neumann, D., Weinhardt, C. “A Minimal Market Model in Ephemeral Markets”, Proceed- ings of the TheFormEMC Workshop, Toledo, Spain, 2004.

[11] Stevens, M. E. “Service-Oriented Architecture”, Java Web Services Architecture, James McGovern, Sameer Tyagi, Michael Stevens (Ed.), Morgan Kaufmann Publishers, 2003.

[12] Smeltzer, L., Carr, A. “Electronic reverse auctions: Promises, risks and conditions for success”, Indus- trial Marketing Management, 2003, Vol. 32, pp 481 -490

[13] Ströbel, M., Weinhardt, C. “The Montreal Taxonomy for Electronic Negotiations”, Journal of Group Decision and Negotiation, 12(2), 2003, pp. 143-164.

[14] Wurman, P. R., Wellman, M. P., Walsh, W. E. “A Parametrization of the Auction Design Space”

Games and Economic Behavior 35. 2001. S. 304-338.