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 Notify Seller and Bidders Receive Bid Timer Fires Notify Seller and Bidders

7. Business Process Execution Language (BPEL) <process> ... </process> <bidRequest> <bidResponse> buyer1: bid buyer2: bid buyer3: bid buyer4: bid

8. 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

9. BPEL’s Limitations

10. BPEL’s Limitations X ?

11. 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

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: • <add> copies an endpoint from an active partner link into a partner group • <remove> removes a link’s endpoint from a partner group

13. 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

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

16. 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>

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

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

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/