USING UDDI REGISTRY AND WORKFLOW ENGINE FOR

MANAGING E-PROCUREMENT PROCESSES

Juha Puustjärvi

Lappeenranta University of Technology, Skinnarilankatu 34, Lappeenranta, Finland

Keywords: B2B, e-procurement, e-auctions, Web Services, UDDI.

Abstract: In electronic business buyers and sellers should be able to interact with each others inside an architecture

that is easy to use and maintain. Electronic auctions are an interesting approach to achieve this goal by

bringing together business in the Web. Further the greatest benefits lie in cost reduction for buyers and

sellers. Technically, an electronic marketplace is a virtual place that resides somewhere in the Internet. They

can provide several types of business processes depending upon their target audience. A form of such

processes is e-procurement. E-procurement technology is any technology designed to facilitate the

acquisition of goods by a commercial or a government organization over the Internet. A form of e-

procurement is reverse e-auctioning. In such auctions the supplier that made the lowest offer wins the

auction. In this paper we describe the e-procurement system that we are developing. In particular we present

how taxonomies and user profiles can be utilized in improving the effectiveness of the e-procurement

process. From technological point of view we present how suppliers’ Web services support e-procurement

specific operations, and how BPEL4WS (Business Process Execution Language for Web Services) can be

used in orchestrating these Web services. In addition, we present how UDDI (Universal Description,

Discovery, and Integration) registry can be utilized in storing the used taxonomies and the profiles of the

suppliers. In this way we can achieve high recall and precision fractions in searching relevant suppliers.

1 INTRODUCTION

E-procurement technology is any technology

designed to facilitate the acquisition of goods by a

commercial or a government organization over the

Internet. Using such a technology we can achieve

many advantages including:

• reducing administrative costs,

• shortening the order fulfilment cycle time,

and

• lowering inventory levels and the price paid

for goods.

A form of e-procurement is reverse e-auctioning.

In reverse e-auctioning buyers buy goods by using

Internet technology from a number of known or

unknown suppliers. In such auctions the supplier

that made the lowest offer wins the auction.

Most auction software developed for e-

auctioning is based on advanced auction formats

such as on combinatorial auctions and on multi-

attribute auctions (Nissan, 200). In combinatorial

auctions bidders are allowed to place offers on sets

on items whereas in multi-attribute auction price is

not the only negotiable parameter.

Auctions are usually defined by their rules. The

rules are typically classified into three classes (Klein

and Keefe, 1999): rules that control the admission

of bids, rules that control the information revealed

by the auction, and rules that control how the

auction computes trades. The architectures of the

auctions systems typically reflect these rules

(Wurman et.al, 2001). Some architecture originates

from workflow systems and contract management

systems. There are also many research efforts

concentrating on agent technology for electronic

market transactions,e.g., (Wurman et.al, 2005).

A common problem of e-procurements systems

is the retrieval of relevant suppliers. Ideally the

system should be able to retrieve all the suppliers,

which are relevant while retrieving as few non-

relevant suppliers as possible. This kind of quality of

supplier retrieval can be measured by the following

fractions:

Puustjärvi J. (2007).

USING UDDI REGISTRY AND WORKFLOW ENGINE FOR MANAGING E-PROCUREMENT PROCESSES.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Society, e-Business and e-Government /

e-Learning, pages 72-76

DOI: 10.5220/0001262700720076

 SciTePress

• Recall: the fraction of the relevant suppliers,

which has been retrieved.

• Precision: the fraction of the retrieved

suppliers, which is relevant.

The values of these fractions are highly

dependent on the way the suppliers and their

products are modelled and how the searching of

suppliers is done.

In this article we focus on e-procurement

technology supporting reverse multi-attribute

auctioning. In particular, we will consider the

technical solutions of the e-procurement system that

we are developing. A corner stone of the system is

the private UDDI (Universal Description, Discovery,

and Integration) -registry that is used for searching

relevant suppliers. The registry supports a variety of

taxonomies including industry taxonomy, product

and service taxonomy and location taxonomy. Using

these taxonomies in retrieving relevant suppliers we

can achieve high recall and precision fractions.

The main ingredients of the e-procurement

system are the private UDDI registry, workflow

engine, and the Web services. The workflow engine

coordinates the procurement processes. The UDDI

registry also includes information supplier’s Web

services that support procurement specific

operations such as “Request for Bid”- operation

The rest of the paper is organized as follows.

First, in Section 2, we give a short introduction to

Web services. Then, in Section 3, we first give an

overview of the UDDI registries, and show how a

private UDDI registry can prove services for the e-

procurement broker. Then, in Section 4, we give an

overview of BPEL4WS (Business Process Execution

Language for Web Services) and show how it can be

used for specifying the coordination requirement of

the workflow engine which runs procurement

processes. After this, in Section 5 we illustrate how

the ingredients (private UDDI registry, suppliers

Web services and the workflow engine) are put

together to form a working e-procurement system.

Finally, section 6 concludes the paper by discussing

the advantages and limitations of our proposed

technical solutions.

2 WEB SERVICES

Web services are XML-based (Newcomer, 2002)

self-describing applications that can be published

and invoked across the Internet. Web services use a

loosely coupled integration model to allow flexible

integration of heterogeneous systems. A nice feature

of web services is that new and more complex Web

services can be composed of other web services.

Our distributed architectural model of Web

services is comprised of three types of participants:

service provider, service brokers, and service

requesters. This architectural model presupposes that

services can be first found from the UDDI registry,

and then used. This in turn requires exact

descriptions of the services. WSDL (Web Service

Description Language) (WSDL, 2001) is an XML-

based language (Harold and Scott, 2002) for

describing a programmatic interface to a Web

service. It includes for example input and output

message formats and the operations provided by the

service.

For example, in our e-procurement model

supplier’s Web services support the operation

“Request_for_Bid”, which has the parameters

product_id and quantity. Accordingly e-procurement

broker’s Web service supports operation “Response

_for_Bid”, which has the parameters

“Suplier_Name” and “Bid. This information is

passed between Web services by the SOAP protocol

(SOAP, 2002). It is a protocol specification for

invoking Web services and defining a uniform way

of passing XML-encoded data

The SOAP-envelope for passing the

“Request_for_Bid”-operation is presented above in

Figure 1.

3 UDDI REGISTRY

Basically UDDI registry describes a mechanism for

registering and locating Web services (Daconta et.

al, 2003). This in turn requires that in UDDI service

providers describe their organization and register

their Web services.

The information in UDDI consists of three parts

white pages, yellow pages and green pages. White

pages include company’s contact information. It

may also include description of the company or links

<SOAP-ENV: Envelope

xmlns:SOAP-ENV=“http://schemas.xmlsoap.org/soap/envelope/

”

SOAP-ENV:encodingStyle=

”http://schemas.xmlsoap.org/soap/encodig/”>

<SOAP-ENV:Body>

<os:request_for_bid

xmlns:=”http://www.it.lut.fi/transaction/ontology/

”>

<product_id_name>Nokia E 90</product_id>

</os:request_for_bid>

</SOAP-ENV: Body>

</SOAP-ENV: Envelope>

Figure 1. A SOAP-messaage for a ”request-for-bid” operation.

Figure 1: A SOAP-message for a “request-for-bid”

operation.

USING UDDI REGISTRY AND WORKFLOW ENGINE FOR MANAGING E-PROCUREMENT PROCESSES

to external documents that describe the business in

more detail.

In our private UDDI registry yellow pages

consist of business categories organized according to

following taxonomies:

• Industry: Classification of the industry

supported by the e-procurement system.

• Products and services: Classification of the

products and services of the suppliers of the e-

procurement system.

• Geographical location: Classification of the

country and region codes.

So, searching on yellow pages can be performed to

locate business that service particular industry or

product category, or are located in a particular

geographic region.

Green pages consist of the information

businesses use to describe how other businesses

conduct electronic commerce with them. In

particular, green pages include technical information

of the exposed services. For example, the WSDL

descriptions of the Web services are included in

green pages.

UDDI specifies also two APIs for programmatic

access to UDDI registry. The inquiry API is used for

retrieving information from a registry and the

Publishing API is used for storing information.

For our purpose we use UDDI for storing

information (Publishing API) and for retrieving

information (Inquiry API). To illustrate this let us

consider the structure of a taxonomy presented in

Figure 2. For example, in the case of classifying

ICT-devices, the correspondence of symbols could

be the following: P= ICT device, P1=memory unit,

P2=laptop, P3=mobile device, and so on.

Now, when a supplier makes registration (using the

Publishing API) the supplier specifies using the

taxonomy which kind of products it can provide,

e.g., if it specifies P1, it means that also provides

products of its descendants, i.e., P1,1, P1,2 and P1,3.

Then when a buyer (or the e-procurement broker)

retrieves products or services (using the Inquiry

API) it specifies one or more nodes from the

taxonomy. For example, in the case of P2 (laptop),

the UDDI registry returns the Web services of the

suppliers which sell laptops.

4 BPEL4WS

The BPEL4WS (BPEL, 2004) processes are XML-

based grammars that can be executed by workflow

engine (orchestration engine), e.g., by IBM’s

BPWS4J (BPWS4J, 2004). The engine reads the

BPEL4WS document and invokes the necessary

Web services in the order required by the process.

A nice feature of BPEL4WS is that we can

generate executable BMEL4WS code from the

BPMN (Business Process Modeling Notation). The

reason for using BPMN is that the BPMN notation is

readily understandable for the buyers and sellers of

the system. It is also readily understandable for the

business analyst that create the drafts of e-

procurement processes as well as for the technical

developers responsible for implementing the

technology that will perform those processes.

We now give an overview of the BPMN. First

we describe the types of graphical objects that

comprise the notation, and then we show how they

work together as part of a Business Process Diagram

(BPD) (BPMN, 2004). After it we give a simple

reverse e-auction description using BPD.

In BPD there are tree Flow Objects: Event,

Activity and Gateway. An Event is represented by a

circle and it represents something that happens

during the business process, and usually has a cause

or impact. An Activity is represented by a rounded

corner rectangle and it is a generic term for a work

that is performed in companies. The types of tasks

are Task and Sub-Process. So, activities can be

presented as hierarchical structures. A Gateway is

represented by a diamond shape, and it is used for

controlling the divergence and convergence of

sequence flow.

In BPD there are also three kind of connecting

objects: Sequence Flow, Message Flow and

Association. A Sequence Flow is represented by a

solid line with a solid arrowhead. A Message Flow

is represented by a dashed line with an open

arrowhead and it is used to show the flow of

messages between two separate process participants.

An Association is represented by a dotted line with a

line arrowhead, and it used to associate data and text

with flow objects.

We now consider how a reverse electronic

auction can be represented by a BPD. In this

example, the auction system runs an auction which

is comprised of time rounds where an offer is

P1,1 P1,2 P1,3

P3,1

P3,2

Figure 2. The structure of the product taxonomy.

Figure 2: The structure of the product taxonomy.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

required from each supplier before the auction can

proceed. Such auctions can be conceptualized as

having four Activities (Figure 3):

• Request for Bids: The broker requests the

suppliers to make an offer of certain products or

services.

• Make Bid: The suppliers make bids and

send them to the broker.

• Make decision: The broker makes the

decision which bids are accepted and which bids are

rejected and sends a message to each supplier. In

addition, if the broker did not make deal of all

products it needs, then the broker may request the

suppliers to make additional offers.

• Perform clearing activity, where the

agreed-upon contract is executed and payments are

made.

5 E-PROCUREMENT BROKER

In this section we describe the main functional

components of the e-procurement server (Figure 4).

Essentially the e-procurement broker brings together

various companies. An important feature is that it

can simultaneously support a set of procurement

processes which may be based on different e-

procurement formats (e.g., whether the bids are

sealed or not).

The Buyer’ application registers new users and

collects their preferences in Web forms and forwards

this information (through Web services) to the E-

procurement broker, which in turns stores the

information to the private UDDI registry, which is

part of the brokers database.

Basically, there are two approaches how

companies (in the role of buyer or supplier) can

integrate their system with the e-procurement

broker.

• A person of company (in the role of a buyer

or a supplier) communicates with the e-

procurement broker through an application

(buyer’s application or server’s application)

and Web service interface.

• A company integrates its ERP-system with

the e-procurement broker.

The gain of the first approach is that it has

minimal initial costs but has high operational cost as

it requires duplication of procurement management

effort. In the second approach the costs are other

way around. However this approach is extremely

fascinating as it allows (through a Web service) the

integration of the ERP-system (Enterprise resource

Planning system) with the e-procurement broker. In

particular, this approach nicely matches with the

third wave ERP-systems which are based on Web

service technology.

The internal components of the e-procurement

broker are presented in Figure 5.

Buyer

Buyer’s application

Buyer’s

Web service

Buyer’s ERP

Buyer’s

Web service

E-procurement broker

Supplier’s

Web service

Spplier’s

Web service

Suplier’s ERP

Suplier’s application

Suplier

Figure 4. The architecture of the system.

…

Web service interface

Requet

for Bids

Make

Bid

Make

decision

Perform

clearing

Figure 3. An example of a BPD in e-procurement.

Need for

new round

Yes

Figure 3: An example of a BPD in e-procurement.

Figure 4: The architecture of the system.

USING UDDI REGISTRY AND WORKFLOW ENGINE FOR MANAGING E-PROCUREMENT PROCESSES

E-procurement broker

Workflow

engine

Revealing

manager

Clearing

manager

Profile

manager

Bid

manager

E-procurement database

(including UDDI-registry)

Figure 5. The components of the e-procurement broker.

The Bid manager controls the admission of bids, i.e.,

control that all the bids are done according to the bid

rules. The Revealing manager governs the revealing

of the information of an auction. The Clearing

manger computes the trades. The Profile manager

maintains the user profiles that are stored in the

database (i.e., in UDDI registry). The profiles

include preferences, which are collected at user

registration

The Auction database contains the UDDI-

registry, user profiles and the BPEL4WS

specifications of various auction protocols. The

Workflow engine (orchestration engine) loads

BPEL4WS specifications from the e-procurement

database and then runs the processes. The Workflow

engine reads the BPEL4WS document and invokes

the necessary Web services in the order required by

the process.

6 CONCLUSIONS

In electronic business buyers and sellers should be

able to interact with each others inside an

architecture that is easy to use and maintain.

Electronic auctions are an interesting approach to

achieve this goal by bringing together business in

the Web.

E-procurement technology is any technology

designed to facilitate the acquisition of goods by a

commercial or a government organization over the

Internet. Using such a technology we can achieve

many advantages including reducing administrative

costs, shortening the order fulfilment cycle time, and

lowering inventory levels and the price paid for

goods.

A problem of e-procurements systems is how

the system can find relevant suppliers. Ideally the

system should be able to retrieve all the suppliers,

which are relevant while retrieving as few non-

relevant suppliers as possible

In this article we have described the e-

procurement system that we are developing. A

salient feature of the system is the private UDDI-

registry which is used for finding relevant suppliers.

The registry uses many taxonomies including

industry taxonomy, product-taxonomy and location

taxonomy. Using these taxonomies we aim to

achieve high recall and precision fractions in

searching relevant suppliers.

In future we aim to extend the e-procurement

system by mobility features such that buyers and

suppliers can interact with the e-procurement system

by their mobile devices. From technology point of

view we will use mobile Web services in

implementing mobile interaction. Probably mobile

Web services will allow the development of many

new auction formats also for B2C.

REFERENCES

BPEL, 2004. BPEL4WS – Business Process

Language for Web Sevices.

http://www.w.ibm.com/developersworks/webservices/

library/ws-bpel/

BPWS4J, 2004, A platform for creating and executing

BPEL4WS processes.

http://alphaworks.ibm.com/aw.nsf/download/bpws4j

BPMN, 2004. Business Process Modeling Notation

(BPMN), http://www.bpmn.org/

Daconta, M., Obrst, L. & Smith, K. (2003). The semantic

web. Indianapolis: John Wiley & Sons.

Harold E. and W. Scott W (2002) . XML in a nutshell.

O’Relly & Associates.

Klein S, and R. O’Keefe R. (1999). The Impact of Web

on Auctions, International Journal of Electronic

Commerce, 3(3).

Newcomer E. (2002) Understanding Web Services.

Boston: Addison-Wesley.

Nissan, N, (2000). Bidding and allocation in combinatioral

auction. In proc Second ACM Conference on

Electronic Commerce.

SOAP, (2002). SOAP – Simple Object Access Protocol.

http://www.w3.org/TR/SOAP/

WSDL, 2001. WSDL- Web Services Description

Language. http://www.w3.org/TR/2001/NOTE-wsdl-

20010315

Wurman, P. Wellman W. and Walsh. A

(2001)parametrization of the auction design space.

Games and Economic Behavior. 35(1-2).

Wurman P. (2005), Online Auction Site Management.

http://www.csc.ncsu.edu/faculty/wurman/Papers/Wur

man-article.pdf.

ure 5: The com

onents of the e-

rocure

ent broker.

WEBIST 2007 - International Conference on Web Information Systems and Technologies