Extending BPEL for Interoperable Pervasive Computing

1
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

2
Outline

• Introduction and Background
• BPEL Extensions
• Proof-of-Concept System
• Related Work and Conclusion

3
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

4
Example Application
5
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

6
Example Workflow
Start
Receive Auction Description
Start Timer
Wait for Event
End
Receive Bid
Timer Fires
Notify Seller and Bidders
Notify Seller and Bidders
7
Business Process Execution Language (BPEL)
ltprocessgt ... lt/processgt
ltbidRequestgt
ltbidResponsegt
buyer1 bid
buyer2 bid
buyer3 bid
buyer4 bid
8
BPEL Key Features

• Interactions based on SOAP -gt resolves
  interoperability problems
• Turing complete -gt workflows can perform
  extremely powerful computations
• Applications are self-contained XML -gt simple to
  deploy wirelessly
• Links are described by type rather than endpoint
  -gt exact identity of partners doesnt have to be
  known until runtime
• Low-level communication details are hidden at
  application level -gt suitable for mixed- or
  unknown-media networks
• Wide acceptance in wired settings -gt many
  modeling and verification tools available
  off-the-shelf

9
BPELs Limitations
10
BPELs Limitations
X
?
11
Approach BPEL Extensions

• BPEL extensions are commonly used to expand
  BPELs use into new areas
• BPEL4People Active Endpoints Inc. 2007
• WS-BPEL 2.0 Extensions for Sub-Processes IBM
  2005
• A few extensions can alleviate BPELs
  shortcomings in mobile settings

12
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
• ltaddgt copies an endpoint from an active partner
  link into a partner group
• ltremovegt removes a links endpoint from a partner
  group

13
Partner Groups (cont.)

• ltreplygt 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 -gt standard
  single-request, single-reply interactions
• BPEL 2.0 can emulate multicast behavior by
  copying link bindings into lists, and iterating
  over lists using ltforEachgt activity

14
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

15
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 ltreplygt 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 ltclosegt and ltunbindgt
  activities

16
Example Auction Bid Handling

• ltpartnerLinksgt
• ltpartnerLink name"buyer" ... /gt
• ltextpartnerGroup name"buyers" ... /gt
• ...
• lt/partnerLinksgt
• ...
• lteventHandlersgt
• ltonMessage operation"bid"
• partnerLink"buyer" ...gt
• ltsequence name"handleBid"gt
• ltextadd partnerGroup"buyers
• partnerLink"buyer" /gt
• ...
• ltextreply partnerGroup"buyers
• operation"bid
• variable"auctionStatus
• moreMessages"yes" /gt
• ltextunbind partnerLink"buyer" /gt
• lt/sequencegt

17
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

18
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

19
Process Repository

• Advertises and distributes user-provided BPEL
  process documents using SOAP
• Can be located at runtime using Bluetooth service
  discovery
• 48 KB codebase

20
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

21
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

22
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 auctions
  status
• The seller and all buyers are notified when the
  items price changes, and at the auctions end
• 4.5 KB of BPEL code, and a 4.2 KB WSDL descriptor

23
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
• Users device describes task or goal to
  centralized server, which generates and executes
  a BPEL workflow to carry it out
• Avoids many of BPELs communication limitations,
  since workflows are generated on-the-fly
• Requires a powerful centralized server

24
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

25
Thank You!
Sliver project page http//mobilab.cse.wustl.edu/
projects/sliver/