Extending bpel for interoperable pervasive computing
Download
1 / 25

Extending BPEL for Interoperable Pervasive Computing - PowerPoint PPT Presentation


  • 223 Views
  • 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

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
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
Outline

  • Introduction and Background

  • BPEL Extensions

  • Proof-of-Concept System

  • Related Work and Conclusion


Introduction l.jpg
Introduction

  • 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

Start

Receive

Auction

Description

Start

Timer

Wait for

Event

End

Notify

Seller and

Bidders

Receive

Bid

Timer

Fires

Notify

Seller and

Bidders


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

<process>

...

</process>

<bidRequest>

<bidResponse>

buyer1:

bid

buyer2:

bid

buyer3:

bid

buyer4:

bid


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

<partnerLinks>

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

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

...

</partnerLinks>

...

<eventHandlers>

<onMessage operation="bid"

partnerLink="buyer" ...>

<sequence name="handleBid">

<ext:add partnerGroup="buyers”

partnerLink="buyer" />

...

<ext:reply partnerGroup="buyers”

operation="bid”

variable="auctionStatus”

moreMessages="yes" />

<ext:unbind partnerLink="buyer" />

</sequence>

</onMessage>

</eventHandlers>


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
Conclusion

  • 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:

http://mobilab.cse.wustl.edu/projects/sliver/


ad