Extending bpel for interoperable pervasive computing
1 / 25

Extending BPEL for Interoperable Pervasive Computing - PowerPoint PPT Presentation

  • Updated On :

Extending BPEL for Interoperable Pervasive Computing. Gregory Hackmann, Christopher Gill, and Gruia-Catalin Roman Mobile Computing Laboratory and Center for Distributed Object Computing ICPS ’07, 18 July 2007. Outline. Introduction and Background BPEL Extensions Proof-of-Concept System

Related searches for Extending BPEL for Interoperable Pervasive Computing

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Extending BPEL for Interoperable Pervasive Computing' - Mia_John

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Extending bpel for interoperable pervasive computing l.jpg

Extending BPEL for Interoperable Pervasive Computing

Gregory Hackmann, Christopher Gill, and Gruia-Catalin Roman

Mobile Computing Laboratory and

Center for Distributed Object Computing

ICPS ’07, 18 July 2007

Outline l.jpg

  • Introduction and Background

  • BPEL Extensions

  • Proof-of-Concept System

  • Related Work and Conclusion

Introduction l.jpg

  • PDAs and mobile phones have become a tremendous pervasive computing platform

    • 267 million Java-equipped mobile phones deployed in 2004; estimated 1.5 billion by end of 2007

    • Typically equipped with high-resolution screens, low-power networking, GPS sensors, microphones, and digital cameras

  • Though they are largely used today for placing calls and taking notes, they have significant potential for unplanned, mobile, ad-hoc interactions

Application characteristics l.jpg
Application Characteristics

  • Wide range of lightweight devices from different manufacturers

  • Deployed exactly when needed, with little or no preplanning

  • Depend on inter-device communication using low-power wireless networks

Example workflow l.jpg
Example Workflow







Wait for




Seller and







Seller and


Business process execution language bpel l.jpg
Business Process Execution Language (BPEL)














Bpel key features l.jpg
BPEL: Key Features

  • Interactions based on SOAP -> resolves interoperability problems

  • Turing complete -> workflows can perform extremely powerful computations

  • Applications are self-contained XML -> simple to deploy wirelessly

  • Links are described by type rather than endpoint -> exact identity of partners doesn’t have to be known until runtime

  • Low-level communication details are hidden at application level -> suitable for mixed- or unknown-media networks

  • Wide acceptance in wired settings -> many modeling and verification tools available off-the-shelf

Approach bpel extensions l.jpg
Approach: BPEL Extensions

  • BPEL extensions are commonly used to expand BPEL’s use into new areas

    • BPEL4People [Active Endpoints Inc. 2007]

    • WS-BPEL 2.0 Extensions for Sub-Processes [IBM 2005]

  • A few extensions can alleviate BPEL’s shortcomings in mobile settings

Partner groups l.jpg
Partner Groups

  • Partner groups are special partner links which contain an unbounded list of endpoints

    • Like partner links, each group has a unique name and associated type

  • Two new activities for manipulating partner links:

    • <add> copies an endpoint from an active partner link into a partner group

    • <remove> removes a link’s endpoint from a partner group

Partner groups cont l.jpg
Partner Groups (cont.)

  • <reply> activity can now send responses to partner links or partner groups

    • Messages are multicast to all group members

    • Optional moreMessages attribute allows partners to continue sending or receiving messages

      • By default, set to “no” -> standard single-request, single-reply interactions

  • BPEL 2.0 can emulate multicast behavior by copying link bindings into lists, and iterating over lists using <forEach> activity

Partner link re use l.jpg
Partner Link Re-Use

  • Workflows can support an unbounded number of participants by re-using partner links

    • e.g., one partner link for accepting bids from clients, which is shared among all bidders

  • This approach requires clear semantics for partner link lifetimes and some control over partner link bindings

Partner link re use cont l.jpg
Partner Link Re-Use (cont.)

  • Proposed partner link lifetime semantics:

    • Links can accept connections iff they are not already being used, i.e., iff they are not currently bound to some endpoint

    • When a <reply> activity is invoked and moreMessages attribute is “no”, then the link is unbound and the communication channel is closed

    • Processes may explicitly close or unbind partner links at runtime using new <close> and <unbind> activities

Example auction bid handling l.jpg
Example: Auction Bid Handling


<partnerLink name="buyer" ... />

<ext:partnerGroup name="buyers" ... />





<onMessage operation="bid"

partnerLink="buyer" ...>

<sequence name="handleBid">

<ext:add partnerGroup="buyers”

partnerLink="buyer" />


<ext:reply partnerGroup="buyers”



moreMessages="yes" />

<ext:unbind partnerLink="buyer" />




Over the air process deployment system l.jpg
Over-the-Air Process Deployment System

  • Over-the-air (OTA) application deployment is very important in mobile ad-hoc settings

  • Though MIDP currently supports OTA deployment, its infrastructure requirements are inappropriate for mobile settings

    • Applications must be hosted on a centralized HTTP server

    • No concrete mechanism for locating application servers

    • Applications cannot share code

  • BPEL processes are self-contained and highly compact applications

  • Proof-of-concept implemented on Java MIDP using Sliver

Sliver middleware l.jpg
Sliver Middleware

  • Lightweight SOAP and BPEL engine designed for mobile devices

    • Supports Java MIDP and Java SE platforms

    • Clean separation between communication and processing components: support for a wide range of communication media and protocols

    • Small storage and memory footprint (190 KB code base including all dependencies)

    • SOAP components can be deployed independently from BPEL components

  • Deployed and tested on Linux, Windows XP, OS X, Windows Mobile, and Symbian OS devices

Process repository l.jpg
Process Repository

  • Advertises and distributes user-provided BPEL process documents using SOAP

  • Can be located at runtime using Bluetooth service discovery

  • 48 KB codebase

Process server l.jpg
Process Server

  • Locates process repositories, presents the user with a list of available processes, and downloads and executes BPEL code

  • Advertises the locally-hosted process using their user-supplied WSDL specifications

  • 181 KB codebase

Process client l.jpg
Process Client

  • Presents the user with a list of process servers and their processes

  • Fetches WSDL descriptions from the process server and presents a form-like GUI for sending messages to the process

  • 88 KB codebase

Sample application l.jpg
Sample Application

  • We have implemented the auction application described earlier in this talk using our proof-of-concept system

    • Sellers may create new listings with a user-specific description, initial price, and length

    • Buyers may submit bids or query the auction’s status

    • The seller and all buyers are notified when the item’s price changes, and at the auction’s end

  • 4.5 KB of BPEL code, and a 4.2 KB WSDL descriptor

Related work l.jpg
Related Work

  • HSN-SOA [Nakamura 2004] allows users to graphically generate workflows for inter-appliance interactions

    • e.g., when the user turns on the TV, the TV turns on the speakers and dims the light

    • Uses SOAP and WSDL for inter-device interoperability

    • Implicitly assumes a stable network, and describes workflows in terms of specific devices

  • [Ranganathan 2004] generates and executes BPEL workflows in pervasive computing settings

    • User’s device describes task or goal to centralized server, which generates and executes a BPEL workflow to carry it out

    • Avoids many of BPEL’s communication limitations, since workflows are generated on-the-fly

    • Requires a powerful centralized server

Conclusion l.jpg

  • BPEL is a powerful language for developing collaborative applications in wired environments

  • With a few extensions, it can be made into an interoperable platform for pervasive and mobile applications

  • We have implemented and deployed a proof-of-concept system using these extensions based on the Sliver middleware

Thank you l.jpg
Thank You!

Sliver project page: