ACM SIGAPP PageTypically, the sensor networks are composed of many wire-less sensor nodes deployed...

Applied Computing Review 2


SIGAPP FY’10 Annual Report July 2009- June 2010Sung Shin

MissionTo further the interests of the computing professionals engaged in the development of new computing applications and to transfer the capabilities of computing technology to new problem domains.

OfficersChair Sung Shin

South Dakota State University, USAVice Chair Richard Chbeir

Bourgogne University, Dijon, FranceSecretary W. Eric Wong

University of Texas, USATreasurer Lorie Liebrock

New Mexico Institute of Mining and Technology, USAWeb Master Hisham Haddad

Kennesaw State University, USAACM Program Coordinator Irene Frawley

ACM HQ

Notice to Contributing AuthorsBy submitting your article for distribution in this Special Interest Group publication, you hereby grant to ACM the following non-exclusive, perpetual, worldwide rights.

• to publish in print on condition of acceptance by the editor • to digitize and post your article in the electronic version of this publication • to include the article in the ACM Digital Library • to allow users to copy and distribute the article for noncommercial, educational or research purposes

However, as a contributing author, you retain copyright to your article and ACM will make every effort to refer requests for commercial use directly to you.

Status UpdateThe main event that took place within SIGAPP for this year was the Symposium on Applied Computing (SAC) in Switzerland after taking place in Honolulu, Hawaii for 2009. This year's SAC was very successful. More details about SAC will follow in the next section. We also supported several additional conferences with in-cooperation status, and will continue supporting additional conferences in the coming year.

SIGAPP’s web page has been redesigned by Hisham Haddad, Web Master of SIGAPP in April. A brand new SIGAPP logo has been selected from a logo competition and will be used for the SIGAPP web page and official publications such as the proceedings of SAC and Applied Computing Review.

I’m pleased to announce the reissuing of ACR (Applied Computing Review). As you know, ACR is the newsletter of the ACM SIGAPP. It hasn’t been published since 2002 and has been strongly desired by


the members of SIGAPP. We’re introducing it semi-annually as an electronic version only. Once the format has stabilized, we’ll begin publishing quarterly electronically and in print. Ultimately, we want ACR to appear in the SCI (Science Citation Index). ACR contains invited papers from world-renowned researchers and selected papers presented by prominent researchers and professionals in the Symposium on Applied Computing 2010 in Sierre, Switzerland. The selected papers have been expanded, revised, and peer-reviewed again for publishing in ACR. We hope that ACR will serve as a platform for many new and promising ideas in the many fields of applied computing. As you know, it is strongly related to nearly every area of computer science, and we feel an obligation to serve you as best we can. The papers in this issue of ACR represent the current applied computing research trends. These authors truly contribute to the state of the art in applied computing.

The Student Travel Award Program continues to be successful in assisting SIGAPP student members in attending conferences sponsored by or in-cooperation with SIGAPP. 24 students were granted awards to attend SAC 2010, representing 14 countries. This was a bit less than last year, but we supported everyone who applied for Travel Award Program. The allocated budget for these awards increased compared to last year. We also implemented a Developing Countries Travel Award for researchers from developing countries who would otherwise have difficulty attending the SAC conference. For 2010, this award was used exclusively for students from developing countries, but in 2011 and beyond we hope to support faculty-level researchers from such countries.

SIGAPP continues to have a stable membership, and its strength and uniqueness among ACM SIGs continues to be an opportunity for scientific diversity and crosscutting multiple disciplines within the ACM community. To encourage this, SIGAPP is continuing to accept proposals for new tracks this year. The officers look forward to working with the ACM SIG Governing Board to further develop SIGAPP by increasing membership and developing a new journal on applied computing. They also appreciate the opportunity to support the programs of SIGAPP since they have provided a springboard for further technical efforts and have done a great service to many technical communities.

New SIGAPP logoFor the first time ever, SIGAPP has an official logo. Designers from around the world sent in their entries as part of a logo competition, chaired by Dr. Richard Chbeir. After five months in the selection process, the final logo design was chosen by the logo competition task force, and Virginia Sprang became the victor. Congratulations!

Next Issue

The planned release for the next issue of ACR is February 2011.


SAC 2010 OverviewSAC Steering Committee

The 25th Annual edition of SAC has marked another successful event for the Symposium on Applied Computing. This international gathering attracted over 490 attendees from over 70 counties. It was hosted and held on the campus of University of Applied Sciences Western Switzerland (HES-SO) in Sierre, Switzerland, March 2010. On Monday, the tutorials program offered 8 tutorials and attracted over 60 attendees. The program included coffee breaks and a social luncheon that took place in a historic restaurant located near the campus. The four-day technical program included over 340 presentations from forty tracks covering a wide range of topics on applied computing. The successful posters programs attracted over 80 posters that were presented over two sessions on Wednesday. Thanks to a great organizing committee, it was extremely successful. In all, 1353 papers were submitted, the most in the history of the SAC, and the final acceptance rate for SAC 2010 was 26.9% for the overall track.

The Tuesday and Thursday keynote addresses were well attended and received. On Tuesday, Professor Bertrand Meyer, Professor of Software Engineering at the Swiss Federal Institute of Technology, talked about the future of programming and shared his vision of how programming will evolve over the next 10 years. He also discussed how current and new techniques can help software developers cope with society's increasing software demands, both quantitative and qualitative. The address was well received and followed by an active Q&A session. On Thursday, Professor Willy Zwaenepoel, Professor and Dean of the School of

Computer and Communication Sciences, EPFL, Lausanne, Switzerland, talked about the dilemma of research publications and the impact of published work in real systems. Specifically, the contradiction between the complexity of published work and simplicity of ideas to have positive impact in real systems. He presented examples of ideas that were successfully transferred to practice, and some ideas on how one can improve the situation. The address was well received by the audience and followed by an active Q&A session.

Entertainment at the Banquet

Organization Committee Dinner

Chatting at the Conference


A number of business meetings were held during SAC 2010, mainly the SIGAPP annual meeting to discuss the current and future directions of the SIG, the SAC organization meeting where proposals for hosting future SAC meetings are presented, and the Track Chairs business meeting where feedback and planning for future SAC tracks are discussed. The social program included daily lunches and coffee breaks provided on site, allowing attendees to gather, converse, and network. On Tuesday, SIGAPP and the host institution hosted a reception. The main social event was the Banquet that was held at Center Le Régent Crans-Montana. The event included live entertainment and the Awards Ceremony. SAC Steering Committee encourages the readers to check SAC 2010 website for more information about the conference events, best paper awards, and some pictures of the event. The committee also encourages the readers to participate in SAC 2011 in Taichung, Taiwan, March 2011. We hope to see you there.

SAC Summary Info1. SAC 2010 Awards:

1. Distinguished Service to SAC:

Sung Shin

2. Outstanding Service to SIGAPP:

Barrett R. Bryant

3. Student Travel Awards: 24 awards granted, totaling $12,671.15

2. New tracks in SAC 2010:

1. Bioinformatics

2. Computer Forensics

3. Power-Aware Designed Optimization

4. Privacy on the Web

5. Applications of Evolutionary Computing

SAC 2011 will be held in Taichung,Taiwan, March 21-25, 2011, and will be hosted by the Tunghai University, Taichung, Taiwan. The web site has further details such as the symposium committee, technical tracks, and track chairs. http://www.acm.org/conferences/sac/sac2011/

SAC 2012 is being planned for Italy which has been selected from three SAC local host proposals: Korea, Italy, and Portugal.

The Banquet


Virtual Protocol Stack for WSN Simulators

Yookun ChoSeoul National University, Korea

[email protected]

Jinman JungSeoul National University, Korea

[email protected]

ABSTRACTIn the most recent years, many kinds of simulation packageshave been developed for wireless sensor networks. Networkdevelopers, engineers, and researchers are frequently usingthe network simulators for evaluating performance and ef-ficiency of their network protocols. However, the existingwireless network simulators have some drawbacks such asdifficulties in programming, lenthy compile time, hard tounderstand simulator engine, and their reliability issues. Inthis paper, we present the Virtual Protocol Stack (VPS)for wireless network simulators. The VPS provides twoimportant features; 1) a unified programming interface fordeveloping network protocols, and 2) separation of simula-tor engine and the network protocols. By using the VPS,developers no longer concern about understanding differentsimulator engines. By doing so, developers can share theirnetwork protocol modules with each other. We implementedand adapted VPS on existing well-known simulation pack-ages, and we observed that VPS well adapted to the differentwireless network simulators.

Categories and Subject DescriptorsI.6.7 [Simulation and Modeling]: Simulation SupportSystems—Environments

General TermsPerformance, Measurement

KeywordsSimulation, Wireless Sensor Networks

1. INTRODUCTIONIn most recent years, wireless sensor networks have been

one of the hot topics in the field of computer science and en-gineering. Many network protocols, system-level techniques,

huge number of hardware and software methods were devel-oped to provide better performance in actual sensing envi-ronments [1]. They have been used in many different envi-ronments such as academies [16], forest [11], buildings, andeven harsh environments [8].

Typically, the sensor networks are composed of many wire-less sensor nodes deployed in the remote region to senseevents. Each sensor node performs sensing, computing, andmulti-hop wireless communication between nodes. The nodesare very resource-constrained to maximize cost-efficiency ofthe whole networks [7]. For example, Berkeley’s Mica seriesconsist of 4-kB RAM, 8 bit CPU, radio transmission module,and limited alkaline or lithium batteries [4].

In wireless sensor networks, energy-efficiency is the mostimportant factor because the sensor nodes have limited bat-teries. Huge number of researches have been made to pro-vide more energy-efficient communication, sleep scheduling,and even system-level software techniques. On developingphase of new mechanisms, it is crucial to measure their per-formance and energy-efficiency in the whole sensor networks.However, using the actual sensor networks require significantcost to buy, deploy, and manage them. This is the reasonwhy the developers need some instruments to simulate thewhole wireless sensor networks. By using simulation pack-ages, the developers can minimize the time and cost con-sumed in the performance evaluation. In addition, simu-lation packages can generate a lot of valuable informationwhich is hard to get in the actual sensor networks.

Many network simulators have been developed to test andevaluate performance of new mechamisms in the wirelesssensor networks such as SENSE [3], EmStar [5], GloMoSim[6], TOSSIM [9], ns-2 [12], OMNeT++ [13], OPNET [14],QualNet [15], and SensorMaker [18]. However, they stillhave some drawbacks such as difficulties in programming,lenthy compile time, hard to understand simulator engine,and their reliability issues. Some of them are hard to usefor various communication protocols [9], and some of themare not appropriate to measure and evaluate network rout-ing and clustering protocols. In addition, some simulatorsare too complex to understand their internal structures andprogramming interfaces [12].

In this paper, we present theVirtual Protocol Stack (VPS)for network simulations in wireless sensor networks. VPS ismainly focused on the following two features; 1) providing aunified programming interface for developing network proto-cols, and 2) separation of simulator engine and the networkprotocols. This approach is much similar to existing VFS,which is an architecture for multiple file systems. By us-


ing the VPS, developers do not need to understand multipledifferent simulator engines. When developer develops a net-work protocol binary module according to the VPS, it canbe simulated for multiple wireless sensor network simulatorswithout any modifications. We implemented and adaptedVPS on existing well-known simulation packages, and weobserved that VPS well adapted to the different wirelessnetwork simulators.The rest of this paper is organized as follows. In Section 2,

we present several previous works on the existing simulatorsfor wireless sensor networks. Section 3 presents the internalstructures of the VPS. Section 4 presents the implementa-tion and usage of the VPS, and Section 5 evaluates perfor-mance and reliability of the VPS in the large-scale wirelesssensor networks. Finally, some conclusions and future workare given in Section 6.

2. RELATED WORKSIn this section, we present several previous simulators re-

lated to our proposed virtual protocol stack. Many researchefforts were made on developing simulation and instrumen-tation toolkits for wireless sensor networks [2, 3, 5, 9, 6, 12,13, 14, 15, 17, 18].The ns-2 [12] is the famous simulator for both wired and

wireless networks. It was developed by LBNL, UC Berkeley,CMU, and many other research institutes, and it has beenused for many kinds of previous works related to the networkprotocols. However, ns-2 is very hard to program becauseit uses both OTcl (object-oriented tool command language)and C++, and the internal structures are too complex tounderstand thoroughly. For this reason, many efforts havebeen made to implement easier simulation packages than thens-2.The EmStar [5] is a wireless network simulator which was

developed by UCLA in 2004. It adapts the event-drivenarchitecture, and supports graphic interface on the Linux’sX-window. The EmStar was designed for detecting faultsand problems between sensor nodes, and there are manydocuments and tutorials on their website. However, it alsohas few functions to measure the performance of the sensornodes, and it is used only small number of researches.The TOSSIM [9] is a well-known simulator for applica-

tions running on TinyOS [10]. It was developed by UCBerkeley’s TinyOS project team. The main goal of theTOSSIM was to provide debugging method for the TinyOSand its applications. However, it can simulate only the sen-sor applications ported to the i386 architecture. It was notprecise as much as AVRORA, and it cannot be used for othersensor operating systems and their applications.Yi et al. proposed SensorMaker [18] for scalable and fine-

grained simulation in wireless sensor networks. It providesan easy way to program communication protocols, and it hasbeen used for many researches including routing, clustering,mobile checkpointing, software updating protocols. How-ever, the SensorMaker does not provide component-basedimplementation, and the developers should understand theirwhole internal structures to implement some network pro-tocols.The GloMoSim [6] is a mobile network simulation library

developed at the UCLA. It was designed as a set of librarymodules and developed using PARSEC, a C-based parallelsimulation language. The GloMoSim is extensible, compos-able and suitable for wireless ad-hoc and sensor networks.

However, the protocol developers should understand the en-tire structures of the GloMoSim and should be familiar withPARSEC.

The OMNeT++ [13] is a discrete event simulation envi-ronment. It provides the basic machinery and tools to con-duct simulations. The OMNeT++ adopted the component-based architecture. In the OMNeT++, the network simu-lation environments, called as models, are assembled fromseveral reusable modules based on a NED (NEtwork De-scription) language. Therefore, protocol developers shouldbe familiar with the concept of models, components, andthe NED language to develop their protocols in the OM-NeT++. The OPNET [14] stands for OPtimized NetworkEngineering Tools. The OPNET Modeler is based on a se-ries of hierarchically-related editors. Among these editors,a process editor describes the behavior and functions of themodules. It uses a finite state machine to describe the proto-cols in detail. Each state of a process contains C/C++ codefor specific controlling. For this reason, protocol develop-ers should understand the process model to implement theirprotocols in OPNET. The QualNet [15] extends GloMoSimfor the commercial use on both industries and academies. Itprovides many kinds of verified built-in network protocolson the simulation package. However, the process for addingnew protocols to the QualNet is rather complex and containssome unnecessary procedures.

3. VPS: VIRTUAL PROTOCOL STACKIn this section, we present several requirements for net-

work simulations. Then, we describe the design and imple-mentation of the VPS in detail.

3.1 Requirements for Network SimulationsOn developing new network protocols, it is crucial to mea-

sure their performance. For this, we need to use a networksimulation package which provides various kinds of simu-lation aspects. In this paper, we focused on designing abetter structure for network simulators enabling easier man-agement of various network protocols. Several requirementsconsidered are as follows.

⋄ Minimizing the amount of source codes which are tobe analyzed for implementing a new network protocol

⋄ Minimizing complexity of internal structure of the sim-ulator engine

⋄ Providing independent development environment byremoving dependencies between network protocols andsimulator engine

⋄ Providing easier programming interface for networkprotocol developers

⋄ Providing fault-tolerance on simulator engine for un-stable network protocols

⋄ Supporting easier method for building a new networkprotocol

⋄ Supporting run-time network protocol plug-in facility


3.2 Design of VPSVPS stands for virtual protocol stack between protocols

and simulator engine. Similar to middlewares between ap-plications and operating systems, it provides an adaptationlayer between protocols and the engine. By using the VPS,simulator developers can easily implement, manage, and fixtheir software components. Also, protocol developers do notneed to understand whole structures of the simulator. Thedevelopers can easily implement various network protocolsby using the generalized interface provided by the VPS.

3.2.1 Overview

(b) VPS-based simulator

Previous Network Simulator

Simulator

Engine

Protocol Stack

(a) The previous network simulator

NWKMACPHYPHY MAC NWK

NWKPHY MAC

VPS based GloMoSim

Simulator

Engine

VPS(Virtual Protocol

Stack)

Plug-ins

NWKMACPHYPHY MAC NWK

NWKPHY MAC

VPS based CoSim

Simulator

Engine

VPS(Virtual Protocol

Stack)

Figure 1: Comparison of Existing Network Simula-tor and VPS-based Simulator

Figure 1 (a) shows a previous network simulator whichis composed of the simulator engine and several protocolstacks. In this structure, we need to rebuild the whole sim-ulator program codes even if we modify just one networkprotocol. However, in Figure 1 (b), the VPS -based simula-tor can manage multiple protocols via hot plug-in method.The network protocols can be implemented separately, andprotocol developers do not need to consider what kind ofnetwork simulator is to be used. In addition, developers canshare their network protocol modules with each other.

VPS PAL(Protocol Adaptation Layer)

VPS

Manager

PHY

Layer

Repository

VPS

PHY

Object

Session

ManagerSessionSessionMapping

Session

MAC

Layer

Repository

Network

Layer

Repository

GPSI

Cluster

Object

GPSI

Reactive

Object

VPS

NWK

Object

Hot Plug-in

Manager (Optional)

VPS SAL(Simulator Adaptation Layer)

GPSI

Object

VPS

MAC

Object

Global

Manager

Global

Infomation

Layer Configurator

Wrapper (optional)

LEACH

ID:1

Version: 0.0.9

Dependency ID

Layer: Network

Type: Cluster

FLOOD

ID:1

Version: 0.0.9

Dependency ID

Layer: Network

Type: Proactive

ETRI-SN

ID:: ETRI-I

Version: 0.0.9

Dependency ID

Layer: PHY

Type: default

802.15.4

ID:: CSMACA

Version: 0.0.9

Dependency ID

Layer: MAC

Type: default

AODV

ID:AODV

Version: 0.0.9

Dependency ID

Layer: Network

Type: Reactive

CSMA/CA

ID:: CSMACA

Version: 0.0.9

Dependency ID

Layer: MAC

Type: default

Session

MManagerMapaa pinng

Session

Global

Managger

Global

Infoff mationn

VPSVirtual

Protocol

Stack

Agent

Repository

GPSI

Reactive

Object

VPS

Agent

Object

Source

ID:1

Version: 0.0.9

Dependency ID

Layer: Network

Type: Proactive

Sink

ID:Sink

Version: 0.0.9

Dependency ID

Layer: Agent

Type: Sink

Radio

Manager

Wrapaa per (optional)

Radio Model

ID:Sink

Version: 0.0.9

Dependency ID

Layer: Radio

Type: default

Custom

Plug-ins

PPHHYY

Layer

Repositoryrr

VPS

PHY

Objb ect

MMAACC

Layer

Repositoryrr

NNeetwork

LLayer

Reppositoryrr

VPS

NWK

Objb ect

VPS

MAC

Objb ect

Layer Confiff gurator

Agent

Repositoryrr

VPS

Agent

Objb ect

Radio

Manager

Component

Configuration Part Session

Management Part

Wrapper Part

Figure 2: Internal Structure of VPS

Figure 2 shows the internal structure of the VPS in detail.The VPS SAL is used to connect to the target simulator

Table 1: SAL Interface

SAL Interface Parameter

i32 vpsi_init VPSI_CONF *

i32 vpsi_release void

i32 vpsi_enum_ptcinfo ENUM_PTC_INFO *

i32 vpsi_get_ptcinfo u32 ptcID,PTC_INFO *

i32 vpsi_set_ptc u32 sessionID,u32 ptcID

i32 vpsi_insert_ptc char *path

i32 vpsi_remove_ptc u32 ptcID

u32 vpsi_create_session Node *

i32 vpsi_destroy_session u32 sessionID

Session * vpsi_get_session u32 sessionID

i32 vpsi_send_packet u32 sessionID,Packet *

i32 vpsi_recv_packet u32 sessionID,Packet *

i32 vpsi_handle_event u32 sessionID,Event *

engine. The other components are VPS Manager, Com-ponent Management, Session Management, Wrapper, VPSPAL, and several plugin network protocol modules. We de-scribe each of them in the following subsections.

3.2.2 VPS SALSAL is a simulator adaptation layer which provides adap-

tation for various simulation packages. This is much similarto the concept of VFS ’s interface and Java VM. By usingSAL, VPS can be easily ported to any programmable net-work simulators. In this study, we ported SAL to the ex-isting wireless sensor network simulators and we will port itto other simulators in our future work. Table 1 shows someprimitive APIs defined in SAL interface.

3.2.3 Component Management PartThe component management part manages protocols as

dynamically loadable components. This part is designed toallow easy addition and removal of customer protocols with-out recompilation of simulators using it. By doing so, it al-lows simulators to easily and automatically take advantageof the newest protocols.

3.2.4 Session Management PartFigure 3(a) shows the session management part. For bet-

ter scalable network simulations, it is crucial to minimizecomputing and memory resource usage. In VPS, we decidedto share protocols for all nodes to reduce memory usage,and we allocated session1 information for each node to re-duce computing resource usage. For example, if every nodein a network use the same protocol, then the protocol willbe shared for all nodes, and session information will be pro-portional to the number of nodes.

3.2.5 Wrapper PartIn general, custom protocols (or, in other words, third-

party protocols) are not reliable because of their error-pronecharacteristic. For better reliability, as shown Figure 3(b),we use the Wrapper layer which verifies arguments, returnvalues, and accessing addresses on the common data struc-

1In this paper, the session represents a data structure of anode’s information.


Node1 Node2

NWK

MAC

PHY

Virtual Protocol Stack

Mapping

SessionMapping

Session

Mapping

Session


Wrapper

Object TrackerMemory Monitor

VPS PAL

Protocol.pluginProtocol.plugin

(b) Wrapper Part(a) Session Management Part

Node3

VPS SAL

apaa

Ses

Figure 3: Session Management and Wrapper Partin VPS

Table 2: PAL InterfacePAL Interface Parameter

u32 plugin_init COMPONENT_INFO *

u32 plugin_end void

u32 protocol_open Session *

u32 protocol_close Session *

u32 protocol_handle_event Session *, Event *

u32 protocol_handle_packet Session *, Packet *

tures. It also can check and securely update the protocolcomponents.

3.2.6 VPS PALPAL stands for Protocol Adaptation Layer. It provides

generalized interface between protocol components and theVPS. In Figure 2, MAC protocols (802.15.4 and CSMA/CA),network protocols (AODV, FLOOD, and LEACH), and thedefinition of the physical components (ETRI-SSN) are con-nected to the PAL interface. The PAL consists of two typesof interfaces, common and specific interfaces. The com-mon interface provides the essential functions to manage andcommunicate between protocols and the VPS. Table 2 showssome primitive APIs defined in PAL interface.Based on these functions, the VPS can manage each pro-

tocol component, and the components can transmit to andreceive packets from the simulator engine. PAL also needsto provide the specific interface for each categorized charac-teristic. By using the PAL, engineers can develop variousprotocols without knowing simulators’ internal structures.

3.2.7 Inter-connection between VPS and SimulatorFigure 4 shows how to inter-connecting the VPS and the

target simulator. It composes of 3 phases. The Init phase isstarted when the simulator calls the function vpsi_init().The component manager scans protocols, and performs plug-in for the scanned protocols. Then the simulator calls thevpsi_create_session() to create sessions for all nodes. Af-ter that, the VPS sets up connection between the simu-lator engine and the nodes in the Setup phase. Finally,the simulator engine can perform network simulation by

calling the vpsi_send_packet(), vpsi_recv_packet() orvpsi_handle_event() in the Handling phase.

4. IMPLEMENTATIONWe have implemented the VPS on the existing sensor

network simulators such as GloMoSim 1.2.3 (Windows ver-sion)[6], and CoSim 2.

We used C++ programming language to implement theVPS because most of the existing simulators are now us-ing it. We used Microsoft Visual Studio 2005 as the mainprogramming environment. Win32 API and MFC librariesare used to implement GUI and visualization of the wirelesssensor networks.

Figure 5 shows the overall structures of the VPS and theCoSim which were implemented in this study. The VPS isbased on the Win32 subsystems, and each component is im-plemented in the DLL file format to link and load them dy-namically. Also, each protocol component follows the DLLformat to provide hot plug-in features.

Win32 Subsystem

MFC Library

Porting Layer

(basenvlib.dll)

CoSim (Cosim.exe)

Environment

Manager

(nvenviron.dll)

Node Manager

(nvwsn.dll)

Event Scheduler

(nvexec.dll)

CoSim


(vps.dll)

Plugin Module

(plugin.dll)

VPS

Figure 5: Overall Structures of VPS and CoSim

In general, the amount of time consumed for simulation isproportional to the number of nodes and the traffic volumesof the networks. To effectively minimize simulation time,some multicore-based powerful machines can be used to ex-ploit parallelism of the network simulations. To increase thebenefit of parallel execution, In Fig. 5, the event schedulersupports both the event-driven and the multi-threaded op-erations based on the threads pool structure.

Figure 6 shows the snapshot of the network simulatorwhich adopted the VPS as the main interface for networkprotocols. In this figure, the fields A and B represent sen-sor nodes and the target 2-dimensional ground, respectively.The fields C, D, E, F, G, and H show interface for config-uring options used in network simulations.

5. PERFORMANCE EVALUATIONIn this section, we present performance of the VPS in sev-

eral aspects. For this, we measured execution time, memoryusage, and the overall performance by using CoSim in manydifferent conditions.

Table 3 represents several parameters used in the simula-tion. We assumed the size of sensing field as 500m × 500m2-dimensional ground, and the sink node is located at thecenter of the field. The distribution method of sensor nodesis done by C ++ standard pseudo-random generation func-tions, srand() and rand(). The number of nodes is 500, andeach node transmits its own data packet to the sink node atevery 3 seconds.

2CoSim was developed by our research team.


VPS SAL

LEACH.DL

L

Plugin_Init

Plugin_End

...

FLOOD.DL

L

Plugin_Init

Plugin_End

...

AODV.DLL

Plugin_Init

Plugin_End

...

GPSI

Network

Proactive

Object

GPSI

Network

Proactive

Object

VPSI

Network

Proactive

Object

VPS PAL

Wrapper

3. plugin_init

Session

Manager

6. create

session

SessionSessionSession

Layer

Repository

4. create

protocol object

VPS Manager

Layer Configurator

2. scan protocol

VPS SAL

LEACH.DL

L

Plugin_Init

Plugin_End

...

FLOOD.DL

L

Plugin_Init

Plugin_End

...

AODV.DLL

Plugin_Init

Plugin_End

...

GPSI

Network

Proactive

Object

GPSI

Network

Proactive

Object

VPSI

Network

Proactive

Object

VPS PAL

Wrapper


Layer

Repository

VPS Manager

Layer Configurator

2. protocol_handle_packet

protocol_handle_event

Session

Manager

LEACH.DL

L

Plugin_Init

Plugin_End

...

FLOOD.DL

L

Plugin_Init

Plugin_End

...

AODV.DLL

Plugin_Init

Plugin_End

...

GPSI

Network

Proactive

Object

GPSI

Network

Proactive

Object

VPSI

Network

Proactive

Object

VPS PAL

Wrapper

3.connect

Session

Manager


Layer

Repository

VPS Manager

1.vpsi_enum_info (&layerinfo )

vpsi_enum_ptcinfo (&ptcinfo )

VPS SAL

Layer Configurator

(a) Init phase (b) Setup phase (c) Handling phase

4. protocol_open

2. vpsi_set_protocol(sID, AODV)1. vpsi_init 5. vpsi_create_session (&node) 1. vpsi_send_packet(sID, packet)

vpsi_recv_packet(sID, packet)

vpsi_handle_event(sID, event)

Figure 4: Inter-connection between VPS and Simulator Engine

Figure 6: Screenshot of Prototype Implementation

Figure 7 shows the impact of VPS on the execution timeof the network simulator. Original CoSim denotes the simu-lator without any VPS layer, and the others show the resultswhen the Wrapper is disabled or enabled on the VPS -basedCoSim. This result shows that the overhead of VPS layerincluding Wrapper is only 0.97 percent of the total executiontime.Table 4 represents the expected time for 4, 000 rounds of

simulation according to the number of sensor nodes. The re-sults show that the execution time increases sub-exponentially

Table 3: Simulation Environment and Parametersused in this paper

Parameter Description

Sensing field 500m × 500mPosition of sink node (250,250)Distribution of sensor nodes Random distributionRadio transmission range 80mMobility of sensor nodes Random (Max. 2m/s)Number of sensor nodes 500

ProtocolsNetwork: AODVMAC: CSMA/CAPHY: Nano-24 (CC2420)

by the number of sensor nodes. This is one of the charac-teristics of the network simulator. This result shows thatthe VPS has no sub-exponential order of magnitude on theexecution overhead. In other words, the VPS still has rea-sonable overhead for simulating large-scale sensor networkssuch as 2, 500 nodes.

6. CONCLUSIONS AND FUTURE WORKIn recent years, lots of simulation packages have been de-

veloped for simulating wireless networks. However, each ofthem has some drawbacks such as difficulties in program-ming, significant time consumption on building network pro-tocols, hard to understand simulator engine, and their reli-ability issues. To alleviate such problems, we presented theVirtual Protocol Stack (VPS) for multiple network simula-


Table 4: Execution Time of Simulatimg 4, 000 Rounds According to the Number of Sensor NodesNumber of

Naive CoSimVPS -based CoSim VPS -based CoSim

sensor nodes (w/o Wrapper & Component Mgmt.) (w/ Wrapper & Component Mgmt.)

500 15.00 s 15.20 s 16.10 s1, 000 93.46 s 94.10 s 94.70 s1, 500 248.86 s 254.59 s 259.20 s2, 000 509.95 s 514.57 s 520.87 s2, 500 829.36 s 836.00 s 847.01 s

Original CoSim VPS-based CoSim

(Wrapper Disabled)

VPS-based CoSim

(Wrapper Enabled)

Time (s)

Figure 7: Impact of VPS on Execution Times

tors in wireless networks. The VPS provides abstraction ofmultiple simulator engines into the generalized programminginterface. By using the VPS, developers can just programnetwork protocols according to VPS, and then the protocolscan be used for multiple network simulators. By doing so,developers can share their network protocol modules witheach other. This will provide extra benefit on the perfor-mance evaluation and quality control of the network proto-cols being developed.We are currently extending our work to port the VPS

to several other network simulators such as ns-2, ns-3, andOMNeT++. In addition, a wizard-based development envi-ronment for protocol developers will be possible to provideby improving design of the protocol adaptation layer (PAL).

7. REFERENCES[1] Akyildiz, I., Su, W., Sankarasubramaniam, Y.,

and Cayirci, E. A survey on sensor networks. IEEECommunications Magazine (Aug. 2002), 102–114.

[2] Avrora. http://compilers.cs.ucla.edu/avrora, website.

[3] Chen, G., Branch, J., Pflug, M. J., Zhu, L., andSzymanski, B. Sense: A sensor network simulator. InAdvances in Pervasive Computing and Networking(2004).

[4] Crossbow. http://www.xbow.com/, website.

[5] Girod, L., Elson, J., Cerpa, A., Stathopoulos,T., Ramanathan, N., and Estrin, D. Emstar: asoftware environment for developing and deployingwireless sensor networks. In USENIX TechnicalConference (2004).

[6] GloMoSim. http://pcl.cs.ucla.edu/projects/glomosim,website.

[7] Hac, A. Wireless Sensor Network Designs. JohnWiley & Sons, 2003, pp. 101–140.

[8] Hirafuji, M., Fukatsu, T., Hu, H., Kiura, T.,Laurenson, M., He, D., Yamakawa, A., Imada,A., and Ninomiya, S. Advanced sensor-network withfield monitoring servers and metbroker. In CIGRInternational Conference (2004).

[9] Levis, P., Lee, N., Welsh, M., and Culler, D.Tossim: Accurate and scalable simulation of entiretinyos applications. In First ACM Conference onEmbedded Networked Sensor Systems (2003).

[10] Levis, P., Madden, S., Gay, D., Polastre, J.,Szewczyk, R., Woo, A., Brewer, E., andCuller, D. The emergence of networkingabstractions and techniques in TinyOS. In FirstUSENIX/ACM Symposium on Networked SystemsDesign and Implementation (NSDI’04) (2004).

[11] Lundquist, J. D., Cayan, D. R., and Dettinger,M. D. Meteorology and hydrology in yosemitenational park: A sensor network application. LectureNotes in Computer Science 2634 (2003), 518–528.

[12] ns 2. http://www.isi.edu/nsnam/ns/, website.

[13] OMNet++. http://www.omnetpp.org, website.

[14] OPNET. http://www.opnet.com, website.

[15] QualNet.http://www.scalable-networks.com/products, website.

[16] Srivastava, M., Muntz, R., and Potkonjak, M.Smart kindergarten: Sensor-based wireless networksfor smart developmental problem-solvingenvironments. In The 7th Annual InternationalConference on Mobile Computing and Networking(2001).

[17] Titzer, B., Lee, D., and Palsberg, J. Avrora:Scalable sensor network simulation with precisetiming. In Fourth International Conference onInformation Processing in Sensor Networks (2005).

[18] Yi, S., Lee, S., Cho, Y., and Hong, J.SensorMaker: A wireless sensor network simulator forscalable and fine-grained instrumentation. LectureNotes in Computer Science 5072 (2008), 800–810.


About the authors:

Yookun Cho (M’91) received the B.E. degree from Seoul National University, Seoul, Korea, in 1971 and the Ph.D. degree in computer science from the University of Minnesota, Minneapolis, in 1978.

Since 1979, he has been with the School of Computer Science and Engineering, Seoul National University, where he is currently a Professor. In 1985, he was a Visiting Assistant Professor with the University of Minnesota, and from 2001 to 2002, he was the President of the Korea Information Science Society. He also served as the honorary conference chair for ACM SAC 2007. His research interests include operating systems, algorithms, system security, and fault-tolerant computing systems.

Jinman Jung received his B.S. degree in Computer Science from Seoul National University, Seoul, Korea, in 2008. He is currently a Ph.D. candidate of School of Computer Science and Engineering, Seoul National University, Seoul, Korea. His current research interests include operating systems, embedded systems and wireless networks.


Fraud Detection in Reputation Systems in e-Markets usingLogistic Regression and Stepwise Optimization

Rafael MaranzatoUniverso Online Inc.

Dept. of R & DSão Paulo, SP, Brazil

[email protected]

Adriano PereiraFederal Center for

Technological Education ofMinas Gerais (CEFET-MG)Dept. of Computer ScienceBelo Horizonte, MG, Brazil

[email protected]

Marden NeubertUniverso Online Inc.

Dept. of R & DSão Paulo, SP, Brazil

[email protected]

Alair Pereira do LagoUniv. of São Paulo - USP

Dept. de ComputaçãoSão Paulo, SP, [email protected]

ABSTRACTReputation is the opinion of the public toward a person, agroup of people, or an organization. Reputation systems areparticularly important in e-markets, where they help buyersto decide whether to purchase a product or not. Since ahigher reputation means more profit, some users try to de-ceive such systems to increase their reputation. E-marketsshould protect their reputation systems from attacks in or-der to maintain a sound environment. This work addressesthe task of finding attempts to deceive reputation systemsin e-markets. Our goal is to generate a list of users (sellers)ranked by the probability of fraud. Firstly we describe char-acteristics related to transactions that may indicate fraudsevidence and they are expanded to the sellers. We describeresults of a simple approach that ranks sellers by countingcharacteristics of fraud. Then we incorporate characteristicsthat cannot be used by the counting approach, and we ap-ply logistic regression to both, improved and not improved.We use real data from a large Brazilian e-market to trainand evaluate our methods and the improved set with lo-gistic regression performs better, specially when we applystepwise optimization. We validate our results with special-ists of fraud detection in this market place. In the end, weincrease by 112% the number of identified fraudsters againstthe reputation system. In terms of ranking, we reach 93%of average precision after specialists’ review in the list thatuses Logistic Regression and Stepwise optimization. We alsodetect 55% of fraudsters with a precision of 100%.

Categories and Subject DescriptorsK.4.4 [Computers and Society]: Electronic Commerce—e-markets; H.3.5 [Online Information Services]: Web-based services—online reputation systems

General TermsExperimentation, Management, Security

Keywordse-markets, reputation systems, trust management, fraud ev-idence, fraud detection, logistic regression

1. INTRODUCTIONIn the past few years, there has been a huge developmentof online commercial activity enabled by the Internet andWorld Wide Web (WWW). Electronic marketplaces, or juste-markets, such as Amazon1 and eBay2, have reached greatpopularity and revenue, emerging as very relevant model inthe Business-to-Consumer (B2C) and Consumer-to-Consu-mer (C2C) e-commerce scenario. Amazon revenues reachedUS$ 19.17 billion in 2008, including a fast-growing incomefrom selling Web Services to other companies. At eBay, salesreached US$15.7 billion in the second quarter of the year,with 84.5 million active users [5].

An e-market can be defined as a multi-party e-commerceplatform intermediating buyers and sellers [13]. E-marketsare therefore information systems intended to provide theirusers with online services that will facilitate information ex-change and transactions. The development of online auc-tion sites and other forms of electronic markets has createda new kind of online community, where people trade with

1http://www.amazon.com2http://www.ebay.com


each other in a potentially large scale. In this scenario, rep-utation plays an important role.

Reputation is the opinion (more technically, a social evalua-tion) of the public toward a person, a group of people, or anorganization. Reputation can also be defined as the amountof trust inspired by a particular person or company in aspecific domain of interest [20]. The widespread adoption ofe-markets has highlighted several problems regarding trustand deception that must be addressed to keep these envi-ronments sound [6].

Major marketplace providers try to tackle the problem byintroducing simple reputation mechanisms [30], which givean indication of how trustworthy a user is, based on his/herperformance in previous transactions.

In this work, we focus on frauds against reputation systems.From a characteristic3 extraction based on expert knowl-edge [29], we use a set of characteristics for fraud detectionin e-markets that was recently found [17]. We also describea simple approach for identifying frauds by characteristicscounting. Next, we enhance the characteristics set in thiswork and adopt a Logistic Regression Model that can dealwith this set. We also apply a technique of optimizationin the model generated by Logistic Regression. These ap-proaches analyze characteristics of both the user and thenegotiation processes that happen in the marketplace. Wecompare them by using actual data from a large Braziliane-market and then checking the results with specialists tovalidate the outcomes. We found out that the performanceof both methods is very promising, and they are useful fordiscovering a large number of fraudsters that have not beenidentified before.

The remainder of this article is organized as follows. Sec-tion 2 discusses related work. Section 3 briefly describes theTodaOferta marketplace, used in our study. In Section 4 weexplain the characteristic extraction procedure for data usedin this work. Section 5 shows the characteristic counting ap-proach with some results. Section 6 presents a new approachthat applies Logistic Regression with our case study and re-sults, including Stepwise optimization. Finally, Section 7shows our conclusions.

2. RELATED WORKElectronic markets are getting more popular each day. Oneof the most common e-markets application is online auc-tions, which have been extensively studied lately. Severalstudies have focused on reputation systems and trust in on-line auctions. Some of them have analyzed the importance ofreputation in auction outputs, mainly in final prices. Ba andPavlou [2] investigate the effectiveness of reputation systemsand how reputation correlates to auction results. They con-clude that reputation plays an important role in trust andleads to higher ending prices.

Klos et. al [12] analyze the effect of trust and reputation over

3We use the term characteristic instead of feature, which isthe term used in some references, because we consider theterm characteristic more appropriated in statistical context

the profits obtained by intermediaries in electronic commer-cial connections. Different trust and distrust propagationschemes in e-commerce negotiations studied and evaluatedby Guha et. al [8]. Resnick et al. [26] show that sellers withhigh reputation are more capable of selling their products,but the gains in final prices are reduced. Using a controlledexperiment, Resnick et al. [27] study more accurately theimpact of reputation on the auction outputs. The resultsshow that, in general, bidders pay higher prices to sellerswith higher reputation.

Several works investigate reputation systems and how theyinduce cooperative behavior in strategic settings. Dellaro-cas [3] has done a thorough review on this topic. While pro-viding incentive to good behavior, reputation systems mayalso help eliciting deceptive behavior. In fact, some fraud-related studies rely on reputation information as a source ofevidence of fraud [7].

This subject has long interested economists once sellers withgood reputation can increase their prices because buyers payfor such reputation [11]. In the real world, reputation is builtwith time after some transactions, and sellers build a conceptabout themselves that becomes a reference to consumers.This historical record is used by future buyers when makinga new transaction [25].

Reputation mechanisms are based on virtual opinions, givenby people who generally do not know each other personally.Therefore electronic trust is more difficult to be establishedif compared to the real world. Taking a broad view, in thesemarketplaces a buyer’s reputation represents the probabilityof payment and a seller’s reputation represents the estimatedprobability of delivering the advertised item (product thathas been bought) after the payment [11]. These probabilitiesare related to trust [21].

Resnick et al. [25] say that these reputation systems havethree main problems: (i) buyers have little motivation toprovide feedback to sellers; (ii) it is difficult to elicit negativefeedback because it is common that people negotiate andsolve problems before filling the evaluation in the system;(iii) it is difficult to assure honest reports. Since it is veryeasy to register in such systems, it is very easy to create afalse identity that can be used to trade with other users anddistort the reputation system.

As the feedback system is the basis of reputation in thesemarketplaces and gives information that is used before themoment the transaction happens, it is easy for fraudstersto make artificial transactions so that they can have a goodreputation score. Basically, this artificial score can be usedto deceive buyers who pay and do not receive the right prod-uct or it can be used to sell more goods because the sellerwill have favorable reputation [25]. Considering this situa-tion, marketplaces should have tools to identify fraudsters,in order to protect honest users. Users who interact withfraudsters may have their reputation affected too [21]. Gav-ish and Tucci [6] show that buyers who are victims of fraudswill decrease their volume of transactions, which it is notprofitable to the marketplaces.


One of the pioneers on empirical and statistical approachon bankruptcy prediction, Ohlson [22] was probably thefirst academic researcher to apply Logistic Regression in thefield. In his work, not only was he able to detect what wasthe most important evidence for bankruptcy prediction, butalso find fraud an/or error evidence since he observed that“the reports of the misclassified bankrupt firms seem to lackany warning signals of impending bankruptcy.” Since then,many other works have applied the method in fraud detec-tion [14, 15, 16, 28]. In particular, Viaene et al. appliedthe method, in a pool of many other methods, for automo-bile insurance fraud data and concluded that “noteworthyis the good overall performance of the relatively simple andefficient techniques such as logit...” (Logistic Regression).

3. MARKETPLACE DESCRIPTIONThis section describes TodaOferta1, which is a marketplacedeveloped by the largest Latin America Internet ServiceProvider, named Universo Online (UOL)2. It also definessome basic concepts related to the marketplace.

TodaOferta [23] is a website for buying and selling productsand services on the Web. Table 1 shows a short summaryof the TodaOferta dataset. It embeds a significant sampleof users, listings, and negotiations. Due to a confidentialityagreement, the quantitative information of this dataset cannot be presented.

Coverage (time) Jun/2007 to Jul/2008

#categories (top-level) 32

#sub-categories 2,189

Average listings per user 4.63

Average listings per seller 42.48

Negotiation options Fixed Price and Auction

Table 1: TodaOferta Dataset - Summary

Users correspond to buyers and sellers interested in makingtransactions in the marketplace. Listings are created by sell-ers to advertise products or services at a fixed-price or in anauction. When a buyer is interested in a listing he/she startsa negotiation. With a fixed-price listing, the negotiation au-tomatically starts a transaction, indicating that buyer andseller should transact the good at the advertised price. Withan auction, the winning bid will become a transaction whenthe auction finishes. Unlike eBay, where auctions representalmost 50% of all transactions [9], in TodaOferta auctionsaccount for less than 2% of all transactions, since the vastmajority of listings are fixed-price.

There are 32 top-level categories in TodaOferta, which in-clude 2,189 sub-categories providing a variety of distinctproducts and services, from collectibles to electronic and ve-hicles. The current top sales sub-categories are cell phones,MP3 players and pen drives.

The TodaOferta marketplace employs a quite simple reputa-tion mechanism. After each negotiation, buyers and sellers

1http://www.todaoferta.com.br2http://www.uol.com.br

qualify each other with a rate of value 1 (positive), 0 (neu-tral), or -1 (negative). User’s reputation is defined as thesum of all qualifications received by him/her. Feedbacksfrom a same user are considered only once when computingthe reputation score. Reputation systems are useful to com-municate trust in electronic commerce applications. As To-daOferta does not charge sellers after transactions, it is quitesimple to generate artificial transactions just to improve thispunctuation. However, TodaOferta provides other informa-tion about sellers and buyers that can be used to identifytrustful and distrustful users as well (e.g., time since theuser is registered, comments left by users who negotiatedwith him/her).

Basically, sellers try to cheat the reputation system withtwo different purposes. The first one is to improve their salesand, consequently, their profits because his or her reputationin the marketplace seems better than it actually is. Thesecond purpose is to exploit the good reputation that he orshe has to commit other types of fraud, in general relatedto finance damage to buyers.

Another relevant feature of TodaOferta is the integrationwith a payment system which includes an escrow mecha-nism. This escrow system is named PagSeguro4 and it isvery similar to PayPal5. If a seller uses the payment system,he can configure his listings so that he will receive paymentsthrough it. However, with the escrow feature, the seller willreceive the payment only after the buyer has received theproduct or after 15 days. So, if a seller has enabled the pay-ment system, he is more likely to be trustworthy, since heallows the buyer to block the money if the product was notdelivered properly.

4. CHARACTERISTIC EXTRACTIONIn this section we describe the procedures related to charac-teristic extraction that is the first part of the methodologydescribed by Maranzato [19].

Given the importance of reputation systems, we decided tofocus our experiments on identifying and evaluating charac-teristics that can be indicative of fraud in such systems. Wepresent here a method for extracting fraud evidence fromtransactions and the reputation systems.

First we gathered a real dataset from TodaOferta (see Ta-ble 1) and a list of all users that were blocked for infringingthe rules of the marketplace. Each item of this list containsa label describing the reason why the user was blocked. Asour goal is to identify users that defraud the reputation sys-tem, we define a set FRS that contains the users blockedspecifically for this reason and FRST the transaction withthis fraud evidence. We also define a set AFr containing allusers blocked for any kind of fraud and AFrT the transac-tion. We consider the remaining users in the system as “notfraud” and put them in a set NFr and NFrT the transaction

4http://www.pagseguro.com.br5http://www.paypal.com


with no fraud evidence. Considering this, we can represent:

FRS ⊂ AFrAFr ∪ NFr = All Users.

One user is considered fraudulent if he/she participates in atleast one fraudulent transaction, as a buyer or a seller. Thus,the transactions in which a given user is involved determinewhich set the user will be in. We organize the transactionsin sets analogous to the ones defined for users. A user isin FRS if he/she is the buyer or the seller in at least onetransaction in FRST . If this is not the case, but the useris involved in at least one transaction in AFrT , he/she is inAFr . Users in NFr are those who only have transactions inNFrT .

With this defined set, we start the actives related to gather-ing information to the process of characteristic extraction.Then we interviewed specialists in fraud detection in thismarketplace to understand their procedures and to identifywhich evidence we should consider when looking for usersthat were trying to cheat the reputation system. Most oftheir work is about reaction to denunciations. The special-ists listed a set of characteristics that they analyzed to iden-tify fraudulent transactions but also pointed out that allthese characteristics can also occur in honest transactions.During the interviews we suggested new characteristics thatcould be used in fraud detection and we included them inour tests – some of them were not useful. We also use our ex-perience to try some characteristics. This kind of approachis defined by Duda and Hart [4] as prior knowledge, thatis one of the sub-problems of pattern recognition. We alsofaced on some other sub-problems like feature extraction,overfitting and noise, for example.

It important to emphasize that we decided to consider onlytransactions with positive feedbacks from buyers, since thepositive feedback is the main goal of frauds to the reputationsystem and that is the type of feedback which affects thepunctuation of the feedback system. We plan to considerother types of feedback in a future work.

After analyzing the dataset, the mechanics of this market-place and the information collected during the interviews,we considered five main events to be taken into account ina fraud detection process:

1. Seller’s registration;2. Buyer’s registration;3. Listing publication;4. Transaction;5. Feedback from Buyer to Seller6.

A timeline of these events can be seen in Figure 1. As youcan see, we use not only the transaction information but allinteractions between buyer and seller in the marketplace.

Another important concept is that in electronic market-places, transactions between users can be represented as a

6In this work, we are not considering feedbacks from sellersbecause they do not benefit sellers.

Figure 2: Graph of negotiations

graph (see Figure 2), with a node for each user and an edgefor one (or more) transactions between two users.

Using connection information available about the buyer andthe seller and considering the events previously describedwe have found twelve characteristics the are indicative offrauds. We started from two connection attributes of eachevent: workstation identifier7 and IP address. Then we tookthe three events related to the buyer (Buyer’s registration,Transaction and Buyer’s feedback) and combined with thetwo events related to the seller (Seller’s registration and List-ing publication), obtaining six combinations to be verified.We show these characteristics in Table 2, presenting an ex-planation of why each one can be considered a good char-acteristic of fraud and a warning about occurrences in le-gitimate transactions. As an example, characteristic SWLBis detected when we observe the same workstation identifierwhen the seller created the listing and when the buyer reg-istered. Similar comparison is done for IP address in SILB.

We also extracted five other characteristics that can not bedescribed by Boolean values like the ones presented in Ta-ble 2, which we list below:

• Quick Feedbacks from Buyers, in less than N hoursafter transaction (QFB);

• Small Rate of Visits per Transactions, smaller than N(SRVT );

• Short Interval for Transactions in the same Listing dur-ing N hours (SITL);

• Same domain in e-mails from buyers in the same listingconsidering N transactions (UDTB);

• E-mails with the same domain between sellers and buy-ers considering N transactions (SDBS);

In all the situations listed above, we can convert these char-acteristics into Boolean values by establishing a thresholdfor the value of N in each case.

These characteristics are named positive characteristics be-cause they indicate evidence of fraud. On the other hand, we

7Due to confidentiality, we can not give more details abouthow this identifier is determined.


Figure 1: Timeline of Events

Characteristic Suspicion Warning Code Situations

Same workstationidentifier

Seller and buyerused the samecomputer

They could haveused a publiccomputer

SWLB Listing and BuyerSWSB Seller and BuyerSWLT Listing and TransactionSWLF Listing and FeedbackSWSF Seller and FeedbackSWST Seller and Transaction

Same IP AddressSeller and buyerused the samecomputer

They could haveused a proxy or apublic computer

SILB Listing and BuyerSISB Seller and BuyerSILT Listing and TransactionSILF Listing and FeedbackSISF Seller and FeedbackSIST Seller and Transaction

Table 2: List of Characteristics

found two characteristics that decrease the chance of fraud.We name than as negative characteristics and they are:

• Seller Recognition (REC1). This recognition can bedone by editorial analyses from the marketplace, forexample;

• Transaction paid through integrated escrowsystem (TCPS), that is PagSeguro;

All positive and negative characteristics are listed in Table 3.

Our next step is to expand this evidence from transactionsand events to the sellers because the seller is the target offraud detection. As we mentioned before, specialists con-sider that a user is fraudulent if he/she participates in atleast one fraudulent transaction, as a seller or a buyer. Withthis approach that uses just one positive characteristic wereach 96.8% of sellers in FRS . Besides, we also reach 78.5%of users in AFr − FRS . Unfortunately, we also hit 54.3%of user that were not pointed as fraudsters (users in NFr),which shows us that only one fraud characteristic (one char-acteristic among all positive seventeen we have obtained) isa weak information to give certainty about a fraud behavior.

Consider a characteristics and let F be the set of all trans-actions that have this characteristic. We count how manytransactions in F are also in FRST and in NFrT , and com-pute their respective probabilities:

p1 = |F ∩ FRST |/|FRST |p2 = |F ∩ NFrT |/|NFrT |.

In order to evaluate the discriminating power of this char-acteristic, we compute the odds ratio between the classesFRST and NFrT . The odds ratio is a measure that com-pares the probability of an event occurring in one group withthe probability of it occurring in another group. If the prob-abilities of the event occurring in each of the groups are p1

and p2, then the odds ratio is:

p1/(1 − p1)

p2/(1 − p2)=

p1(1 − p2)

p2(1 − p1).

In this work, we only consider positive characteristics withodds ratio at least 3. For negative ones, we just invert theratio and we use the same threshold. This simple approach


Characteristic Description Type

QFB Quick Feedbacks from Buyers, in less than N hours after transaction Positive

REC1 Seller Recognition Negative

SDBS E-mails with the same domain between sellers and buyers considering N transactions Positive

SILB Same IP Address – Listing and Buyer Positive

SILF Same IP Address – Listing and Feedback Positive

SILT Same IP Address – Listing and Transaction Positive

SISB Same IP Address – Seller and Buyer Positive

SISF Same IP Address – Seller and Feedback Positive

SIST Same IP Address – Seller and Transaction Positive

SITL Short Interval for Transactions in the same Listing during N hours Positive

SRVT Small Rate of Visits per Transactions, smaller than N Positive

SWLB Same workstation identifier – Listing and Buyer Positive

SWLF Same workstation identifier – Listing and Feedback Positive

SWLT Same workstation identifier – Listing and Transaction Positive

SWSB Same workstation identifier – Seller and Buyer Positive

SWSF Same workstation identifier – Seller and Feedback Positive

SWST Same workstation identifier – Seller and Transaction Positive

TCPS Transaction paid through integrated escrow system Negative

UDTB Same domain in e-mails from buyers in the same listing considering N transactions Positive

Table 3: Complete list of Characteristics

is useful to to validate the characteristics and we introduce itin the next section, since it is based on counting the numberof positive characteristics of a transaction.

5. CHARACTERISTICS COUNTINGThis section explains a characteristic counting approach tovalidate characteristics in a fraud detection process. We cantake the positive characteristics introduced in Section 4 andcheck if that the presence of only one of them is enough todetermine that a transaction is fraudulent.

Now we can find out how a minimal number of characteris-tics k can be used as a strong evidence of fraud. First werank the characteristics in decreasing order of their corre-sponding odds ratios. Iterating k up to the 17 character-istics, we compute the set K of sellers that participate intransactions with at least k characteristics. These charac-teristics are the positive ones listed in Table 3 and they arenatural candidates for investigation.

Using this simply composed characteristic as a classifica-tion/ranking criteria, we apply the usual measures of pre-cision, recall and F-measure, used for classifiers. The per-centage of sellers in FRS that are in K is the recall. Thepercentage of sellers in K that are in FRS is the precision.The harmonic mean of recall and precision is the F-measure,which evaluates the usual trade off between precision andrecall, providing a better measure to comparison. These re-sults are in Table 4 and they will be compared to the LogisticRegression Model approach next in Section 6.

We saw that the best value of measure occurs when we reach60.3% of sellers, with a precision of only 33.0%. In terms ofa global metric for this ranking, we have reached an average

k Recall Precision F-measure

17 1.3% 80.0% 0.026

16 2.7% 66.7% 0.051

15 6.7% 66.7% 0.121

14 10.3% 59.6% 0.176

13 15.3% 53.5% 0.238

12 19.0% 49.1% 0.274

11 24.0% 49.0% 0.322

10 30.0% 45.9% 0.363

9 33.7% 42.6% 0.376

8 41.0% 38.7% 0.398

7 47.0% 35.2% 0.402

6 52.0% 34.0% 0.411

5 60.3% 33.0% 0.427

4 70.7% 28.4% 0.405

3 79.0% 22.3% 0.348

2 89.3% 18.0% 0.300

1 100.0% 12.4% 0.220

Table 4: Sellers with at least k characteristics


precision8 of 38.9%.

6. LOGISTIC REGRESSIONThis section presents the Logistic Regression Model and itsapplication. First we describe some concepts about it (Sec-tion 6.1) and then we describe our case study applying it toactual data from TodaOferta to rank all sellers consideringtheir estimated fraud probability (Section 6.2). It is im-portant to say that we consider this problem of identifyingfraudsters as a ranking problem instead of a classificationproblem that typically classifies the results in some prede-fined sets. Our intention is to generate a list that shows allsellers ordered by the percentage of one seller to be consid-ered fraudster.

6.1 DefinitionOne of the greatest advantage of the Logistic Regressionmethod over typical classification methods is that it providesa ranking ordering on the classified data, since it tries topredict the estimated fraud probability. Another importantreason why we used this method and not others, is the factthat it is a quite natural extension to the odds ratio we havecomputed in the characteristics extraction analysis reportedpreviously in Section 4. Applying to our data, the estimatedprobability of fraud (p) is represented by:

p =1

1 + e−z

where, for constants βi and variables xi, with 1 ≤ i ≤ 17,we have:

z = β0 + β1x1 + · · · + β17x17.

In fact, we have 17 variables (the fraud characteristics). Andthe constants βi are the best constants that fit the model tothe data. The optimization procedures and details that areused for their obtainments are out of the scope of this workand we refer the reader to the work done by Hosmer andLemeshow [10] for a better understanding of this method.

6.2 Case Study and ResultsThis sections describes our case-study using a real datasetfrom TodaOferta (described in Section 3) and it discussesthe results of the experiments. In this section, we will applypart of the methodology proposed by Maranzato [19] to de-tect fraudsters against reputation systems in e-markets. Wewill compare and optimize some applications of the LogisticRegression Model.

It is important to say that the approach of sorting sellersby the number of positive characteristics of fraud has limi-tations if you compare it to the Logistic Regression Modelthat we apply in this work and another previous work [17].

8Average precision (AP ) is defined by:

AP =

∑|K|k=1

(P (k) × rel(k))

|K|

where k is the rank, K the number of sellers, rel() a bi-nary function that returns if it is fraudster ou not, and P (k)precision at a given cut-off rank.

The first limitation is that it is difficult to consider negativecharacteristics, that is, the percentage of the characteristicin NFrT is significantly higher than in FRST because it onlysums each one without considering if its positive or negativeevidence of fraud.

Another limitation is related to characteristics defined bythresholds. The counting characteristics method cannot dealwith continuous values but only binary ones, because it con-siders only a binary response for a given characteristic offraud. One example is the period between the transactionand the evaluation. We saw that the shorter the periodevaluated is, the greater the chances of fraud. If we define athreshold we cannot use these variations of time as an inputvalue to the analysis.

It is also possible to apply the Logistic Regression Model toconsider percentages of occurrence of one characteristic inthe transactions instead of just considering the characteris-tic of the seller. It is important to remember that it is a ruleof the specialists in the investigation process in TodaOferta,but considering as fraudster a seller that has only one sus-picious transaction in many of them can generate a lot offalse positives. Afterwards, we will see that this informationis used to improve the ranking performance.

In order to apply Logistic Regression Model the first taskis to prepare the dataset. To make a list of all sellers, foreach one, we check if there is at least one transaction thatcontains the characteristics described in Section 4. We use1 to indicate this existence and 0 otherwise. Afterwards, weimprove this list with two non-fraud characteristics: an in-dication of if the seller passed for an editorial analysis9 andthe percentage of transactions that are effectively done byPagSeguro. To complete that list, we compute the percent-age of transactions that has a characteristic for each seller.

The next step is to build the dataset that is going to be usedas input to the Logistic Regression Model. We decided toadopt the full data for training and also for testing. The factthat the obtained performance numbers are not trustablebecause the generated model suffers from overfitting is nota problem anyway since the non-fraud annotations are nottrustworthy, as we discovered in our previous work [17, 18].We are aware of the problem, but we are interested in rank-ing sellers by estimated fraud probability and using the fulldata is better for this purpose. The real performance num-bers of the ranking are those obtained by manual verificationby specialists analysis.

It is important to say that both for training and testingdatasets we excluded all transactions in AFrT that are not inFRST , since our focus is to discover fraudsters in reputationsystems and these transactions can not be considered NFrTneither FRST . We believe that improvements in our workcould handle AFrT too, but here our focus is just FRST .That is the reason to discard frauds that are not related to

9TodaOferta has a program in which sellers can send theirdocumentation for analysis to get a certificate. It indicatesthat the seller really exists and follows the rules of market-places.


reputation systems.

In order to apply the Logistic Regression Model to ranksellers, we use the free software for statistical computingR – for more details see http://www.r-project.org. Us-ing command glm provided by this, we consider FRS as adependent variable, considering the selected characteristicsand using the same dataset for training and testing. Hence,we obtain the estimated probability for a seller to be in FRS ,and we sort the sellers list from highest to lowest estimatedfraud probabilities. It is important to remember that in thisfirst application we have just used the same 17 characteris-tics that can be used in Characteristic Counting describedin Section 5.

With this sorted list of sellers, we compute precision, recalland F-measure for each percentage of the list. One shortsummary of these results is listed in Table 5. We saw thatchecking between 8% and 10% of the sellers sorted by theestimated fraud probability, we can achieve the best value ofF-measure, covering around 50% of fraudsters against rep-utation system in this marketplace. We will name this firstapplication of Logistic Regression Model as “APP1” for fur-ther comparison.

% of sellers Recall Precision F-measure

1% 10,7% 82,1% 0,189

2% 17,7% 67,9% 0,280

3% 23,3% 59,8% 0,336

4% 29,3% 56,4% 0,386

5% 33,3% 51,3% 0,404

6% 38,0% 48,7% 0,427

7% 41,0% 45,1% 0,429

8% 46,7% 44,9% 0,458

9% 49,7% 42,5% 0,458

10% 52,7% 40,5% 0,458

15% 65,0% 33,3% 0,441

20% 76,0% 29,2% 0,422

30% 83,7% 21,5% 0,341

40% 93,7% 18,0% 0,302

50% 97,7% 14,7% 0,256

51% 97,7% 14,4% 0,252

60% 98,7% 12,4% 0,221

70% 98,7% 10,7% 0,193

80% 98,7% 9,4% 0,171

90% 98,7% 8,3% 0,154

100% 100,0% 7,6% 0,141

Table 5: APP1 - Sellers ordered by probability offraud (Recall, Precision and F-measure)

Analyzing the results of APP1, we can see that the averageprecision is 45,5% - it represents an increment of 16.1% ifyou compare to the Characteristic Counting approach (CC).

Next, we are going to compare the results of the Characteris-tic Counting approach (see Section 5) with Logistic Regres-sion Model in three different applications: the first one usesthe same 17 characteristics from Section 4 (which we have al-ready done previously) and the second one uses percentages,

negative characteristics and characteristics with continuousdistribution, that represents 37 different variables (APP2)and the third one optimizes the second model using Step-wise Regression (APP3).

For a given data, this optimization basically selects the vari-ables upon which the best model is based. In this work, weuse backward regression, which involves starting with allcandidate variables and testing them one by one for sta-tistical significance, deleting any that are not significant tothe model. In this case, the selection criteria is based onAkaike’s Information Criterion (AIC)10. We refer the readerto the work from Hosmer and Lemeshow [10] for a betterunderstanding of this optimization method.

In those three applications of Logistic Regression, we com-pute the F-measure of both for each portion of sellers, in thesame way that we did in the first application (APP1). Wealso compute average precision for the entire rank to have asingle metric for each situation.

Figure 3 shows the comparison among these 3 applicationsfor the sellers sorted by estimated probability. As we can see,Logistic Regression Model performs better than Character-istic Counting and that it is possible to improve the perfor-mance of the results when we use the model that considersvariables that characteristic counting cannot deal with. Wehave made experiments with all sellers from the dataset, butwe are only displaying the results of the first 25% becauseafter that limit the values are quite similar and it simplifiesour analysis.

In Figure 3 we can also see that when using more variables(APP2 and APP3), the precision is better if you comparewith the first one that was using only positive and binarycharacteristics (APP1). In Table 6 we have the values of av-erage precision in this 4 different ways of ranking – one withCharacteristic Counting and 3 with the estimated probabil-ity provided by the application of Logistic Regression. Wesee that when we apply a Stepwise Regression the precisionvalues decrease a little, which shows that this kind of opti-mization, with the original annotation in this dataset, doesnot affect the global performance of this ranking.

Approach AveragePrecision

CC - Characteristic Counting 38.9%

APP1 - Logistic Regression - 17 variables 45.1%

APP2 - Logistic Regression - 37 variables 53.0%

APP3 - Logistic Regression - Optimized 52.3%

Table 6: Average Precision in each ranking.

APP3 resulted in 17 variables and they are different fromAPP1. With these results, that are in theory the best val-ues that we can achieve with the characteristics that we haveextracted in this dataset, we return to specialists to ask themto check what the actual performance of the output of these

10For more details about Akaike’s information criterion,please check the reference from Akaike [1]. The commandin software R that performs this model selection is stepAIC.


Figure 3: Comparison between Characteristic Counting approach and Logistic Regression Model in differentapplications

applications of Logistic Regression Model is, especially atthe top of the list. In our previous work we discovered morefraudsters than the original annotation [17, 18] so we knowin advance that the performance metrics could be better. Itis important to say that the best revision process would beif it were possible to use the list generated by APP3, butspecialists also checked previous lists sorted by characteris-tics counting when we were validating those characteristics.After that revision, we reach an average precision of 78.0%(we had around 53% before revision in APP2 and APP3).

As the number of elements in the predefined sets has changedbecause new fraudsters were detected, we decided to build anew model using the same variables of the second approachthat considers 37 characteristics, but using the values of thereference variable after specialists’ revision (FRS Reviewed).

After that, we decided to optimize the model by applyingStepwise Regression to find the best model that fits in thisdataset with the new fraudsters set. This optimization gen-erates a model with 25 out of 37 variables and its perfor-mance is shown in Table 7. In the final model, only onecharacteristic extracted was not used (SILF). We can seethat either the binary characteristic, that was described inSection 4, or its respective percentage in the transactions11

is present. It show that the process of characteristic extrac-tion was correct. These variables are:

x1 = pctSITL, x2 = SWLB, x3 = pctSWLB, x4 = SWLT, x5 = pctSWLF,

x6 = SWSB, x7 = SWST, x8 = SWSF, x9 = SDBS, x10 = pctSDBS,

x11 = pctSILB, x12 = SILT, x13 = SISB, x14 = pctSISB, x15 = SIST,

x16 = pctSIST, x17 = SISF, x18 = QBF, x19 = pctQBF, x20 = UDTB,

x21 = pctUDTB, x22 = SRVT, x23 = TCPS, x24 = SITL, x25 = REC1.

Analyzing the results in Table 7 we see that the precisionof this model is 100% when we consider 9% of the sellers inthe sorted list. It is also possibile to see that the best valueof F-measure is when whe check 14% of the sellers. At this

11The prefix “pct” shows that the variable refers to the per-centage of the characteristic in transactions.

% of sellers Recall Precision F-measure

1% 6.1% 100.0% 0.115

2% 12.2% 100.0% 0.218

3% 18.4% 100.0% 0.310

4% 24.5% 100.0% 0.393

5% 30.6% 100.0% 0.469

6% 36.7% 100.0% 0.537

7% 42.9% 100.0% 0.600

8% 49.0% 100.0% 0.658

9% 55.1% 100.0% 0.711

10% 60.9% 99.5% 0.756

11% 66.9% 99.3% 0.799

12% 72.7% 98.9% 0.838

13% 76.9% 96.6% 0.857

14% 80.4% 93.8% 0.866

15% 82.9% 90.3% 0.864

15% 82.9% 90.3% 0.864

20% 89.0% 72.7% 0.800

30% 94.5% 51.5% 0.666

40% 98.0% 40.0% 0.568

50% 99.1% 31.7% 0.481

60% 100.0% 26.8% 0.422

70% 100.0% 23.0% 0.374

80% 100.0% 20.2% 0.336

90% 100.0% 17.9% 0.304

100% 100.0% 16.1% 0.278

Table 7: APP4 - Sellers ordered by probability offraud (Recall, Precision and F-measure)


point, we reach more than 80% of fraudsters with 93.8% ofprecision.

We have seen in Figure 3 that we are constantly improv-ing precision values, especially on top of sellers’ list. Butafter specialists’ revision, this performance is much better,as we can see in Figure 4. This gain can also be verified inTable 6, where we observe the average precision values ofeach application. And in the last application (APP4), theaverage precision is 93%.

Figure 4: Comparison between Logistic RegressionModel before and after specialists’ review

Another important tool to compare the performance of thesedifferent ways to apply Logistic Regression Model and theoptimization done through the experiments in our datasetis to analyze precision in terms of recall.

Figure 5: Precision x Recall

In Figure 5 we see that using a model optimized to the an-notation after specialists’ revision, the precision is better ifwe compare to the original annotation. It confirms that ourprocedures improve the fraud detection process because wegenerate a list of fraudsters sorted by an estimated prob-ability that has high precision on the top of that list. Inthis scenario, it does not generate many false-positives andreduces the cost of fraud investigation.

Another benefit of using Logistic Regression Model is that it

is possible to input the model with the dataset of reviewedanalysis and rebuild it. Furthermore, it is possible to opti-mize the model with the new training dataset. We believethat it can improve the accuracy of the fraudsters’ list andbe adapted to new transactions.

The results also show an increment of the average precisionin the reviewed list compared to the original precision in75% (from 53% to 93%). This indicates that our approachof optimization improves significantly the fraud detectionprocess.

Considering the problem of overfitting that we have ex-plained before in the beginning of this section, we are con-ducting some experiments splitting the dataset in trainingand testing data. We are sorting the transactions by achronological date and using the first ones (or the older ones,in other words) to train and the last ones to test, simulatingthe actual scenario of the marketplace, where new transac-tions are occurring and these ones need to be investigated.The results that we are obtaining show that the precisionremains in the same level that we have in this work – higherthan 90% in average precision.

One important benefit of using Logistic Regression and opti-mization is that we can determine a threshold of F-measure(or precision or recall), to automatically disable some sellers.While specialists are checking our list, we observe that forthe top ranked sellers, they just disable the fraudster, but asthey continue checking, in some cases, they prefer to warnthem, considering that seller defrauds the reputation system,but he has some transactions that are licit (this thresholddetermination can be subject of future work). This situationfrequently happens when the seller has negative characteris-tics of fraud. It offers an opportunity to punish those sellers,to register fraud, and to give them another chance. It canbe recorded and used in future events. It also allows themto reconsider some editorial recognition and the relationshipthat was established.

7. CONCLUSIONSE-markets constitute an important research scenario due totheir popularity and revenues over the last years. In thisscenario, reputation plays an important role, mainly for pro-tecting buyers from fraudulent sellers. A reputation mecha-nism tries to provide an indication of how trustworthy a useris, based on his/her performance in previous transactions.

In online marketplaces, reputation is based on feedback sys-tems that use the past transactions as reference to show userperformance with the intention of providing more informa-tion for future transactions. Mostly, fraud detection is donethrough reactive procedures where fraud experts conductan investigation from a user claim. This work is focused onsupport decision for fraud detection against the reputationsystems as a complement to fraud experts decisions.

Here, we apply such a set of characteristics for fraud detec-tion to the e-market reputation systems. Besides, we de-scribe and evaluate two approaches for identifying frauds,one based on fraud characteristics counting and another one


based on Logistic Regression modeling. Moreover, we en-hance the characteristics set with non-fraud characteristicsthat Logistic Regression can deal with but CharacteristicsCounting can not. We compare both approaches using ac-tual data from a large Brazilian e-market (TodaOferta).

We apply Logistic Regression Model to these set of charac-teristics. The method naturally ranks all sellers consideringtheir fraud against the reputation system estimated proba-bility. We also see that it is possible to optimize the modelusing stepwise regression to improve the quality of the rank-ing. The output of this application is a list of sellers sortedby the estimated fraud probability.

This list allows experts to prevent fraud instead of just react-ing. In the end, using the rank provided by Logistic Regres-sion, we increased by 112% the number of identified fraud-sters in TodaOferta marketplace. And when we optimize themodel we reach an average precision of 93%.

As future work, we want to apply the same methodology toidentify other types of fraud along with the ones in repu-tation systems. In particular, we are interested in findingcorrelation between frauds in reputation systems and othertypes of frauds. The idea of using network-based metrics [24]to complement the current characteristics of fraud seemsalso to be promising. We are planning a deeper analysisof the final obtained logistic model, checking which char-acteristics are stronger than others and analyzing their co-efficients βi [10], before trying other classification and/orranking methods.

8. ACKNOWLEDGMENTSThis work was partially sponsored by Universo Online S.A.- UOL (http://www.uol.com.br) and partially supported bythe Brazilian National Institute of Science and Technologyfor the Web (CNPq grant no. 573871/2008-6), CAPES,CNPq, Finep, and Fapemig. We also thank Aline Pereiraand Rodnei Lozano, from UOL, for their support on theanalysis and validation of our results.

9. REFERENCES[1] H. Akaike. A new look at the statistical model

identification. IEEE Transactions on AutomaticControl, 19:716–723, 1974.

[2] S. Ba and P. A. Pavlou. Evidence of the effect of trustbuilding technology in electronic markets: pricepremiums and buyer behavior. MIS Quarterly,26(3):243–268, 2002.

[3] C. Dellarocas. Reputation mechanisms. In Handbookon Economics and Information Systems, page 2006.Elsevier Publishing, 2006.

[4] R. O. Duda, P. E. Hart, and D. G. Stork. PatternClassification (2nd Edition). Wiley-Interscience, 2edition, November 2000.

[5] J. Feigenbaum, D. C. Parkes, and D. M. Pennock.Computational challenges in e-commerce. Commun.ACM, 52(1):70–74, 2009.

[6] B. Gavish and C. L. Tucci. Reducing internet auctionfraud. Commun. ACM, 51(5):89–97, 2008.

[7] D. G. Gregg and J. E. Scott. The role of reputationsystems in reducing on-line auction fraud. Int. J.Electron. Commerce, 10(3):95–120, 2006.

[8] R. Guha, R. Kumar, P. Raghavan, and A. Tomkins.Propagation of trust and distrust. In WWW ’04:Proceedings of the 13th international conference onWorld Wide Web, pages 403–412, New York, NY,USA, 2004. ACM.

[9] C. Holahan. Auctions on ebay: A dying breed.BusinessWeek online, jun 2008.

[10] D. W. Hosmer and S. Lemeshow. Applied logisticregression. Wiley-Interscience Publication, September2000. (Wiley Series in probability and statistics).

[11] D. Houser and J. Wooders. Reputation in auctions:Theory, and evidence from ebay. Journal of Economics& Management Strategy, 15(2):353–369, 06 2006.

[12] T. B. Klos and F. Alkemade. Trusted intermediatingagents in electronic trade networks. In AAMAS ’05:Proceedings of the fourth international joint conferenceon Autonomous agents and multiagent systems, pages1249–1250, New York, NY, USA, 2005. ACM.

[13] T. T. Le. Pathways to leadership forbusiness-to-business electronic marketplaces.Electronic Markets, 12(2), 2002.

[14] M. J. Lenard and P. Alam. Organizational DataMining: Leveraging Enterprise Data Resources forOptimal Performance, chapter The Use of Fuzzy Logicand Expert Reasoning for Knowledge Managementand Discovery of Financial Reporting Fraud. IdeaGroup Publishing, Hershey, PA, 2004.

[15] M. J. Lenard and P. Alam. An historical perspectiveon fraud detection: From bankruptcy models to mosteffective indicators of fraud in recent incidents. Journalof Forensic & Investigative Accounting, 1(1), 2009.

[16] Y.-I. Lou and M.-L. Wang. Fraud risk factor of thefraud triangle assessing the likelihood of fraudulentfinancial reporting. Journal of Business & EconomicsResearch, 7(2):61–78, February 2009.

[17] R. Maranzato, M. Neubert, A. Pereira, and A. P.do Lago. Feature extraction for fraud detection inelectronic marketplaces. In LA-WEB 2009: 7th LatinAmerican Web Congress, Merida, Mexico, 2009. IEEEComputer Society.

[18] R. Maranzato, M. Neubert, A. Pereira, and A. P.do Lago. Fraud detection in reputation systems ine-markets using logistic regression. In SAC ’10:Proceedings of the 2010 ACM symposium on Appliedcomputing, Sierre, Switzerland, 2010. ACM.

[19] R. P. Maranzato. Identificacao de fraude contrasistemas de reputacao em mercados eletronicos.Master’s thesis, Instituto de Matematica e Estatıstica- Universidade de Sao Paulo, Sao Paulo, Brasil, 2010.

[20] S. P. Marsh. Formalising Trust as a ComputationalConcept. PhD thesis, Department of Mathematics andComputer Science, University of Stirling, 1994.

[21] M. I. Melnik and J. Alm. Does a seller’s ecommercereputation matter? evidence from ebay auctions.Journal of Industrial Economics, 50(3):337–49,September 2002.


[22] J. A. Ohlson. Financial ratios and the probabilisticprediction of bankruptcy. Journal of AccountingResearch, 18:109–131, 1980.

[23] A. M. Pereira, D. Duarte, W. M. Jr., V. Almeida, andP. Goes. Analyzing seller practices in a brazilianmarketplace. In 18th International World Wide WebConference, pages 1031–1041, April 2009.

[24] A. M. Pereira, A. Silva, W. Meira, Jr., andV. Almeida. Seller’s credibility in electronic markets:a complex network based approach. In WICOW ’09:Proceedings of the 3rd workshop on Informationcredibility on the web - WWW’09 workshop, pages59–66, New York, NY, USA, 2009. ACM.

[25] P. Resnick, K. Kuwabara, R. Zeckhauser, andE. Friedman. Reputation systems. Commun. ACM,43(12):45–48, 2000.

[26] P. Resnick and R. Zeckhauser. Trust among strangersin internet transactions: Empirical analysis of ebay’sreputation system. The Economics of the Internet andE-Commerce, edited by M.R. Baye. Amsterdam:Elsevier Science B.V.:127–157, 2002.

[27] P. Resnick, R. Zeckhauser, J. Swanson, andK. Lockwood. The value of reputation on ebay: Acontrolled experiment. School of Information,University of Michigan, Ann Arbor, Michigan,USA:34, 2003.

[28] S. Viaene, R. A. Derrig, B. Baesens, and G. Dedene. Acomparison of state-of-the-art classification techniquesfor expert automobile insurance fraud detection.Journal of Risk and Insurance, 69(3):373–421, 2002.

[29] S. M. Weiss and C. A. Kulikowski. Computer SystemsThat Learn: Classification and Prediction Methodsfrom Statistics, Neural Nets, Machine Learning, andExpert Systems. Morgan Kaufmann, 1991.

[30] G. Zacharia, A. Moukas, and P. Maes. Collaborativereputation mechanisms for electronic marketplaces.Decision Support Systems, 29(4):371 – 388, 2000.


About the authors:

Rafael Plana Maranzato is a project manager in the department of research and development of ecommerce products at Universo Online (UOL), the largest Brazilian Internet portal. He holds a bachelor degree in mathematics at Fundação Santo André-SP (FSA) in 1999 and received his master degree in 2010 at the Mathematics & Statistics Institute (IME) of University of São Paulo (USP) - his research was about fraud detection in reputation systems in marketplaces. He is also interested in agile development and project management.

Adriano C. Machado Pereira is an Adjunct Professor at Federal Center of Technological Education of Minas Gerais (CEFET-MG), Brazil. He received his bachelor degree in Computer Science at UFMG in 2000, his MSc. in 2002, and his Ph.D. in 2007. His research interests include e-Business, Information and System’s Credibility, Distributed Systems, Web 2.0, Social Networks, Performance of Computer Systems, Web Technologies, Workload Characterization, Formal Methods, and Business Intelligence. He has worked as a consultant for the Brazilian government and United Nations Development Programme (UNDP) in a project of an Open Source Cooperation Network for e-governance for Latin America. He is also a member of the Brazilian National Institute of Science and Technology for the Web (www.inweb.org.br). He is also a Post-Doc researcher in Computer Science in a cooperated project with UOL, the largest Latin American Internet Service Provider.

Marden Neubert holds a bachelor degree and a Master's degree in Computer Science from Federal University of Minas Gerais (UFMG), Brazil. He has researched topics in Information Retrieval, Software Engineering and Fraud Detection. Currently he works as Research and Development Director at Universo Online (UOL), the largest Brazilian Internet portal.

A. Pereira do Lago, an assistant professor in the Computer Science Department of University of São Paulo, is one of Imre Simon's students, a prized Hungarian mathematician who helped to found Computer Science in Brazil. Imre improved the mathematical rigor that was already present in the student since he also obtained the third premium in the International Olympiads on Mathematics, in 1983. They both helped to solve a 20 years old conjecture in Automata Theory and Formal Languages, and their work was cited by important researchers like Mark Sapir and Nachum Dershowitz. Supervising other students on their Masters and/or PhD work, the former student has also been able to develop a quite rigorous research is areas as different as Operational Systems, Computational Biology, Advanced Data Structures, Information Retrieval, Formal Concept Analysis and Fraud Detection.


A tool for rapid development of WS-BPEL applications

Luca CesariDipartimento di Sistemi e

InformaticaUniversità degli Studi di

[email protected]

Rosario PuglieseDipartimento di Sistemi e


[email protected]

Francesco TiezziDipartimento di Sistemi e


[email protected]

ABSTRACTWS-BPEL is imposing itself as a standard for orchestrationof web services. However, there are still some well-knowndifficulties that make programming in WS-BPEL a trickytask. In this paper, we present BliteC, a software tool wehave developed for supporting a rapid and easy developmentof WS-BPEL applications. BliteC translates service orches-trations written in Blite, a formal language inspired to butsimpler than WS-BPEL, into readily executable WS-BPELprograms. We illustrate our approach by means of a fewpractical programming examples.

Categories and Subject DescriptorsD.2.2 [Software engineering]: Design Tools andTechniques—Computer-aided software engineering ; D.3.1[Programming Languages]: Formal Definitions andTheory—Syntax Semantics; D.3.4 [Programming Lan-guages]: Processors—Compilers Parsing

KeywordsService-Oriented Computing, Web services, Compilers

1. INTRODUCTIONIn recent years, there has been an ever increasing acceptanceof WS-BPEL [30] as a standard language for orchestration ofweb services, one of the most successful and well-developedimplementations of the Service-Oriented Computing (SOC)paradigm. However, designing and developing WS-BPELapplications is a difficult and error-prone task. The lan-guage has an XML syntax which makes awkward writingWS-BPEL code by using standard editors. Therefore, manycompanies (among which e.g. Oracle and Active Endpoints)have equipped their WS-BPEL engines with graphical de-signers. Such tools are certainly suitable to develop sim-ple business processes, but turn out to be cumbersome andineffective when programming more complex applications.Further difficulties derive from the fact that WS-BPEL isequipped with such intricate features as concurrency, mul-

tiple service instances, message correlation, long-runningbusiness transactions, termination and compensation han-dlers. Most of all, WS-BPEL comes without a formal se-mantics and its specification document, written in ‘natural’language, contains a fair number of acknowledged ambigu-ous features that may give rise to different interpretations.These ambiguities have led to engines implementing differentsemantics (see [25]) and, hence, have undermined portabilityof WS-BPEL programs across different platforms. There-fore, many research efforts have been devoted to provideWS-BPEL with a formal semantic (see, e.g., [27, 18, 33, 31,24, 26, 20, 21]), although most of them do not deal withthe complete language. Finally, the deployment procedureof WS-BPEL programs is not standardised, which furthercompromises portability. In fact, to execute a WS-BPELprogram, besides the associated WSDL [17] document thatdescribes the program’s public interfaces, different enginesrequire different (and not integrable) process deployment de-scriptors, i.e. sets of configuration files that describe how theprogram should be deployed.

To overcome these difficulties, we have developed BliteC, asoftware tool that accepts as an input a specification writtenin the lightweight orchestration language Blite [25] and re-turns the corresponding WS-BPEL program together withthe associated WSDL and deployment descriptor files.

Blite is closely inspired to WS-BPEL. It is the result of atension between handiness and expressiveness. While the setof WS-BPEL constructs is not intended to be a minimal one,the design of Blite, to keep the language manageable, onlyretains the core features of WS-BPEL. It follows that Bliteis simpler and more compact than WS-BPEL, although itmaintains the same descriptive power. Using Blite for ini-tially specifying a service orchestration offers some signifi-cant advantages. From the one hand, Blite textual notationis certainly more manageable than those, possibly graphi-cal, notations proposed for WS-BPEL. From the other hand,Blite is equipped with a formal operational semantics thatclarifies all ambiguous and intricate aspects of WS-BPEL.Of course, to preserve such semantics on different WS-BPELengines, the translation of Blite programs into WS-BPELones has to be properly targeted to each specific engine.

BliteC further simplifies the programmers work by automa-tizing the deployment procedure. In fact, the returned filesare properly packaged to be immediately executable in aWS-BPEL engine. Currently, these packages are intended


Figure 1: BliteC workflow

to be deployed on ActiveBPEL [6] that, according to [25],is one of the freely available WS-BPEL engines that bettercomplies with the WS-BPEL specification. The workflow ofuse of BliteC is graphically depicted in Figure 1.

The rest of the paper is organized as follows. Section 2 sum-marizes WS-BPEL, while Section 3 introduces the syntax ofBlite accepted by our tool. Section 4 presents BliteC andexplains the correspondence between Blite constructs andWS-BPEL activities. Section 5 illustrates BliteC at work onsome practical examples, one of which is borrowed from theofficial specification of WS-BPEL. Section 6 reviews moreclosely related work and hints at some future work.

2. AN OVERVIEW OF WS-BPELWS-BPEL is essentially a linguistic layer on top of WSDLfor describing the structural aspects of web service orches-tration. In WS-BPEL, the logic of interaction between a ser-vice and its environment is described in terms of structuredpatterns of communication actions composed by means ofcontrol flow constructs that enable the representation ofcomplex structures. Orchestration exploits state informa-tion that is maintained through shared variables and man-aged through message correlation. For the specification oforchestration, WS-BPEL provides many different basic andstructured activities.

The following basic activities are provided: <receive> and<reply>, to enable web service one-way and request-responseoperations; <invoke>, to invoke web service operations; <wait>,to delay execution for some amount of time; <assign>, to up-date the values of variables with new data; <throw>, to signalinternal faults; <exit>, to immediately end a service instance;<empty>, to do nothing; <compensate> and <compensateScope>, toinvoke compensation handlers; <rethrow>, to propagate faults;<validate>, to validate variables; and <extensionActivity>, toadd new activity types.

The structured activities describe the control flow logic ofa business process by composing basic and/or structuredactivities recursively. The following structured activities areprovided: <sequence>, to execute activities sequentially; <if>,to execute activities conditionally; <while> and <repeatUntil>,to repetitively execute activities; <flow>, to execute activitiesin parallel; <pick>, to execute activities selectively; <forEach>,to (sequentially or in parallel) execute multiple activities;and <scope>, to associate handlers for exceptional events toa primary activity.

The handlers within a <scope> can be of four differentkinds: <faultHandler>, to provide the activities in responseto faults occurring during execution of the primary ac-tivity; <compensationHandler>, to provide the activities tocompensate the successfully executed primary activity;<terminationHandler>, to control the forced termination of theprimary activity; and <eventHandler>, to process message ortimeout events occurring during execution of the primaryactivity. If a fault occurs during execution of a primary ac-tivity, the control is transferred to the corresponding faulthandler and all currently running activities inside the scopeare interrupted immediately without involving any fault/-compensation handling behaviour. If another fault occursduring a fault/compensation handling, then it is re-thrown,possibly, to the immediately enclosing scope. Compensa-tion handlers attempt to reverse the effects of previouslysuccessfully completed primary activities (scopes) and havebeen introduced to support Long-Running (Business) Trans-actions (LRTs). Compensation can only be invoked fromwithin fault or compensation handlers starting the compen-sation either of a specific inner (completed) scope, or of allinner completed scopes in the reverse order of completion.The latter alternative is also called the default compensa-tion behaviour. Invoking a compensation handler that isunavailable is equivalent to perform an empty activity.

A WS-BPEL program, also called (business) process, is a<process>, that is a sort of <scope> without compensation andtermination handlers.

WS-BPEL uses the basic notion of partner link to directlymodel peer-to-peer relationships between services. This re-lationship is expressed at the WSDL level by specifying theroles played by each of the services in the interaction. How-ever, the information provided by partner links is not enoughto deliver messages to a business process. Indeed, since mul-tiple instances of a same service can be simultaneously activebecause service operations can be independently invoked byseveral clients, messages need to be delivered not only to thecorrect partner, but also to the correct instance of the ser-vice that the partner provides. To achieve this, WS-BPELrelies on the business data exchanged rather than on specificmechanisms, such as WS-Addressing [22] or low-level meth-ods based on SOAP headers. In fact, WS-BPEL exploitscorrelation sets, namely sets of correlation variables (calledproperties in WS-BPEL jargon), to declare the parts of amessage that can be used to identify an instance. This way,a message can be delivered to the correct instance on thebasis of the values associated to the correlation variables,independently of any routing mechanism.

We end this section by showing an auction service describedin the official specification of WS-BPEL [30, Sect. 15.4].This example will allow us to illustrate most of the lan-guage features, including correlation sets, shared variables,control flow structures, asynchronous communication andmultiple start activities, and, through its implementation inBlite presented in Section 5.3, will permit a rough compari-son between the two languages.

The auction service collects information from a seller and abuyer about a concluded auction, reports the auction resultto an auction registration service, and then communicates


the registration result to the seller and the buyer. The auc-tion house process may be instantiated either by receivingthe seller information or by receiving the buyer information.Indeed, the process is able of receiving the seller and buyerrequests in a statically unpredictable order and in such away that the first incoming message triggers the creation ofa process instance which the subsequent request is deliveredto. This requires the two starting receive activities to sharea correlation set, which will be initialized with an auctionidentifier that the seller and the buyer have to provide whensending their requests. The auction house process passes theauction identifier to the auction registration service that, inits turn, returns the identifier in its answer to locate theproper process instance.

We report below the corresponding WS-BPEL program,where to make the reading of the code easier, we have omit-ted irrelevant details1 and highlighted the basic activitiesreceive, invoke and assign.

<process name="auctionService" ... ><partnerLinks> ... </partnerLinks><variables> ... </variables><correlationSets><correlationSet name="auctionIdentification"

properties="as:auctionId" /></correlationSets><sequence><flow><receive name="acceptSellerInformation"

partnerLink="seller"portType="as:sellerPT"operation="submit"variable="sellerData"createInstance="yes">

<correlations><correlation set="auctionIdentification"

initiate="join" /></correlations>

</receive>

<receive name="acceptBuyerInformation"partnerLink="buyer"portType="as:buyerPT"operation="submit"variable="buyerData"createInstance="yes">

<correlations><correlation set="auctionIdentification"

initiate="join" /></correlations>

</receive></flow>

<assign><copy><from>... http://example.com/auction/RegistrationService ...

</from><to partnerLink="auctionRegistrationService" />

</copy><copy><from partnerLink="auctionRegistrationService"

endpointReference="myRole" /><to>$auctionData.auctionHouseEndpointReference</to>

</copy><copy><from>$sellerData.auctionId</from><to>$auctionData.auctionId</to>

</copy><copy><from>1</from><to>$auctionData.amount</to>

</copy></assign>

<invoke name="registerAuctionResults"partnerLink="auctionRegistrationService"portType="as:auctionRegistrationPT"operation="process"inputVariable="auctionData" />

<receive name="receiveAuctionRegistrationInformation"partnerLink="auctionRegistrationService"portType="as:auctionRegistrationAnswerPT"

1The fully detailed version of the WS-BPEL process and theassociated WSDL document can be found in [30, Sect. 15.4].

operation="answer"variable="auctionAnswerData">

<correlations><correlation set="auctionIdentification" />

</correlations></receive>

<flow><sequence>

<assign><copy><from>$sellerData.endpointReference</from><to partnerLink="seller" />

</copy><copy><from><literal>Thank you!</literal></from><to>$sellerAnswerData.thankYouText</to>

</copy></assign>

<invoke name="respondToSeller"partnerLink="seller"portType="as:sellerAnswerPT"operation="answer"inputVariable="sellerAnswerData" />

</sequence><sequence>

<assign><copy><from>$buyerData.endpointReference</from><to partnerLink="buyer" />

</copy><copy><from><literal>Thank you!</literal></from><to>$buyerAnswerData.thankYouText</to>

</copy></assign>

<invoke name="respondToBuyer"partnerLink="buyer"portType="as:buyerAnswerPT"operation="answer"inputVariable="buyerAnswerData" />

</sequence></flow>

</sequence></process>

Notice that the buyer and the seller provide their endpointreferences for the auction house process to respond properlyin an asynchronous way. For similar reasons, the auctionhouse process provides its own endpoint reference to theauction registration service.

3. PROGRAMMING SERVICES IN BLITEA Blite program accepted by BliteC is composed of a Blitespecification and a declarative part. The former focusses onthe behavioural aspects of the orchestration, while the latterprovides the implementation details (e.g. types, addresses,bindings, . . . ) that are necessary to deploy and execute thecorresponding WS-BPEL program.

3.1 Blite specificationBlite [25] is a prototypical orchestration language whose de-sign is closely inspired to WS-BPEL. To keep the languagemanageable, the design of Blite only retains the core featuresof WS-BPEL. In fact, some aspects have been intention-ally left out, including timeouts, synchronization dependen-cies within flow activities, event and termination handlers.Moreover, Blite only provides a simplified form of fault andcompensation handling and only supports unnamed faultsand the default compensation mechanisms.

Blite provides a formal description of service deploymentsby only keeping relevant implementation details. Thus, theroles played by service partners in a service interaction areexplicitly indicated by partner links and partners, while suchaspects as physical service binding (necessary to generate


the associated WSDL documents and deployment descrip-tors) are abstracted away and dealt with separately in thedeclarative part.

The syntax of Blite accepted by BliteC is given in Figure 2.Services are structured activities built from basic activities,i.e. service invocation, service request processing, assign-ment, empty activity, fault generation and instance forcedtermination, by exploiting operators for conditional choice,iteration, sequential composition, parallel composition, pickand scope. A scope activity groups a primary activity Atogether with a fault handling activity Af and a compen-sation activity Ac. Start activities are structured activitiesthat initially can only execute receive activities. Sequencehas higher priority (i.e. bind more tightly) than parallelcomposition and pick. Moreover, fault and compensationactivities may be omitted from a scope construct, in whichcase they are intended to be throw and empty, respectively.

Notation < · > stands for tuples of objects, e.g. <x_1,. . . ,x_n>denotes a tuple of variables (variables in the same tuple mustbe pairwise distinct). Partner links pl can be either of theform <partner> or of the form <partner1,partner2>. Indeed, inone-way interactions a partner link indicates a single part-ner because one of the parties provides all the invoked op-erations. Instead, in asynchronous request-response inter-actions, partner links indicate two partners because the re-questing partner must provide a callback operation used bythe receiving partner to send notifications. Service partnersused for receiving messages must be known at design-time,while the partners used to send messages in reply may bedynamically determined.

Besides asynchronous invocation, WS-BPEL also providesa construct for synchronous invocation of remote services.This construct forces the invoker to wait for an answer bythe invoked service, that indeed performs a pair of activitiesreceive–reply. In Blite, this behaviour is rendered in termsof a pair of activities invoke–receive over the same opera-tion executed by the invoker and a corresponding pair ofactivities receive–invoke executed by the invoked service.

Data can be shared among different activities through sharedvariables (ranged over by x, x_1, . . . ). The manipulablevalues are boolean, integer numbers (ranged over by int),strings (as usual, written within double inverted commas),partner links, and literals (defined in the declarative partand denoted by putting the symbol $ in front of the corre-sponding identifier). Expressions combine values and vari-ables by means of boolean, arithmetic, comparision andstring operators. Operators set(x,"path") and get(x,"path")

can be used respectively in the left and right hand sides ofan assignment to act on a specific element (indicated by path)of the XML message stored in the variable x. Both opera-tors turn out to be quite useful for easily interacting withnon-Blite services (see Section 5.5).

Blite specifications are finite compositions of definitions(that assign names to Blite terms), containing at most onedeployment definition. A deployment associates a correla-tion set, namely a (possibly empty) set of correlation vari-ables, to a service. A service provides a ‘top-level’ scope (i.e.a scope that cannot be compensated) and offers a choice of

alternative receives among multiple start activities.

We refer the interested reader to [25] for a formal accountof the Blite operational semantics.

3.2 Declarative partThe declarative part of a Blite program specifies configura-tion data necessary to properly translate the Blite specifica-tion into an executable WS-BPEL program. Notably, BliteCrequires the user to insert only the strictly necessary data.The declarations must be included within <?blm and ?>, andcan occur in any position within a Blite program.

A declarative part has the following form:

<?blmADDRESSES {myns => " base_for_namespaces ";myaddress => " base_for_service_url ";

}IMPORTS {

associations prefix => " url ";}VARIABLES {

variable and message declarations}LITERALS {

associations literal_name => [[ literal_code ]];}PARTNERLINKS {

partner link type declarations}

?>

where blocks ADDRESSES and VARIABLES are mandatory, whilethe other ones can be omitted.

Within the ADDRESSES block the user has to specify the basefor the namespaces used inside the generated files (after thekeyword myns) and the base for the address where the newservice will be hosted (after the keyword myaddress).

To define a service orchestration it is often necessary to im-port data (e.g. type declarations) from documents (e.g.WSDL files) associated to other services. To this aim,the user can specify the addresses of the documents tobe imported within the IMPORTS block, by associating toeach imported document a namespace prefix that will beused in the subsequent declarations to refer to it. No-tably, definitions belonging to standard namespaces (e.g.http://www.w3.org/2001/XMLSchema) are automatically importedand, hence, do not require any declaration.

Blite variables are untyped, while WS-BPEL ones must betyped. Therefore, to enable an automated translation, theuser has to declare the type of the variables (both localvariables and messages) within the VARIABLES block. Localvariables, that can be used to temporarily store data andmanipulate them, are declared by associations of the formx => XML_Schema_type; (e.g. x_city => xsd:string;). Messages,i.e. tuples of variables used as either sending source or re-ceiving target, can be declared in two ways:

• by using an imported message type. For ex-ample, in <x_auctionId,x_registrationId> => reg:regResp;

the message composed of variables x_auctionId andx_registrationId is typed as regResp, that is defined inthe (WSDL) document identified by the namespaceprefix reg (defined in the IMPORTS block);


b ::= (basic activities)inv pl op <x_1,. . . ,x_n> | rcv pl op <x_1,. . . ,x_n> (invoke, receive)

| x := e | set(x,"path") := e | y := get(x,"path") (assignments)| empty | throw | exit (empty, throw, exit)

pl ::= <partner> | <partner1,partner2> (partner links)

e ::= (expressions)e1 | e2 | e1 & e2 | ! e | TRUE | FALSE (boolean operators)

| e1 + e2 | e1 - e2 | e1 * e2 | e1 / e2 | int (arithmetic operators)| e1 >= e2 | e1 <= e2 | e1 > e2 | e1 < e2 | e1 = e2 | e1 != e2 (relational operators)| e1 . e2 | "string" (string operators)| x | pl | $literal_name (variable, partner link, literal)

a ::= (structured activities)b | if (e) {a1} else {a2} | while (e) {a} (basic, conditional, iteration)

| seq a1 ; . . . ; an qes | flw a1 | . . . | an wlf (sequence, parallel)| [ A @ Af * Ac ] | pck rcv pl1 op1 <x_1,. . . ,x_k> ; a1 (scope, pick)

+ . . . + rcv pln opn <x_1,. . . ,x_h> ; an kcp

r ::= (start activities)rcv pl op <x_1,. . . ,x_n> | seq r; a1 ; . . . ; an qes | flw r1 | . . . | rn wlf (receive, sequence, parallel)

| [ R @ Af * Ac ] | pck rcv pl1 op1 <x_1,. . . ,x_k> ; a1 (scope, pick)+ . . . + rcv pln opn <x_1,. . . ,x_h> ; an kcp

s ::= [ R @ Af ] d ::= { S } {x_1,. . . ,x_n} (services, deployments)

A ::= a | i R ::= r | i S ::= s | i (activities/services identifiers)

def ::= i := a;; def | i := r;; def | i := s;; def | i := d;; (definitions)

Figure 2: Syntax of Blite

• by generating a new message type. For example, in<x_auctionId,x_creditCardNumberB,x_phoneNumber>=> gen:buyerReq, <id,ccNum,phone>,

<xsd:int,xsd:string,xsd:string>;

message <x_auctionId,x_creditCardNumberB,x_phoneNumber> istyped as buyerReq, that defines messages composed ofone integer and two string parts, id, ccNum and phone,respectively. The namespace prefix gen indicates thatthe type must be generated. If the type of a messagepart is an element type defined in an XML schema notgenerated by BliteC, the keyword (El) must precedethe type. For example, in

<num,scale,reqWeath>=> gen:req,

<init,scale,request>,<xsd:integer,xsd:string,(El)wth:GetCityWeatherByZIP>;

the element type GetCityWeatherByZIP is defined in theblock types of the WSDL document identified by wth.

In a WS-BPEL program, literals (i.e. constant values) canbe directly assigned to variables. Instead, in a Blite pro-gram, for the sake of readability, literals must first be de-clared within the LITERALS block, as e.g.

litConv => [[<tem:FahrenheitToCelciusxmlns:tem="http://webservices.daehosting.com/

temperature"><tem:nFahrenheit>0</tem:nFahrenheit>

</tem:FahrenheitToCelcius>]];

and, then, can be assigned to a variable by using the asso-ciated name, e.g. reqConv := $litConv;.

Similarly, also partner links are typed in WS-BPEL and un-typed in Blite. Therefore, except for the partner links usedby the process to interact with its clients, that are automat-ically generated and typed by BliteC, the type of the otherpartner links must be defined within the PARTNERLINKS block.Each declaration has the following form:

PARTNERLINK { TYPE => partner_link_type;MY_ROLE partner1 => port_type1 ;PARTNER_ROLE partner2 => port_type2 ; }

where the association for MY_ROLE can be omitted wheneverthe process does not play any role. Moreover, to de-couplethe Blite operation names from the WS-BPEL ones, associ-ations of the form (bliteOperation => wsbpelOperation) may bespecified after the definitions of the two roles.

4. BLITEC: FROM BLITE TO WS-BPELIn this section we present the architecture of BliteC andexplain the correspondence between the Blite constructs andthe WS-BPEL activities.

4.1 BliteC architectureBliteC2 is developed in Java3 to guarantee its portabilityacross different platforms, to exploit the well-established li-braries for generating parsers and for manipulating XMLdocuments, and because Java is the reference language forthe applications designed around WS-BPEL. Besides thestandard Java libraries, we have used JDOM [12] for cre-ating and managing XML documents, JavaCC [11] for gen-erating the parsers that validate the input documents, andJJTree4 for allowing the parsers to build parse trees (alreadyarranged to support the Visitor design pattern [19]).

The architecture of BliteC is graphically depicted in Fig-ure 3. The tool is composed of five main components:

2BliteC is a free software; it can be downloaded from http://rap.dsi.unifi.it/blite and redistributed and/or mod-ified under the terms of the GNU General Public License.3JRE and JDK version 6.4JJTree is included within JavaCC.


Figure 3: BliteC architecture

• Mapper parses the declarative part of the input Bliteprogram and initializes a map that associates each de-clared object (e.g. partner link, literal, variable, . . . )to its name;

• Blite parser analyzes the Blite specification within theinput program, completes the map created by Mapperand creates the parse tree of the Blite specification;

• WS-BPEL and WSDL generators use the data pro-duced by the above components to generate a WS-BPEL process and the associated WSDL document;

• Deployer generates the deployment descriptor andpackages all created documents into a deployable file;it is the only ‘engine-dependent’ component.

Any text editor can be used to write Blite programs. Any-way, to simplify the task, we provide users with a customizedversion of jEdit5 [2] equipped with specific features sup-porting programming in Blite, such as syntax highlighting,auto indentation and direct compiling. The files for the cus-tomization can be downloaded with the BliteC distributionarchive. The main advantage of jEdit with respect to moreprofessional development environments is that it is multi-platform and lightweight. We are also implementing a devel-opment environment with similar features written in Java.Figure 4 shows a screenshot of our environment. In additionto the functionalities of the customized version of jEdit, ourdedicated environment also provides text auto-completion,highlight of search results, local deploy and undeploy.

4.2 From Blite to WS-BPELWe now provide some insights about the transformation ofBlite constructs into WS-BPEL activities. Since the sameWS-BPEL program might have different behaviours on dif-ferent engines [25], the translation described here is targetedto a specific engine, i.e. ActiveBPEL. If one want to pro-duce packages intended to be executed by other WS-BPELengines, the translation has possibly to be properly tailored.Since there is no precise description of the behaviour of theActiveBPEL engine, it cannot be formally proved that thesemantics of the WS-BPEL program resulting from a trans-lation conforms to that of the original Blite program. How-ever, since Blite is a ‘sort of’ lightweight variant of WS-BPEL, the translation we define is quite intuitive and di-rect, which makes us confident that the original semantics is5jEdit is a programmer’s text editor written in Java releasedas free software with full source code, provided under theterms of the GPL 2.0.

Figure 4: BliteC development environment

Table 1: Mapping of the receive activityBlite WS-BPEL

pck ... <onMessage partnerLink="pl"rcv pl op <x1,. . . ,xn>... operation="op"kcp variable="x" />

<invoke partnerlink="pl"inv <p,p’> op <y1,. . . ,yn>; operation="op"rcv <p’> op <x1,. . . ,xm> inputVariable="y"

outputVariable="x" />

<receive partnerLink="pl"rcv pl op <x1,. . . ,xn> operation="op"

variable="x" />

obeyed. This is of course witnessed by all the experimentswe have done.

Communication activities, invokes and receives, are trans-lated in a different way depending on their arguments andtheir position in the code. Therefore, the translation of Bliteprograms proceeds in a top-down fashion and, in doing so,the WS-BPEL generator exploits the information previouslycollected by the Mapper and the Blite parser. For example,as shown in Table 1, if a receive activity is positioned withina pck construct it is translated as an <onMessage> activity; if itis positioned after an invoke (in case of a request-responseinteraction) it is translated as a synchronous <invoke>; oth-erwise, it is simply translated as a <receive>. In addition tothe excerpts shown in the table, the translation also settlesthe following activity attributes. If a receive is a start activ-ity, to allow the process to be instantiated, the createInstance

attribute must be set to yes. Moreover, if some correla-tion variables are involved, the corresponding correlation set(whose declaration is generated during the translation of thedeployment term) must be specified as a further argumentof the <receive> activity. The correlation attributes initiate

and pattern are set according to the type of the interaction.

The invoke activity is translated similarly, as shown in Ta-


Table 2: Mapping of the invoke activityBlite WS-BPEL

<invoke partnerLink="pl"inv pl op <x1,. . . ,xn> operation="op"

variable="x" />

<invoke partnerlink="pl"inv <p,p’> op <y1,. . . ,yn>; operation="op"rcv <p’> op <x1,. . . ,xm> inputVariable="y"

outputVariable="x" />

<receive ... />rcv <p,p’> op <y1,. . . ,yn> ...... <reply partnerlink="pl"inv <p’> op <x1,. . . ,xm> operation="op"

variable="x" />

Table 3: Mapping of assign, empty, throw and exitBlite WS-BPEL

<assign><copy>

x := e <from> e </from><to> $var_x.part_x </to>

</copy></assign>

<assign><copy><from> e </from>

set(x,"path") := e <to variable="var_x" part="part_x"><query> path </query></to>

</copy></assign>

<assign><copy><from variable="var_x" part="part_x">

y := get(x,"path") <query> path </query></from><to variable="var_y" part="part_y" />

</copy></assign>

empty <empty />

throw <throw />

exit <exit />

ble 2; in particular, when it is used in a request-responseinteraction to send the response, it is translated as a <reply>

activity. The translation of the remaining basic activities,as shown in Table 3, is straightforward. In particular, anassign activity involving message variables is translated bypossibly using XPATH queries and by exploiting the typeof the involved variables (defined in the declarative part) toidentify the corresponding parts. Also the translation of thestructured activities does not require a significant effort, asshown in Table 4. Finally, as shown in Table 5, a Blite ser-vice is rendered as a scope, where the compensation handleris removed and the tag <scope> is replaced by <process>.

5. BLITEC AT WORKIn this section, we present an application of BliteC to someillustrative practical scenarios. The WS-BPEL and WSDLfiles of the presented services are reported in [16], while allBlite programs and the corresponding WS-BPEL packagescan be retrieved along with the BliteC distribution archive.

5.1 A virtual credit card serviceA virtual credit card is a prepaid non-physical credit carddevised for safe online shopping. A Blite specification forcreating and handling a virtual credit card is the following:

s_vcard ::=[ seq

rcv <p_createcard> o_newcard <x_id,x_amount>;

Table 4: Mapping of structured activitiesBlite WS-BPEL

<if><condition> e </condition>

if (e) {a1} else {a2} a1<else> a2 </else>

</if>

<while>while (e) {a} <condition> e </condition>

a</while>

<sequence>seq a1 ; . . . ; an qes a1 . . . an

</sequence>

<flow>flw a1 | . . . | an wlf a1 . . . an

</flow>

<pick>pck a1 + . . . + an kcp a1 . . . an

</pick>

<scope><faultHandlers>

<catchAll><sequence>

<compensate/> af

</sequence>[ a @ af * ac ] </catchAll>

</faultHandlers><compensationHandler>

ac

</compensationHandler>a

</scope>

Table 5: Mapping of service definitionsBlite WS-BPEL

<process><faultHandlers>

<catchAll><sequence>

[ a @ af ] <compensate/> af

</sequence></catchAll>

</faultHandlers>a

</process>

while(x_amount>0){seqrcv <p_vcard,x_clt> o_getcash <x_id,x_wdr>;if (x_amount>=x_wdr)

{ seqx_amount := x_amount - x_wdr;x_resp := "Withdrawal of ". x_wdr .

" Euros accepted"qes }

else { x_resp := "Withdrawal of ". x_wdr ." Euros not accepted"};

inv <x_clt> o_getcash <x_id,x_resp>qes }

qes ];;

virtualcard ::= {s_vcard}{x_id};;

A new card is created by invoking the operation o_newcard

and specifying a card identifier and the initial amount. Thecreated instance allows the card holder to perform with-drawals by repeatedly invoking the request-response opera-tion o_getcash until the card is empty. For each withdrawalrequest, the money availability is checked and a message,stored in x_resp, is sent back. The fact that the invoke activ-ity used for the reply is performed along the same operationof the second receive indicates that the two activities form asynchronous request-response interaction, hence the invokewill be translated into a <reply> activity. The card identifier,stored in x_id, is used as a correlation value.


Since the above service does not need to invoke other ser-vices, only its address and variables are explicitly declared:

<?blmADDRESSES {myns => "http://virtualcard";myaddress => "http://XXX:8080/active-bpel/services";

}VARIABLES {<x_id,x_amount> => gen:creationReq,<id,amount>,

<xsd:int,xsd:int>;<x_id,x_wdr> => gen:withdrawalReq,<id,wdrAmount>,

<xsd:int,xsd:int>;<x_id,x_resp> => gen:withdrawalResp,<id,msg>,

<xsd:int,xsd:string>;}?>

To compile this Blite program, we have to save the abovecode into a file (named, e.g., vcard_service.bl) and execute thecommand java -jar blite.jar vcard_service.bl. This way, thefile virtualcardProcess.bpr, which is a WS-BPEL package di-rectly deployable into ActiveBPEL, is generated. Of course,the same actions can be also performed by using the editoror the development environment mentioned in Section 4.1.The WS-BPEL file included in the generated package, whereirrelevant details have been omitted, is as follows:

<?xml version="1.0" encoding="UTF-8"?><process name="virtualcardProcess" ... ><import location="virtualcard.wsdl" ... /><partnerLinks><partnerLink name="cltPL" partnerLinkType="mwl:cltPLT"

myRole="p_vcard" /><partnerLink name="p_createcardPL"

partnerLinkType="mwl:p_createcardPLT"myRole="p_createcard" />

</partnerLinks><variables><variable name="var1" messageType="mwl:withdrawalReq" /><variable name="var2" messageType="mwl:withdrawalResp" /><variable name="var0" messageType="mwl:creationReq" />

</variables><correlationSets><correlationSet name="x_idCorr"

properties="mwl:x_idProp" /></correlationSets><faultHandlers><catchAll><sequence> <compensate /> <empty /> </sequence>

</catchAll></faultHandlers><sequence><sequence><receive partnerLink="p_createcardPL"

operation="o_newcard"variable="var0"createInstance="yes">

<correlations><correlation set="x_idCorr" initiate="yes" />

</correlations></receive><assign><copy><from variable="var0" part="id" /><to variable="var1" part="id" />

</copy><copy><from variable="var0" part="id" /><to variable="var2" part="id" />

</copy></assign>

</sequence><while><condition>$var0.amount > 0</condition><sequence><receive partnerLink="cltPL"

operation="o_getcash"variable="var1">

<correlations><correlation set="x_idCorr" initiate="no" />

</correlations></receive><if><condition>$var0.amount >= $var1.wdrAmount

</condition>

<sequence><assign><copy><from>$var0.amount - $var1.wdrAmount</from><to variable="var0" part="amount" />

</copy></assign><assign><copy><from>concat(’Withdrawal of ’,string($var1.wdrAmount),

’ Euros accepted’)</from><to variable="var2" part="msg" />

</copy></assign>

</sequence><else><assign><copy><from>concat(’Withdrawal of ’,string($var1.wdrAmount),

’ Euros not accepted’)</from><to variable="var2" part="msg" />

</copy></assign>

</else></if><reply operation="o_getcash"

partnerLink="cltPL"variable="var2">


</correlations></reply>

</sequence></while>


As expected, the resulting WS-BPEL code is more verboseand intricate than the Blite one. However, the performedtranslation turns out to be quite ‘clean’, in the sense thateach BliteC activity has been translated into the correspond-ing WS-BPEL one without introducing ‘junk’ code.

To deploy the file virtualcardProcess.bpr, it is sufficient tomove it into the engine’s deployment directory bpr. Then,to check that the deploy succeeded, we can use the Ac-tiveBPEL’s administration console that can be accessed byusing any browser at the address http://XXX:8080/BpelAdmin

(where XXX is the server’s address where the ActiveBPELengine is running). By selecting Deployed Processes from themenu on the left-hand side, we obtain the list of the de-ployed processes (Figure 5) among which virtualcardProcess

should appear. Now, by selecting Deployed services, we canretrieve the URLs of the two WSDL files6 corresponding tothe partner links for interacting with the service:

http://XXX:8080/active-bpel/services/p_createcardService?wsdl

http://XXX:8080/active-bpel/services/p_vcardService?wsdl

To test the service behaviour, we can use a tool for automaticgeneration of web service requests, as e.g. soapUI [13], andinvoke the service by sending the following SOAP messages:

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:vir="http://virtualcard/virtualcard.wsdl"><soapenv:Header/><soapenv:Body>

<vir:x_idEL> 1234 </vir:x_idEL><vir:x_amountEL> 100 </vir:x_amountEL>

</soapenv:Body></soapenv:Envelope>

6In fact, when provided with a WSDL file, ActiveBPEL pro-duces as many WSDL files as the different partner links.


Figure 5: List of deployed processes

<soapenv:Envelopexmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/"xmlns:vir="http://virtualcard/virtualcard.wsdl"><soapenv:Header/><soapenv:Body>

<vir:x_idEL> 1234 </vir:x_idEL><vir:x_wdrEL> 50 </vir:x_wdrEL>

</soapenv:Body></soapenv:Envelope>

The first message creates a virtual credit card identifiedby 1234 with 100 Euros as initial amount, while the sec-ond message is a request for withdrawing 50 Euros. In re-sponse to the second message we get the string Withdrawal

of 50 Euros accepted and, by selecting Active Processes from theconsole menu, we can verify that the card instance is stillrunning. If we resend the request we obtain the same re-sponse, but the instance status changes to Completed.

5.2 On asynchronous communicationFrequently, it is assumed that a service request can be pro-cessed in a reasonable amount of time, justifying the re-quirement that the invoker waits for a response related to asynchronous request-response operation. In a business pro-cess setting, where communication costs are high or net-work latency is unpredictable, such assumption usually doesnot hold and the interactions are better modeled by asyn-chronous message exchanges. Therefore, an asynchronousmessaging approach is considered good practice for web ser-vices and service orchestrations in particular.

Although WS-BPEL provides the means for implementingasynchronous communication, it requires programmers todirectly deal with endpoint references, as shown by the ex-ample in Section 2. Instead, in Blite this relevant communi-cation pattern can be easily and transparently implemented.

A Blite specification for receiving a request and asyn-chronously replying with the string Hello is the following:s_asyncServer ::= [ seq

rcv <server,client> request <x_id>;x := "Hello";inv <client> response <x_id,x>

qes ];;asyncServer ::= {s_asyncServer}{x_id};;

Since this service does not need to invoke other services, thedeclarative part is just as follows:

<?blmADDRESSES {myns => "http://asyncComm";myaddress => "http://XXX:8080/active-bpel/services";

}VARIABLES {

<x_id> => gen:req,<id>,<xsd:int>;<x_id,x> => gen:resp,<id,msg>,<xsd:int,xsd:string>;

}?>

The corresponding invoker service is rendered in Blite as

s_asyncClient ::= [ seqrcv <p_init,y_clt> init <y_id>;inv <server,client> request <y_id>;rcv <client> response <y_id,y_msg>;y_resp := "Response: ".y_msg;inv <y_clt> init <y_id,y_resp>

qes ];;asyncClient ::= {s_asyncClient}{y_id};;

The process is initialized by invoking the synchronousrequest-response operation init. Then, the created instanceasynchronously invokes the partner server and, once receivesthe reply message, appends it at the response and sends theobtained message to the initiator. Notably, in Blite syn-chronous and asynchronous interactions are rendered in asimilar way (i.e. as pairs of activities inv-rcv and rcv-inv);they are distinguished only by the fact that synchronous in-teractions use the same operation for invoking and receiving.

The declarative part of the asynchronous invoker is:

<?blmADDRESSES {myns => "http://asyncComm";myaddress => "http://XXX:8080/active-bpel/services";

}IMPORTS { asS => "http://asyncComm/asyncServer.wsdl"; }VARIABLES {

<y_id> => asS:req;<y_id,y_msg> => asS:resp;<y_id,y_resp> => gen:response,<id,resp>,<xsd:int,xsd:string>;

}PARTNERLINKS {PARTNERLINK {

TYPE => asS:serverPLT;MY_ROLE client => asS:clientPT;PARTNER_ROLE server => asS:serverPT;

}}?>

The types of the messages corresponding to the asyn-chronous invocation and the related response are importedby the WSDL document of the asynchronous server (iden-tified by the prefix asS). Moreover, while the partner linkto interact with the initiator partner client is automaticallygenerated by BliteC, the partner link to interact with server

must be explicitly declared (the types of the partner linkand the involved ports are again imported from the server’sWSDL document). Hence, the server must be complied first.

We report here an excerpt of the WS-BPEL program corre-sponding to asyncServer

<process name="asyncServerProcess" ... >...<partnerLinks><partnerLink name="serverPL" partnerLinkType="mwl:serverPLT"

myRole="server"partnerRole="client"initializePartnerRole="no" />

</partnerLinks><variables> ... </variables><correlationSets><correlationSet name="x_idCorr" properties="mwl:x_idProp" />

</correlationSets>


<faultHandlers> ... </faultHandlers><sequence><sequence><receive partnerLink="serverPL"

operation="request"variable="var0"createInstance="yes">

<correlations><correlation set="x_idCorr" initiate="yes" />

</correlations></receive><assign> ... </assign>

</sequence><sequence>

<receive partnerLink="serverPL"operation="setClientAddress"variable="var2">


</correlations></receive><assign><copy><from variable="var2" part="address" /><to partnerLink="serverPL" />

</copy></assign>

</sequence><assign> ... </assign><invoke partnerLink="serverPL" operation="response" ... />


To enable asynchronous communication, the translation au-tomatically puts an additional receive activity (highlightedby a gray background) in the generated WS-BPEL code.This activity will be used by clients to communicate theiraddresses, which are then assigned to the partner link usedfor the callback operation. Similarly, in a transparent way,BliteC equips the clients invoking this partner link with thesymmetric invoke activity.

5.3 An auction service scenarioWe show here an application of BliteC to a scenario builtupon the auction service drawn from the WS-BPEL specifi-cation document and already introduced in Section 2.

The auction service is defined in Blite as:

s_auction ::=[ seq

flwrcv <auctionS,seller> submit

<x_auctionId,x_creditCardNumberS,x_shippingCost>|rcv <auctionB,buyer> submit

<x_auctionId,x_creditCardNumberB,x_phoneNumber>wlf;x_amount := 1;inv <register,auction> process <x_auctionId,x_amount>;rcv <auction> regAnswer <x_auctionId,x_registrationId>;x_resp := "Thank you!";flwinv <seller> answer <x_auctionId,x_resp>|inv <buyer> answer <x_auctionId,x_resp>

wlfqes ];;

auction ::= {s_auction}{x_auctionId};;

<?blmADDRESSES {

myns => "http://auction";myaddress => "http://localhost:8080/active-bpel/services";

}IMPORTS { reg => "http://register/register.wsdl"; }VARIABLES {<x_auctionId,x_creditCardNumberS,x_shippingCost>

=> gen:sellerReq,<id,ccNum,cost>,<xsd:int,xsd:string,xsd:int>;

<x_auctionId,x_creditCardNumberB,x_phoneNumber>=> gen:buyerReq,<id,ccNum,phone>,

<xsd:int,xsd:string,xsd:string>;<x_auctionId,x_amount> => reg:regReq;

<x_auctionId,x_registrationId> => reg:regResp;<x_auctionId,x_resp>

=> gen:resp,<id,msg>,<xsd:int,xsd:string>;}PARTNERLINKS {PARTNERLINK {

TYPE => reg:registerPLT;MY_ROLE auction => reg:auctionPT;PARTNER_ROLE register => reg:registerPT;

}}?>

Here, differently from the program in Section2, the endpointreferences of the registration, buyer and seller services arenot explicitly handled by the programmer. Moreover, theonly partner link declared is that used for interacting withthe registration service.

The registration service is rendered in Blite as follows:register ::={[ seq

rcv <register,auction> process <x_id,x_amount>;x_registrationId := "someId";inv <auction> regAnswer <x_id,x_registrationId>

qes ]}{x_id};;

<?blmADDRESSES {

myns => "http://register";myaddress => "http://localhost:8080/active-bpel/services";

}VARIABLES {<x_id,x_amount>=> gen:regReq,<id,amount>,<xsd:int,xsd:int>;

<x_id,x_registrationId>=> gen:regResp,<id,regId>,<xsd:int,xsd:string>;

}?>

Its behaviour is very simple: the process gets instantiated bythe auction service by invoking the operation process; then,the created instance replies with a registration identifier. Forthe sake of simplicity, we do not model here the generationof a unique identifier (which most likely could be providedby another service).

Finally, we report below the seller service (the buyer serviceis defined similarly):v_seller ::=[ seq

rcv <initSeller,initiator> init <x_id,x_cc,x_shipCost>;inv <auction,seller> submit <x_id,x_cc,x_shipCost>;rcv <seller> answer <x_id, x_resp>;inv <initiator> init <x_id,x_resp>

qes ];;

seller ::= {v_seller}{x_id};;

<?blm ADDRESSES {myns => "http://seller";myaddress =>"http://localhost:8080/active-bpel/services";

}IMPORTS { as => "http://auction/auction.wsdl"; }VARIABLES {

<x_id,x_cc,x_shipCost> => as:sellerReq;<x_id, x_resp> => as:resp;

}PARTNERLINKS {

PARTNERLINK {TYPE => as:auctionSPLT;MY_ROLE seller => as:sellerPT;PARTNER_ROLE auction => as:auctionSPT;

}}?>

The above specification is very similar to that of the asyn-chronous client described in Section 5.2.

Once the above programs have been compiled and deployed,regardless of the activation order of the buyer and seller,both services will receive the message Thank you! indicatingthe successful termination of the orchestration.


5.4 An auction service scenario with fault andcompensation handling

We now extend the scenario introduced in Section 5.3 withfault and compensation handling. Basically, we allow thebuyer and the seller services to cancel the auction, whichcauses its unregistration. Thus, the auction service becomes:

invReg ::=seqinv <register,auction> process <x_auctionId,x_amount>;rcv <auction> regAnswer <x_auctionId,x_registrationId>;flwinv <seller> answer <x_auctionId,x_resp>|inv <buyer> answer <x_auctionId,x_resp>

wlfqes;;

compReg ::=seqx_motivation := "Auction cancelled";inv <registerComp> unregister <x_auctionId,x_motivation>

qes;;

fh ::=seqx_resp := "The registration has been cancelled";flwinv <seller> answer <x_auctionId,x_resp>|inv <buyer> answer <x_auctionId,x_resp>

wlfqes;;

s_auction ::=[ seq

flwrcv <auctionS,seller> submit

<x_auctionId,x_creditCardNumberS,x_shippingCost>|rcv <auctionB,buyer> submit

<x_auctionId,x_creditCardNumberB,x_phoneNumber>wlf;x_amount := 1;x_resp := "Thank you!";[invReg @ empty * compReg];rcv <auctionCanc> cancel <x_auctionId>;throw

qes@ fh];;

auction ::= {s_auction}{x_auctionId};;

<?blmADDRESSES {

myns => "http://auction";myaddress => "http://localhost:8080/active-bpel/services";

}IMPORTS { reg => "http://register/register.wsdl"; }VARIABLES {<x_auctionId,x_creditCardNumberS,x_shippingCost>

=> gen:sellerReq,<id,ccNum,cost>,<xsd:int,xsd:string,xsd:int>;

<x_auctionId,x_creditCardNumberB,x_phoneNumber>=> gen:buyerReq,<id,ccNum,phone>,

<xsd:int,xsd:string,xsd:string>;<x_auctionId,x_amount> => reg:regReq;<x_auctionId,x_registrationId> => reg:regResp;<x_auctionId,x_motivation> => reg:unreg;<x_auctionId,x_resp>

=> gen:resp,<id,msg>,<xsd:int,xsd:string>;<x_auctionId> => gen:cancellation,<id>,<xsd:int>;}PARTNERLINKS {

PARTNERLINK {TYPE => reg:registerPLT;MY_ROLE auction => reg:auctionPT;PARTNER_ROLE register => reg:registerPT;

}PARTNERLINK {

TYPE => reg:registerCompPLT;PARTNER_ROLE registerComp => reg:registerCompPT;

}}?>

Once the auction service receives the two requests, it ex-ecutes the scope activity [invReg @ empty * compReg]: the pri-mary activity invReg interacts with the registration service

and then replies to buyer and seller, while the activity compReg

is the corresponding compensation handler that simply in-vokes the registration service to cancel the registration. Af-ter the scope completes, the auction service waits for a can-cellation message by either the buyer or the seller. Thereception of such a message generates a fault (through theactivity throw). The fault is handled by the fault handlerfh that automatically activates the compensation handlercompReg (we refer to [25] for a complete account of the defaultcompensation mechanism) and sends two messages to buyerand seller to notify that the registration has been cancelled.

5.5 Orchestrating non-Blite servicesThe previous examples show how BliteC can be used to gen-erate complete orchestration scenarios where each service isobtained by a Blite specification. However, our tool can bealso used to orchestrate Blite services together with non-Blite ones. To this aim, our specification language providestwo simple constructs, get and set, that permit manipulatingXML messages exchanged with (possibly) non-Blite services.

Consider a service that receives a US zip code and a pref-erence for the temperature scale, i.e. either the characterc for Celsius or f for Fahrenheit, contacts a first servicefor getting the current weather conditions and the temper-ature in degrees Fahrenheit of the city corresponding to thezip code, possibly contacts a second service for convertingdegrees Fahrenheit into degrees Celsius, and finally sendsthe obtained weather and temperature information to theinvoker. To implement this service we have orchestratedtwo web services freely provided by CDYNE [1]. The corre-sponding Blite specification is as follows:

zipWeatherClient ::={[ seq

rcv <initWeatherClient,initiator> init <num,scale,reqWeath>;inv <weather, cb_weather> reqWeather <reqWeath>;rcv <cb_weather> reqWeather <respWeath>;x := get(respWeath, "/wth:GetCityWeatherByZIPResponse

/wth:GetCityWeatherByZIPResult/wth:Description");

x_city := get(respWeath, "/wth:GetCityWeatherByZIPResponse/wth:GetCityWeatherByZIPResult/wth:City");

x_temF := get(respWeath, "/wth:GetCityWeatherByZIPResponse/wth:GetCityWeatherByZIPResult/wth:Temperature");

x := "The current weather at " . x_city . " is: " . x .", the temperature is: ";

if (scale == "c"){seq

reqConv := $litConv;set(reqConv,"/tem:FahrenheitToCelcius

/tem:nFahrenheit") := x_temF;inv <converter, cb_converter> reqConversion <reqConv>;rcv <cb_converter> reqConversion <respConv>;x_temC := get(respConv,"/tem:FahrenheitToCelciusResponse

/tem:FahrenheitToCelciusResult");

x := x . x_temC ." ◦C"qes}

else {x := x . x_temF ." ◦F"};inv <initiator> init <num,x>qes ]}{num};;

<?blmADDRESSES {

myns => "http://zipWeather";myaddress => "http://localhost:8080/active-bpel/services";

}IMPORTS {wth => "http://ws.cdyne.com/WeatherWS/";tem => "http://webservices.daehosting.com/temperature";

}VARIABLES {<reqWeath> => wth:GetCityWeatherByZIPSoapIn;<respWeath> => wth:GetCityWeatherByZIPSoapOut;<num,scale,reqWeath>


=> gen:req, <init,scale,request>,<xsd:integer,xsd:string,(El)wth:GetCityWeatherByZIP>;

<num,x>=> gen:resp, <init,response>,<xsd:integer,xsd:string>;

x_city => xsd:string;x_temF => xsd:decimal;<reqConv> => tem:FahrenheitToCelciusSoapRequest;<respConv> => tem:FahrenheitToCelciusSoapResponse;x_temC => xsd:string;

}LITERALS {litConv => [[<tem:FahrenheitToCelcius

xmlns:tem="http://webservices.daehosting.com/temperature">

<tem:nFahrenheit>0</tem:nFahrenheit></tem:FahrenheitToCelcius>]];

}PARTNERLINKS {

PARTNERLINK {TYPE => gen:weatherPLT;PARTNER_ROLE weather => wth:WeatherSoap,

(reqWeather =>GetCityWeatherByZIP);}PARTNERLINK {

TYPE => gen:converterPLT;PARTNER_ROLE

converter => tem:TemperatureConversionsSoapType,(reqConversion =>FahrenheitToCelcius);

}}

?>

The get construct is used here to extract information fromthe XML messages received from the two external web ser-vices, while the set construct is used to insert the receivedtemperature expressed in degrees Fahrenheit into the XMLrequest message for the converter service, whose structurehas been previously initialized by means of the literal litConv.

Once the program has been compiled and deployed, if weinvoke the operation init by specifying the zip code 90210

and the scale Celsius, we will get back a string of the form:

The current weather at Beverly Hills is: Clear,

the temperature is: 14.4444444 ◦C

6. CONCLUDING REMARKSWe have presented BliteC, a software tool for supporting arapid and easy development of WS-BPEL applications. Thetool aims at solving some well-known programming prob-lems of WS-BPEL caused by its XML syntax, lack of aformal semantics, and non-standardization of the deploy-ment procedure. Basically, BliteC takes as inputs programswritten in Blite, a prototypical orchestration language in-spired to WS-BPEL but with a simpler syntax and a well-defined operational semantics, and provides as output thecorresponding deployable WS-BPEL programs.

The aim of facilitating the development of WS-BPEL ap-plications is shared also by the several graphical editorsthat permit designing WS-BPEL processes, among whichwe mention the designers embedded in Oracle BPEL Pro-cess Manager [5], Intalio|Designer [10], ActiveVOS Designer[7], and Eclipse BPEL designer [9]. Although their use isquite intuitive, developing large applications by using themcan be awkward and annoying compared to the more classictextual approach. Indeed, graphical notations turn out to besuitable for beginner WS-BPEL programmers to representsimple business process workflows, but do not allow more ex-pert programmers to exploit commonly used functionalities,such as e.g. copy/cut/paste, and are inappropriate for ex-pressing some (textual) information, such as e.g. correlationsets. Moreover, graphical designers have a significant nega-tive impact on performance during the programming phase

(that is, indeed, the phase of the software development pro-cess on which we focus on), since they usually are plugins ofheavy software development environments such as JDevel-oper [3] and Eclipse [4]. Some other works with a similar aimare [28, 32, 14]. The first two present some tools that pro-duce WS-BPEL processes starting, respectively, from UML-and Petri Nets-based representations of SOC applications.Due to the use of graphical representations, also these toolssuffer from the problems previously mentioned. Instead, thethird one proposes a mapping from a π-calculus based for-malism into WS-BPEL. In all three approaches, only non-executable WS-BPEL processes are generated, i.e. the gen-erated code should be thought of as a template code where,besides binding and deployment details, programmers havealso to define things such as partner links, variables, porttypes, correlations sets, etc. by editing the generated files.Another related work is [29], which proposes a different ap-proach to develop SOC applications that still relies on aformal language. However, input programs are directly ex-ecuted in a purposely developed engine, rather than beingtranslated into and deployed as WS-BPEL processes.

Currently, the WS-BPEL packages generated by BliteC areintended to be deployed on ActiveBPEL. This is just todemonstrate feasibility of our approach. In fact, BliteC hasbeen designed so that the generation of deployment descrip-tors for different engines can be easily integrated, and weplan to enable it to produce packages also for other freelyavailable engines, such as Oracle BPEL Process Manager,Apache ODE [8] and Beepell [23]. Of course, to preserve thesemantics of the original Blite programs, one has to studythe inner implementation of every supported engine and todefine a customized translation. Since no engine has a for-mal description of its behaviour, this study has to be carriedout by means of experimental tests and, most of all, no for-mal proof of semantics preservation can be done. It is alsoworth noticing that the semantics of Blite, which is in factquite close to that of ActiveBPEL, could be rather toughto render by some WS-BPEL engines, whose semantics maysignificantly differ on low-level implementation details (e.g.message queue handling) or may more strictly (or inappro-priately) enforce some WS-BPEL constraints. For instance,it may happen that a process instance should receive a mes-sage from a partner according to the Blite semantics, whileinstead the message cannot be effectively accepted accord-ing to the semantics of the considered engine, due to e.g.some peculiar correlation constraint. In such a case, BliteCshould identify the potential conflicting receives in the gener-ated WS-BPEL program and, e.g., replace them by a singlereceive enabling some proper coordination activities.

We also plan to enrich the BliteC development environmentpresented in Section 4.1 with further functionalities, suchas deployment/undeployment facilities over remote servers,and debugging tools, such as automatic generation of webinterfaces for invoking the created services and log recordingbased on an embedded dedicated web service. This lattertool could require to extend the syntax of Blite accepted byBliteC with a construct for printing strings into the log thatwould be translated into a WS-BPEL one-way interaction.

For what concern the language Blite, we also intend to in-vestigate its extension to cover some WS-BPEL constructs


that at the time being have been left out, such as timedactivities, event and termination handlers, and more sophis-ticated forms of fault and compensation handling involvingnamed faults and compensation of specified scopes. We donot envisage any major issue in translating such constructsin WS-BPEL code, while their addition to Blite would re-quire to significantly revise the formal definition of the op-erational semantics of the language.

Finally, we intend to develop formal analysis techniques, e.g.based on model checking (as in [14, 15]), for Blite specifi-cations. This way, we would be able to specify in Blite anorchestration scenario, validate its behaviour by using for-mal tools, and deploy it as a set of WS-BPEL programs.

7. ACKNOWLEDGMENTSWe thank Alessandro Lapadula for his fundamental contri-bution to the definition of the language Blite. We also thankthe anonymous reviewers of SAC’10 and Applied Comput-ing Review for their helpful comments, and people attendingthe SOAP track at SAC’10 for the fruitful discussions fol-lowing the presentation of our work. Finally, we thank thechairs of the SOAP track for their invitation to submit tothe Applied Computing Review and their support.This work has been sponsored by the EU project Sensoria,IST-2005-016004.

8. REFERENCES[1] CDYNE Corporation. http://www.cdyne.com/.

[2] jEdit Programmer’s Text Editor 4.3.http://www.jedit.org/.

[3] Oracle JDeveloper.http://www.oracle.com/technology/products/jdev.

[4] The Eclipse project. http://www.eclipse.org.

[5] Oracle BPEL Process Manager 10.1.3, December2007. http://www.oracle.com/technology/bpel.

[6] ActiveBPEL 5.0.2, October 2009.http://sourceforge.net/projects/activebpel502/.

[7] ActiveVOS Designer 5.0.2, June 2009.http://www.activevos.com/.

[8] Apache ODE 1.3.3, August 2009.http://ode.apache.org.

[9] Eclipse BPEL project 0.4.0, May 2009.http://www.eclipse.org/bpel.

[10] Intalio|Designer Community Edition 6.0.1, August2009. http://www.intalio.com/products/bpm/community-edition/designer.

[11] JavaCC 4.2, April 2009.https://javacc.dev.java.net.

[12] JDOM 1.1, April 2009. http://www.jdom.org.

[13] soapUI 3.5, March 2010. http://www.soapui.org.

[14] F. Abouzaid and J. Mullins. A Calculus forGeneration, Verification and Refinement of BPELSpecifications. In WWV, volume 200 of ENTCS, pages43–65. Elsevier, 2008.

[15] F. Abouzaid and J. Mullins. Model-checking WebServices Orchestrations using BP-calculus. InFOCLASA, volume 255 of ENTCS, pages 3–21.Elsevier, 2009.

[16] L. Cesari, R. Pugliese, and F. Tiezzi. A tool for rapiddevelopment of WS-BPEL applications. Technical

report, Dip. Sistemi e Informatica, Univ.Firenze, 2010.

[17] E. Christensen, F. Curbera, G. Meredith, andS. Weerawarana. Web Services Description Language(WSDL) 1.1. Technical report, W3C, 2001.

[18] N. Dragoni and M. Mazzara. A Formal Semantics forthe WS-BPEL Recovery Framework: The pi-CalculusWay. In WS-FM, volume 6194 of LNCS, pages 92–109.Springer, 2010.

[19] G. Erich, R. Helm, R. Johnson, and J. Vlissides.Design Patterns: Elements of ReusableObject-Oriented Software. Addison-Wesley, 1994.

[20] D. Fahland and W. Reisig. ASM-based Semantics forBPEL: The Negative Control Flow. In Abstract StateMachines, pages 131–152, 2005.

[21] A. Ferrara. Web services: a process algebra approach.In ICSOC, pages 242–251. ACM, 2004.

[22] M. Gudgin, M. Hadley, and T. Rogers. Web ServicesAddressing 1.0 - Core. Technical report, W3C, May2006. W3C Recommendation.

[23] T. Hallwyl, F. Henglein, and T. Hildebrandt. Astandard-driven implementation of WS-BPEL 2.0. InSAC, pages 2472–2476. ACM, 2010.

[24] S. Hinz, K. Schmidt, and C. Stahl. TransformingBPEL to Petri Nets. In Business Process Management,volume 3649 of LNCS, pages 220–235. Springer, 2005.

[25] A. Lapadula, R. Pugliese, and F. Tiezzi. A formalaccount of WS-BPEL. In COORDINATION, volume5052 of LNCS, pages 199–215. Springer, 2008.

[26] N. Lohmann. A Feature-Complete Petri NetSemantics for WS-BPEL 2.0. In WS-FM, volume 4937of LNCS, pages 77–91. Springer, 2008.

[27] R. Lucchi and M. Mazzara. A pi-calculus basedsemantics for WS-BPEL. J. Log. Algebr. Program.,70(1):96–118, 2007.

[28] P. Mayer, A. Schroeder, and N. Koch. Mdd4soa:Model-driven service orchestration. In EDOC, pages203–212. IEEE, 2008.

[29] F. Montesi, C. Guidi, and G. Zavattaro. ComposingServices with JOLIE. In ECOWS, pages 13–22. IEEE,2007.

[30] OASIS WSBPEL TC. Web Services Business ProcessExecution Language Version 2.0. Technical report,OASIS, April 2007.

[31] C. Ouyang, E. Verbeek, W. van der Aalst, S. Breutel,M. Dumas, and A. ter Hofstede. Formal semantics andanalysis of control flow in WS-BPEL. Sci. Comput.Program., 67(2-3):162–198, 2007.

[32] W. M. P. van der Aalst and K. B. Lassen. Translatingunstructured workflow processes to readable BPEL:Theory and implementation. Information & SoftwareTechnology, 50(3):131–159, 2008.

[33] M. Weidlich, G. Decker, and M. Weske. EfficientAnalysis of BPEL 2.0 Processes Using π-calculus. InAPSCC, pages 266–274. IEEE, 2007.


About the authors:

Luca Cesari is a student in Scienza e Tecnologia dell'Informazione at the University of Florence. He received a Master degree in Computer Science from the University of Florence (April 2009) with the thesis "Design and implementation of a tool for supporting the development of WS-BPEL applications" supervised by Prof. Rosario Pugliese and Francesco Tiezzi. His current interests focus on type systems, model checking and service-oriented systems.

Rosario Pugliese received a Laurea degree cum laude in Scienze dell'Informazione from the University of Pisa (April 1991) and a Ph.D. degree in Computer Science from the University of Rome `La Sapienza' (November 1996). Pugliese is with the Dipartimento di Sistemi e Informatica. He is associate professor of Computer Science at the Facoltà di Scienze Matematiche Fisiche e Naturali (School of Science) of University of Florence since 2002. He has been assistant professor in the same School since 1999. Previously, he has benefited from research fellowships and contracts funded by the National Research Council (CNR) and by the University of Florence. Pugliese research interests are centered around formal methods and tools (process calculi, behavioural equivalences, type systems, modal logics) for specification and verification of concurrent and distributed systems. His current research focusses on Global Computing and Service Oriented Computing.

Francesco Tiezzi received a Laurea degree cum laude in Informatica from the University of Florence (January 2005) and a Ph.D. degree in Computer Science from the same university (April 2009), under the supervision of Prof. Rosario Pugliese. Previously, during 2005, he had a Post-degree collaboration with the Dipartimento di Sistemi e Informatica of the University of Florence. Since 2009, Tiezzi is a Post-doc at the same department. Tiezzi's research interests include semantics of languages for Service-Oriented Computing, process calculi, type systems, models and tools supporting specification and verification of service-oriented systems, and web-based programming languages.


Register-Relocation: a Thermal-aware Renaming Method for Reducing Temperature of a Register File

Jungwook Kim Department of Computer Science and Engineering Seoul National University

Seoul 157-144, Korea

[email protected]

Seong Tae Jhang* Department of Computer The University of Suwon Gyeonggi-do 445-743,

Korea

[email protected]

Seung-Jin Moon Department of Computer The University of Suwon Gyeonggi-do 445-743,

Korea

[email protected]

Chu Shik Jhon Department of Computer Science and Engineering Seoul National University

Seoul 157-144, Korea

[email protected]

ABSTRACT

The manufacturing process of microprocessors becomes

increasingly fine and the clock frequency is rapidly growing.

Since the corresponding power consumption, however, is not

reduced, power density is increased dramatically. The generated

heat by the power density induces high temperature. The high

temperature causes many problems: calculation errors, aging,

leakage power, and cooling costs. Register file produces the

highest temperature in a microprocessor because of extremely

high access frequency and its small area. We demonstrated that

the existing renaming unit causes high temperature since it

allocates registers imbalanced. Our idea is to redistribute evenly

register allocations and accesses across the full range of the

register file; consequently, the overall power density is reduced

and then the temperature is lowered. The proposed method can be

implemented by adding a small logic to the traditional renaming

unit with around 1.5% overheads. As a result, temperature drop

was up to 10.4°C (11%) on average 4.6°C (6%). We also achieved

leakage power savings and performance improvements by the

temperature drop.

Categories and Subject Descriptors

C.1.0 [Processor Architectures]: General

General Terms

Design, Experimentation

Keywords

Register File, Temperature Reduction, Register Relocation,

Embedded Processor

1. INTRODUCTION In recent years, it has been able to integrate a great number of

transistors to limited space on the chip due to development of

semiconductor manufacturing technology. Accordingly, current

microprocessors show more features and faster performance in

spite of the smaller area compared to the older microprocessors.

While the physical size of the microprocessors becomes

progressively smaller, the power consumption requirements are

rarely reduced because the software increasingly demands high

performance. Thus, the power density on the microprocessor is

rapidly increased, and the high temperature caused by this

increase brings about many problems: malfunction, poor

durability, increased leakage power, and cooling costs. Low-

power processors used in embedded devices are not free from the

thermal problems as well as high-performance microprocessors

for servers; moreover, this issue may be intensified in the future.

For this reason, many studies have been introduced to lower the

temperature in microprocessors.

Among the studies, the most common technique is the Dynamic

Thermal Management (DTM). The technique adjusts the

operating frequency or the voltage of a microprocessor, or it

regulates the instruction-fetch to control the temperature. The

most common mechanism is as follows. The processor

temperature is monitored in real-time. If the temperature rises

above a predetermined threshold temperature, the operating

frequency or the voltage of the processor is scaled, or the

instruction-fetch is suspended until the temperature goes down to

a safe point below the emergency temperature. As the instruction

pipeline is slowly performed or suspended by this control, the

power consumption of each unit in the microprocessor is

dramatically reduced and then the temperature is decreased. When

the temperature goes down to a safe area below the critical point,

the clock frequency or the voltage is increased again or the

instruction-fetch is restarted to operate in normal speed. Since the

DTM is such an effective dynamic temperature control, a number

of different methods have been introduced and studied. For

example, Skadron et al [1] proposed various DTM techniques:

“temperature-tracking” frequency scaling, localized toggling, and

migrating.

While the DTM is widely applied in many places and many

studies are in progress, the performance loss is inevitable. The

more frequent the temperature-controlled intervention becomes,

the slower the microprocessor is. As DTM is a piece of software

at the expense of the performance, the need for research about that

have to adopt a temperature resistant structure to suppress high

temperature from the design stage of a microprocessor has been

emerged. In terms of the microprocessor architecture, the register

file shows the highest power density as it has a severe access

frequency and occupies a relatively small area. As a result, the

register file is known to the hottest unit in the microprocessor. For

this reason, several studies have been introduced to reduce the

power density of the register file [2][3][4]. Among the studies,

especially, we paid attention to Zhou et al [3]. They showed that

Permission to make digital or hard copies of all or part of this work for

personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that

copies bear this notice and the full citation on the first page. To copy

otherwise, or republish, to post on servers or to redistribute to lists,

requires prior specific permission and/or a fee. *corresponding author


what makes the register file the hottest unit is mostly due to the

highly clustered register file accesses where a set of few registers

physically placed close to each other are accessed with very high

frequency, and they proposed a compiler-based register re-

assignment technique which purpose is to break groups of

registers and to uniformly distribute the accesses to the register

file. We were interested in such information and then found that

accesses and allocations of the register file actually were not

conducted uniformly through a preliminary investigation.

Furthermore, we demonstrated that the method of the traditional

renaming unit caused the non-uniformity. Figure 1a shows this

uneven distribution of register accesses and allocations. The x-

axis corresponds to the entry number of the register file.

Typically, the operation of a renaming unit is as follows. If the

output dependency is not resolved when the register-writing is

executed, the renaming unit allocates a new free entry of physical

registers to the register scheduled to be written. However, as can

be seen from Figure 1a, the highly clustered accesses were found

on the only one side of the register file by our preliminary

experiments. This can be seen that the existing renaming unit was

not designed to consider the power density and temperature.

Figure 1b presents an example of the emergency temperature due

to this highly clustered pattern on the right side.

In this paper, we propose an idea that evenly redistributes

accesses to the full range of the register file through the

improvement of the traditional renaming unit. The idea can be

implemented by attaching only a small logic to the traditional

renaming unit. The detailed method and operation of the attached

logic will be described in Section 2.2. If the redistribution lowers

the power density of the register file, the temperature will be

reduced. The temperature drop of the hottest unit may bring a

positive effect to lower the entire temperature of the

microprocessor. In addition, many benefits are expected due to the

decreased temperature. First, leakage power savings are expected.

Then, the performance improvement is expected since the

performance loss by DTM-intervention will be disappeared

because many hotspots can be removed if the temperature

decreases to a safe area below the emergency point. Last of all,

the chip durability may be less affected and the cooling costs

savings are expected.

The proposed method by us has some distinctive advantages in

comparison with conventional techniques. As our technique is not

a static method dependent on the compiler but a dynamic scheme

using hardware logic, the development potential remains. By

adding some functions to our logic in the future, it can respond to

thermal behavior in real-time according to the operating

characteristics of the program. For example, by such a fixed way

of a static method based on the compiler or lowering the power

density by changing the placement of wires connected to the

register file, it will be impossible to cope with the malicious attack

such as the thermal virus. The malicious code can cause even

greater problems if it attacks by taking advantage of the fixed re-

assignment structure. In contrast, our method could be the

favorable way to the malicious code as the functionality of our

logic can be improved to adequately respond while the program

behavior is monitored in real-time.

2. REGISTER RENAMING

2.1 Conventional Renaming Method Generally, modern superscalar processors have 32 architectural

registers and more than 32 physical registers. For example, in

Alpha 21264 processor, which has been representative as a high-

performance microprocessor and was selected for our

experimental target, the physical integer register file has 80 entries.

Its higher part (i.e. 0–39 entry number) consists of 32 architectural

registers and 8 shadow registers, and the other part (i.e. 40–80

entry number) is used as physical registers for the allocation of

writing.

The register renaming is a technique which preserves “program

order” against data hazards; the hazards occur among two

instructions using the same register or memory location. For

example, consider two instructions I1 and I2; I1 and I2 are “load r1,

r2, r3” and “add r2, r4, r5”, respectively; I1 occurring before I2 in

program order. Commonly, a less time-consuming instruction is

executed before a long-time instruction in an Out-of-Order

microprocessor. Since the “load” instruction of I1 takes more time

than the “add” instruction of I2, I2 will be executed before I1. Thus,

I2 may try to write r2 register before it is read by I1, so I1

incorrectly gets a new value (i.e. WAR hazard is occurred). In

such a case, the renaming logic assigns the second r2 register to a

free physical register within the range of 40–80 entry numbers;

(a) Access count (b) Thermal map

Figure 1 (a) Imbalanced accesses in gzip (b) Temperature emergency due to the imbalanced accesses

-

2

4

6

8

10

12

14

16

18

20

0 4 8 12 16 20 24 28 32 36 40 44 48 52 56 60 64 68 72 76 80

Access

Co

un

t x

1,0

00

,000

entry number

writes reads

42


hence, I2 writes the value to a new destination and I1 gets the

correct value. Consequently, the program order is preserved by

the renaming technique.

However, from our simulation, we found that the most

assignments by the conventional renaming scheme clustered on

one side of the register file, and it caused high temperature. Since

the assignments for register writing are fixed to the only half

range (i.e. 40–80 entry number), and accesses for writing hold a

considerable portion in the total accesses, the power density in the

right side of the register file is rapidly increased. As a result, the

maximum temperature appears in that region; moreover, the

hotspots (i.e. emergency temperature points) are also created.

Figure 1a shows an example of the concentrated accesses on the

half of the physical registers in gzip program; the x-axis

represents an entry number of the physical registers. Figure 1b

shows an example of the thermal map (e.g. gzip); the steady-state

temperature rises to the hotspot point (e.g. 90°C) in the right part

of the registers.

On the other hand, if the renaming unit assigned a register with

a consideration of power density, the temperature of the register

file would be decreased, and the number of DTM interventions

also would be reduced. In other words, if the allocations for

register writing were distributed uniformly to the full range of the

register file, then the writing accesses also were distributed

uniformly; consequently, the power density and temperature

would be decreased and the performance loss also would be

reduced.

2.2 Proposed Method: Register Relocation The goal of our idea is the reduction of the temperature in a

register file. The goal may be achieved by uniformly distributing

accesses throughout the full-entries of the registers. Our idea is a

re-mapping technique revealing that architectural registers (i.e.

entry number 0–40) are relocated to the full range of entry

numbers (i.e. 0–79) with only the even number allocation, and

also that the assignments to physical registers (i.e. 40–80) are also

repositioned throughout whole register file area (i.e. 1–80) with

the odd number. Our strategy is as follows:

First, the traditional renaming unit allocates an index number of

a physical register entry to an architectural register. Next, a new

index number is generated by our simple algorithm: if the index

number is less than 40, then a new index number will be obtained

from multiplying the first index number by 2; otherwise (i.e. 40–

80), we subtract 40 from the first index and multiply the

subtracted value by 2, and „1‟ is added. This simple algorithm can

be implemented by a small logic, and the logic can be attached to

the traditional renaming unit; the attached logic consists of six

small components: an eight bit adder, an eight bit shift register, a

comparator, an OR gate, and two 2:1 muxes. Our algorithm can be

expressed as follows.

Their detailed operations are described as follows. At first, the

comparator checks if the first index number is less than 40 and

passes the result to two 2:1 muxes. The adder subtracts 40 from its

input data and sends it to the first 2:1 mux. The first 2:1 mux

selects an input with the result signal of the comparator and

forwards it to the shift register. The shift register does a multiply

by shifting only one bit (e.g. 2*x). The OR gate does the “+1”

operation within “2*i+1”. The OR gate receives two inputs: a

multiply result from the shift register and the constant number „1‟,

and then it does the OR operation with the two inputs; the OR

gate sends its result to the second 2:1 mux. The second 2:1 mux

Figure 2 The proposed small logic attached to the traditional renaming unit and our mapping scenario

/ 2C Full entry

if i C

2 ( ) 1i i C

else if i C

2i i


receives two inputs from the shift register directly and the OR

gate, and it selects one input with the result signal from the

comparator; finally, it forwards the selected input to the output

port connected to the next pipeline stage. Figure 2a shows this

new logic structure, and Figure 2b describes our mapping scenario;

the higher part and the lower part of the original entries are

relocated to the even entries and the odd entries, respectively.

3. EXPERIMENTAL RESULTS

3.1 Simulation Parameters Our simulation environment targets the Alpha 21264

microprocessor. The parameters of the simulation were brought

from the Alpha 21264 processor core [5]. Table 1 reports the

configuration that was assumed in our simulations.

3.2 Methodology For more precise simulations, we used Sim-alpha [6] as a main

simulator. Since the floorplan file [1] of the Alpha21264 was used

in our thermal experiments, we needed more accurate simulations

on the Alpha Processor.

The Sim-alpha simulator is based on the SimpleScalar [7], but

it simulates the Alpha core more accurately than the SimpleScalar.

While the SimpleScalar provides only a Register Update Unit

(RUU) integrating many essential units (e.g. renaming logic, issue

queue, reorder buffer), the Sim-alpha provides many essential

logics individually and then implements them with more detailed

behaviors. Especially, it is quite a help to our simulation that the

relation between the architectural registers and the physical

registers is obviously separated and defined, and the realization of

the renaming map table and the reorder buffer is relatively exact,

compared with the SimpleScalar.

Our power consumption models referred to the models of

Wattch [8]. The parameters of our power model followed the 65

nm technology guided by International Technology Roadmap for

Semiconductors (ITRS). Our floorplan file for the thermal

experiments also was fitted to 65 nm scales; the die size of the

microprocessor core is 36 mm2.

Temperature simulations were conducted by HotSpot [9] with

power trace files which were generated from Sim-alpha and

Wattch. For more exact simulations, every power trace file was

simulated as twice; at first, the steady-state temperature was

obtained by the first thermal simulation, and it was used as the

initial temperature for the next phase of the thermal simulation.

This two-phase process is a typical method in HotSpot simulator.

We used benchmark programs from SPEC CPU2000 [10]. For

the experiments efficiency and reducing the simulation time, we

used fast-forwarding data from SimPoint [11]. SimPoint provides

fast-forwarding data by analyzing each characteristic of

SPEC2000 benchmark programs. In other words the study is that

the results of unique segments are little difference with the results

of whole sectors. Accordingly, the time of unnecessary

experiments can be considerably saved.

Table 1. Simulation Parameters

Instruction Fetch Queue Size 4

Instruction Fetch Queue Width 4

Instruction Fetch Queue Speed 1

Map(Rename) Width 4

Issue Width 4

Commit Width 11

Branch Predictor Tournament Predictor

Reorder Buffer Size 80

Load Queue Size 32

Store Queue Size 32

Issue Queue Size : INT / FP 20/15

L1 I/D Cache 512 sets, 64Byte Block, 2Way

Fast forwarding Data by SimPoint

Clock speed 3.0Ghz

Technology 65 nm

Figure 3 Steady-state and Peak temperature reductions

55

60

65

70

75

80

85

90

95

100

105

bzip2 crafty eon gap gcc gzip mcf parser perlbmk twolf vortex vpr avg

Tem

per

atu

re (°C

)

steady-base steady-RR peak-base peak-RR


3.3 Results and Discussion We conducted the experiments by dividing into the integer

programs and the floating-point programs, and we summarized

the results by measuring the maximum temperatures of the steady-

state and the transient state in each result of the program.

First, we get the power consumption file of each unit over time

through the main simulator. Next, the results of the temperature-

simulation can be achieved by putting the power consumption file

and the floorplan file of the microprocessor as the input of the

HotSpot simulator. The achieved results consist of the thermal

map of the steady-state temperature and the recorded trace-file of

the temperature changes over time.

First, we will analyze the results of the integer programs. Then

the results of the floating-point programs will be discussed in

Section 3.4.

Figure 3 shows temperature changes of each program in the

integer register-file. The left two bars present the comparison of

the existing method and our method in steady-state temperature,

and the right two bars show the comparison in peak temperature.

As can be seen in Figure 3, our method shows the same effect on

the temperature reduction of the steady-state as well as the peak

temperature. Especially, in case of gcc program, the best results

are shown as the reduction above 10°C both the steady-state and

peak temperature. In whole programs the average reduction of

steady-state temperature was 4.6°C, and that of peak temperature

was 4.7°C. If the emergency temperature is defined as 80°C, in

the steady-state temperatures, four programs are exceeding the

emergency point: bzip2, crafty, gcc, and gzip. In the peak

temperatures, three programs have been added to the early four

programs: gap, parser, and twolf; therefore, total seven programs

are exceeding the emergency temperature. Finally it can be seen

that the average of the peak temperatures is already exceeding the

emergency temperature. In spite of such high peak-temperatures,

because our method has the effect of reducing the peak

temperature as well as the steady-state temperature, it can be

found in the right bars of Figure 3 that the average of the peak

temperature has been decreased below the critical temperature.

Figure 4 shows an example that discusses a cause of the

temperature reductions in terms of thermal map, and it reveals that

the heating pattern of gcc program has been changed. Figure 4a

presents the heating pattern which was created by the imbalanced

register-allocation of the existing method. Like the example of

Figure 1a, it depicts severely increased temperature by high power

density of the right part, and a big thermal gradient also may be

created by steep temperature differences between the left and the

right; it is known that the thermal gradient is harmful to the

durability of a circuit. In contrast, as shown in Figure 4b, the

maximum temperature of steady-state also has been considerably

reduced, and the overall heating pattern is uniform. These results

also may be due to our register-relocation method. In addition, it

can be expected that such a uniform pattern lowers the likelihood

of a steep thermal gradient.

While Figure 4 shows the thermal map of steady-state

temperature, Figure 5 shows the temperature changes over time in

gcc program. In three-dimensional coordinate of Figure 5, x-axis

displays entry numbers of the register file; y-axis shows the

execution cycles over time; and z-axis corresponds to the

temperatures of each entry. Figure 5a shows the temperature

changes of the register file by the existing register assignment

method. In this case, it cannot be found that the peak temperature

goes down below the emergency point (e.g. 80°C) during whole

execution cycles. In previous section of near 300 (x 100k) cycles

point, it can be seen that in the right side of the register file, the

temperature has been severely increased enough to exceed 100°C;

in contrast, temperature of the left side is about 70°C; thus, the

temperature difference is more than 30°C between the left side

Figure 4 Thermal map of steady-state temperature in gcc

(a) base – gcc (b) Register Relocation - gcc

Figure 5 Temperature distribution and change over time in the register file


and the right side. Accordingly, it can be easily expected that the

thermal gradient by the sudden difference will be a significant

damage to the lifetime of the register file. The maximum of the

peak temperatures is kept above the emergency point even in the

next section after the 300 (x 100k) cycles point. In that section,

also it can be found that the difference is about 30°C compared to

the lowest temperature.

Consequently, the existing renaming method causes the

continuous high temperature and the extreme difference of

temperature. Generally, the thermal gradient by the sudden

difference is a cause of the thermal-cycling creation. Rapid

thermal-cycling between hot point and cold can damage the chip

by giving the thermo-mechanical stress to a circuit [12] [13].

Therefore if programs such as gcc are continuously performed, the

microprocessor cannot avoid a severe damage of the register file

circuit as well as the performance loss.

On the other hands, in case of our method, Figure 5b shows

some stable heating pattern. In section before the 300 (x 100k)

cycles, though the maximum temperature is seen above 80°C, the

heating-pattern is shown as the uniform distribution compared to

Figure 5a. Of course, in such a uniform heating pattern, the

created thermal-gradient will be very small enough to ignore the

impact to the circuit. Also the maximum temperature of this

section has been considerably reduced after the 300 (x 100k)

cycles point, and the uniform heating-pattern is being kept. Since

the maximum temperature is below the emergency point, the

performance loss by DTM-intervention will not occur.

Accordingly, it can be seen that our method has many

advantages in the overall comparison. First, the decrease of

steady-state and peak temperature leads to relative performance

improvements by minimizing DTM; in addition, it is expected to

save the leakage power by the reduced temperature. Second, it is

expected that the uniform heating pattern contributes to extend the

lifetime of the register file circuit by minimizing the thermal

gradient creation.

However, the result of “vortex” program is quite different with

other programs; the temperature rose instead of falling. Our

analysis for this fail is as follows. Two important reasons can be

considered. First, in most applications, the access count of the

R31 register is a considerable portion in the total accesses; the

R31 register is the 32th entry of the register file and used as “zero

register”. Second, in vortex, the access count of R31 register is

relatively greater than others (e.g. the percentages are 8% and 3%

in vortex and gcc, respectively). In other words, the number of

accesses of the 32th entry (i.e. R31 register) gives vortex more

impact. In such a case, since some frequently accessed entries are

relocated near R31 register entry by our proposed method, the

power density near R31 register may be inevitably higher than the

existing register file compared with other applications. Figure 6a

and 6b shows that the position of the maximum temperature

region was changed by our method. Also, from Figure 6c and

Figure 6d, the change of access-density between the existing

method and our method can be observed near R31 register. In

such a case, a more dynamic control may be required and for

future work, we will study a smarter scheme.

3.4 Results of Floating-Point Programs Figure 7 shows the results of floating-point programs in the

integer register file. The left two bars indicate the maximum

temperatures of the steady state, and the right two bars show the

maximum temperatures of the transient state. As can be seen, the

overall resulting temperatures are lower than the integer programs.

Since the floating-point programs have the high utilization of the

floating-point register file as well as the integer register file, the

access to the register file may be distributed on both sides. Also,

from the bar 2 and 4, it can be found that the effect is not high

though our method has been applied. This may be due to that the

overall temperature is low and the emergency situations are hardly

ever occurred. An example of this can be seen from Figure 8.

Figure 8 shows the temperature-changes according to the

execution cycles of equake which is one of the floating-point

programs. As shown in Figure 8, the characteristic of the equake

(a) Thermal map - base (b) Thermal map - RR

(c) Access counts in register entries - base (d) Access counts in register entries - RR

Figure 6 Exceptional result in vortex

0

50

100

150

200

250

300

350

0 5 101520253035404550556065707580

x 1

00

,00

0

0

50

100

150

200

250

300

350

0 5 101520253035404550556065707580

x 1

00

,00

0


program is depicted as a unique pattern that the access count to

the register file is suddenly increased for short time at regular

intervals. In this case, from Figure 8a, also it can be seen that the

access are clustered to the right in the existing register file;

however, the temperature difference between the clustered right-

part and the non-clustered left-part is not greater than the integer

programs. Thus, though the imbalanced access have been

uniformly distributed by our method, the temperature drop is

actually not large; however, though the gap of temperature drop is

small, it can be found that the steepness of the thermal gradient is

considerably mitigated in Figure 8b compared to Figure 8a. Also

such an alleviated gradient may be helpful to the durability of the

register file.

In addition, as can be seen in Figure 7, because there is no case

of exceeding the emergency point in the peak temperatures,

according to this, the performance loss by DTM will not occur.

Since this is the results from the integer register-file used by

floating-point programs, we will monitor the temperature changes

again through the experiments of the floating-point register file

for the future work. Also, as shown in the equake result of Figure

7, though the overall steady-state temperature belongs to the very

low side, it needs to be remembered that there is a unique program

such as the equake which has the high difference between the

peak temperature and the steady-state; the difference is almost

close to twice. Unless we prepare to such a unique pattern, the

circuit may be damaged by the instantly sudden rise of

temperature. Even if this occurs, as can be seen in Figure 8, our

method may alleviate the damage to some extent.

3.5 Leakage Power and Performance Leakage power is closely related to temperature. Generally, it is

known that leakage power is exponentially increased by

temperature rise. It is predictable that the leakage power may be

reduced since the steady-state temperature was decreased by our

method in the register file. We used HotLeakage [14] tool for

calculating the leakage power, and the results can be seen from

Figure 9a and Figure 9b. In most cases except one, the significant

reductions of the leakage power are achieved, and the power

saving is up to 24% on the average 13%. As described on the

Figure 7 Steady-state and Peak temperature reductions of Floating-Point Programs

(a) base (b) Register Relocation

Figure 8 Temperature changes over time in equake

45

50

55

60

65

70

75

80

ammp applu apsi art equake facerec galgel lucas mesa mgrid sixtrack swim wupwise avg

Tem

per

atu

re (°C

)

steady-base steady-RR peak-base peak-RR


Section 3.3, since vortex showed the negative result from the

temperature rise, the leakage power grew up at the rate of the

temperature increase.

In addition, we can consider the benefit of performance

improvement; as our logic eliminated several hotspots, the

number of DTM-intervention will be reduced. The performance

evaluation was carried out in limited four cases exceeding the

emergency point: bzip2, crafty, gcc, and gzip. Because none of the

other programs exceeded the emergency point, any performance

drop will not exist; thus, it may be enough to analyze the only four

cases. The emergency temperature was assumed to 80°C, and the

used DTM technique reducing the temperature was the fetch-

throttling. The fetch-throttling is a DTM scheme that suspends the

instruction fetch if the temperature exceeds the emergency point

until the temperature goes down to a safe area below the

emergency point while the temperature is monitored. During the

fetch stop, access counts to the register file will be reduced

considerably; hence, the power density of the register file will be

lowered, and the lowered power-density will lead to the

temperature drop. However, such a DTM technique stopping the

instruction pipeline decreases the Instruction Per Cycle (IPC)

severely; therefore, the execution time for the given instructions

will be significantly extended. Due to the extended time, the

processor performance suffers severe damage. On the other hands,

since the temperature of the register file is reduced by our

architectural approach, the case beyond the critical temperature is

extremely rare even in the most execution time. In other words,

our method brings about the blocking effect; it fundamentally

blocks a bad luck due to the performance loss by DTM. Figure 9c

and 9d reports such a contrast result between the existing method

and the proposed method, and Figure 9d presents the degree of the

relative performance improvement due to the difference with

Figure 9c.

Figure 10 shows the comparison of temperature changes over

time under DTM-intervention between the existing method and

our method. In other words, it shows the monitored results of the

(a) Normalized leakage power

(b) Leakage power reduction

(c) Instructions per cycle (d) Speed up

Figure 9 Leakage power reduction and Performance improvement under DTM intervention

0.6

0.7

0.8

0.9

1

1.1

1.2

Norm

ali

zed

Lea

kag

e

Pow

er

base RR

24%

13%

-20%

-10%

0%

10%

20%

30%

Lea

kag

e P

ow

er

Red

uct

ion

0

0.2

0.4

0.6

0.8

1

1.2

1.4

1.6

bzip2 crafty gcc gzip avg

IPC

base RR31.4%

24.8%

0%

5%

10%

15%

20%

25%

30%

35%

bzip2 crafty gcc gzip avg

Sp

eed

up


temperature changes and performance loss by DTM; when the

temperature exceeds the emergency point, DTM reduces the

temperature of the register file by stopping the instruction fetch or

by lowering the clock frequency. Figure 10a shows the

temperature changes and the performance loss through the

existing method, and Figure 10b shows the degrees of the

temperature changes and the performance loss in the case of

adopting our register-relocation method. First, In Figure 10a, the

overall heating pattern is shown as the imbalanced form of the

clustered access on the right side of the register-file as shown in

the previous examples; thus, the maximum temperature is higher

than Figure 10b. Also the initial temperature is formed highly as

87°C; accordingly, the DTM-intervention is immediately started

due to the initial temperature exceeding the emergency

temperature. The temperature of the register file starts to fall by

stopping the instruction-fetch. It can be found that the temperature

decreases below 80°C after 10 (x 100k) cycles as it rapidly goes

down until about 10 (x 100k) cycles. Since the temperature

dropped below the emergency point, the instruction-fetch is

normally started again; however, the temperature of the register

file will soon increase above 80°C by the restarted instruction-

fetch. Then, DTM-intervention is triggered once again, the

temperature falls again to below 80°C. As such a process

continuously is repeated, the execution cycles of the instructions

go on. Thus, from 10 (x 100k) cycles to 80 (x 100k) cycles in

Figure 10a, it can be seen that the pattern like a saw blade is

repeated. In other words the temperature is going up and down as

the zigzag pattern around 80°C by DTM. Thus the execution time

is increasingly extended; consequently, in Figure 10a, the

execution time is spent about 110 (x 100k) cycles for finishing the

given instructions.

Now let us look at the results of our relocation method in

Figure 10b. As expected, it can be seen that the initial temperature

is lower than Figure 10a; however, since there are some cases of

exceeding 80°C, DTM is triggered at each time of the exceeding.

Thus some patterns of the saw blades can be seen until about 20

(x 100k) cycles. But it is confirmed that because the saw blades

patterns around 80°C are hardly seen after 20 (x 100k) cycles,

there is little DTM-intervention compared to Figure 10a; therefore,

the relative performance improvements can be expected compared

to Figure 10a. As expected, this is due to the reduction of the

maximum temperature since the overall temperature is distributed

uniformly by our relocation technique. Consequently, the finished

execution cycles are about 85 (x 100k) cycles, and the finished

time is shorter than Figure 10a; accordingly, the performance of

the processor will be relatively improved.

3.6 Overheads Since our proposed logic consumes some power itself, it is

necessary to consider the costs of our logic. The power model of

our logic referred to that of CACTI [15] and Wattch [8], and it

was scaled to the technology of 65 nm. As the eight-bit adder and

shift register consumes a big portion of the power, the attached

logic increases the power consumption of the original renaming

unit to 25%. However, since the power consumption of the

existing renaming logic is relatively much smaller than the

register file, the additional power consuming of our logic occupies

only a trivial portion in the whole power consumption; the overall

power consumption includes the consumption of the register file

and that of the novel renaming unit.

Similarly, another overhead has to be considered in terms of

temperature. As the area of a renaming unit is wider than a

register file and the power consumption is quite smaller than the

register file, the power density of the novel renaming unit is much

lower than the register file; thus, it is expected that the

temperature rise will be truly limited. From Table 2, it can be seen

that the additional power consumption and the temperature

increase are extremely slight.

Moreover, as it is considered that the reduction of leakage

power and the performance improvement can be achieved by our

logic, the relative overheads can be smaller.

Table 2 Attached logic overheads

Overheads Normalized increase (%)

Power

(register file + renaming unit) 1.47

Temperature (renaming unit) 1.60

(a) Base (b) Register Relocation

Figure 10 Temperature changes and Thermal Map under DTM intervention in crafty


4. RELATED WORKS Activity Migration [4] moves operations to multiple clones of

register file when the emergency temperature is occurred. Thus

the temperature of the previous unit can be decreased. But the

migration overheads and area overheads exist and the migration

overheads may damage the performance since the register file is

time-critical. Active Bank Switching [2] proposed that only a few

registers are active enough in the CPU cycles because not all the

registers are used during the execution time. X.Zhou, et al.

proposed the Compiler-driven Register Reassignment [3]. They

evenly redistribute clustered registers to reduce the power density

and temperature. But their method is the static one based on

compiler and they only focused on the architectural registers. As

can be seen until now, full-fledged research about the thermal-

aware register file is not much yet.

5. CONCLUSIONS The power density is rapidly being increased from high-

performance microprocessors for servers to low-power embedded

processors for mobile devices. Accordingly, generated heat and

high temperature produce many thermal problems: malfunction,

aging, leakage power, and cooling costs as well as the

performance loss. The register file is the hottest unit of a

microprocessor, and we have proposed a new renaming method

for reducing temperature in the register file. Our idea can be

implemented by adding a small logic to the traditional renaming

unit and showed some results with around 1.5% overheads both

power and temperature.

Our proposed method evenly redistributes allocation and access

of the register file; ultimately, it lowers the overall power density

for reducing the temperatures of the register file. As a result, we

leaded to the temperature reductions reaching up to 10.4°C (11%)

on average 4.6°C (6%); accordingly, hotspots were removed in

some benchmark programs. The removed hotspots significantly

reduces the performance loss by DTM-triggering; consequently,

relative performance improvements reached up to 31.4% on

average 24.8% compared to the traditional method. In addition,

since leakage power is proportional to the exponential function of

temperature, some leakage power reductions were obtained due to

the temperature drop. Leakage power savings reached up to 24%

on average 13%.

The dynamic renaming techniques proposed by us have

produced some results with low overheads. Moreover, our logic

may be able to cope with malicious attacks (e.g. thermal virus

[12]) which may occur in the future because our logic has many

chances to enhance the functionality by adding the appropriate

response techniques in accordance with each application. For

future work, we will continue to conduct research in this area.

6. ACKNOWLEDGEMENTS This work was supported by the GRRC program of Gyeonggi

province. [(GRRC SUWON2010-B1), CCTV Image Based

Context-Aware Process Technology]

7. REFERENCES [1] K.Skadron, M.R.Stan, K.Sankaranarayanan, and W.Huang,

Temperature aware Microarchitecture, In Proc. ISCA, San

Diego, California, USA. June 11-13, 2003.

[2] K.Patel, W.Lee and M.Pedram, Active bank switching for

temperature control of the register file in a microprocessor,

In Proc. GLSVLSI, Stresa-Lago Maggiore, Italy. March 11-

13, 2007, pp. 231-234.

[3] X.Zhou, C.Yu, and P.Petrov, Compiler-Driven Register Re-

Assignment for Register File Power-Density and

Temperature Reduction, In Proc. DAC, Anaheim, California,

USA. June 8-13, 2008.

[4] S.Heo, K.Barr, and K.Asanovic, Reducing Power Density

through Activity Migration, In Proc. ISLPED, Seoul, Korea.

August 25-27, 2003.

[5] R.E.Kessler, E.J.McLellan, and D.A.Webb, The Alpha 21264

Microprocessor Architecture, IEEE Micro, March, 1999, pp.

19(2):24-36.

[6] R.D.Doug, D.Burger, S.W.Keckler, and Todd Austin, Sim-

alpha: a Validated, Execution-Driven Alpha 21264

Simulator, 2001.

[7] T.Austin, E.Larson, D.Ernst, SimpleScalar: An Infrastructure

for Computer System Modeling, Computer, vol. 35, no. 2, pp.

59-67, February, 2002.

[8] D.Brooks, et al. Wattch: A Framework for Architectural-

Level Power Analysis and Optimizations. In ISCA. 2000.

[9] K.Skadron, et al. HotSpot: Techniques for Modeling Thermal

Effects at the Processor-Architecture Level, THERMINIC,

Madrid, Spain, October 1-4, 2002

[10] SPEC2000INT benchmark at: http://www.spec.org/cpu

[11] T.Sherwood, et al. Basic Block Distribution Analysis to Find

Periodic Behavior and Simulation Points in Applications. In

PACT. 2001.

[12] P.Dadvar and K.Skadron, Potential Thermal Security Risks,

21st IEEE SEMI-THERM Symposium, 2005.

[13] D.Atienza et al., Reliability-Aware Design for Nanometer-

Scale Devices, ASPDAC, 21-24, March, 2008.

[14] Y.Zhang, D.Parikh, K.Sankaranarayanan, K.Skadron, and

M.Stan, HotLeakage: A Temperature-Aware Model of

Subthreshold and Gate Leakage for Architects, Univ. Of

Virginia Dept. Of Computer Science Tech. Report CS-2003-

05.

[15] P.Shivakumar and N.P.Jouppi, CACTI 3.0: An Integrated

Cache Timing, Power, and Area Model, Compaq Computer

Corporation Western Research Laboratory, August, 2001.


About the authors:

Jungwook Kim is a Ph.D. Candidate in the School of Electrical Engineering and Computer Science at Seoul National University in Korea. His research interests include thermal-aware architecture, power-density minimization, and low-power computer architecture. He received his B.S. (2003) degree in Rural Systems Engineering from Seoul National University in Korea.

Seong Tae Jhang is an associate professor in the Department of Computer Science at the University of Suwon in Korea. His research interests include multi-processor systems, computer architecture, and memory models. He received his B.S. (1986) degree in Computer Engineering from Seoul National University, his M.S. (1988) degree in Computer Engineering from Seoul National University, and his Ph.D. (1994) degree in Computer Engineering from Seoul National University.

Dr. Moon is a member of KISS, KICS, KIPS and KIIS. His research interests include real-time embedded systems, real-time databases, and real-time location-based tracking systems. He received his B.S. Degree from the University of Texas at Austin, 1986. He received his M.S. And Ph.D. Degrees in Computer Science from Florida State University in 1991 and 1997, respectively.

Chu Shik Jhon is a professor in the Department of Electrical Engineering and Computer Science at Seoul National University. He received his B.S. Degree in Applied Mathematics from Seoul National University in 1975, his M.S. Degree in Computer Engineering from Korea Advanced Institue of Science and Technology at Taegeon in 1977, and his Ph.D. Degree in Computer Engineering from the University of Utah in 1982.

ACM SIGAPP PageTypically, the sensor networks are composed of many wire-less sensor nodes deployed...

Documents

Transcript of ACM SIGAPP PageTypically, the sensor networks are composed of many wire-less sensor nodes deployed...