Docstoc

main - Get Now PDF

Document Sample
main - Get Now PDF Powered By Docstoc
					         Extending BPEL for Interoperable Pervasive
                       Computing
                            Gregory Hackmann, Christopher Gill, and Gruia-Catalin Roman
                                       Department of Computer Science and Engineering
                                              Washington University in St. Louis
                                        Email: {ghackmann, cdgill, roman}@wustl.edu


   Abstract— The widespread deployment of mobile devices like            application constructs a tailored plan for containing and
PDAs and mobile phones has created a vast computation and                cleaning the spill, which is then deployed over an ad-hoc
communication platform for pervasive computing applications.             802.11b network to the other engineers’ PDAs.
However, these devices feature an array of incompatible hard-
                                                                      • A structural engineer surveys a construction site. During
ware and software architectures, discouraging ad-hoc interac-
tions among devices. The Business Process Execution Language             a routine inspection, the engineer notices that a beam
(BPEL) allows users in wired computing settings to model                 is misshapen. The engineer constructs a plan on-the-fly
applications of significant complexity, leveraging Web standards          to collect the parts needed to replace the beam and to
to guarantee interoperability. However, BPEL’s inflexible commu-          coordinate the workers who will perform the replacement.
nication model effectively prohibits its deployment on the kinds
of dynamic wireless networks used by most pervasive computing            The steps are sent to the corresponding workers’ PDAs
devices. This paper presents extensions to BPEL that address             using a Bluetooth connection. As the workers complete
these restrictions, transforming BPEL into a versatile platform          their tasks, they mark boxes on their PDAs; electronic
for interoperable pervasive computing applications. We discuss           notifications are sent back to the engineer, who monitors
our implementation of these extensions in Sliver, a lightweight          completion of the plan.
BPEL execution engine that we have developed for mobile
devices. We also evaluate a pervasive computing application        Though these scenarios are varied, they share several key
prototype implemented in BPEL, running on Sliver.                  characteristics. First, a wide range of ubiquitous devices from
                                                                   different manufacturers participate in the applications. Second,
                       I. I NTRODUCTION
                                                                   the applications are deployed over-the-air exactly when they
   Inexpensive mobile and embedded computing devices, like         are needed, with little or no preplanning. Third, these appli-
PDAs and mobile phones, have become an important part of           cations depend greatly on inter-device communication using
everyday business and social life. In 2004, over 267 million       low-power wireless networks.
Java-capable mobile phones were deployed worldwide, and               These three characteristics comprise a significant interoper-
Sun estimates that up to 1.5 billion will be deployed by           ability challenge. Mobile and embedded computing devices
the end of 2007 [1]. Today, these ubiquitous devices are           feature a wide variety of incompatible hardware and soft-
primarily used for simple organization and communication           ware architectures. In order for such devices to collaborate
tasks, like note-taking and placing phone calls. However, as       successfully, they must agree on common protocols for data
these devices become more and more commonplace, they offer         processing and exchange. The need for universal standards is
an increasingly-powerful environment for pervasive computing       especially important in pervasive computing settings like the
applications. Typical PDAs and mobile phones are equipped          ones describe above: meetings among otherwise-incompatible
with high-resolution color displays; low-power networking          platforms often occur without planning.
adapters like Bluetooth; CPUs capable of processing full-             In traditional wired computing settings, interoperability is-
motion video; and even GPS sensors, microphones, and digital       sues are resolved using Web standards. Using the Business
cameras.                                                           Process Execution Language [2] (BPEL) standard, complex
   Many compelling collaborative applications occur in un-         applications can be modeled as workflows. Workflows divide
planned, mobile, ad-hoc settings. Some example applications        large processes into smaller tasks; they are annotated with
include:                                                           explicit synchronization, ordering, and data flow constructs
   • An artist brings a painting to an art exhibition. Several     which direct tasks toward a coherent goal. BPEL assumes
     art collectors express an interest in buying the painting.    that these tasks are implemented as software services which
     The artist creates a personal-area network among the          exchange XML messages, but does not require a specific
     PDAs carried by the collectors using his mobile phone’s       protocol or middleware for service invocation and data ex-
     Bluetooth interface, and deploys an auction application       change. In practice, this role is filled universally by the Simple
     to sell his painting.                                         Object Access Protocol [3] (SOAP). Because BPEL and SOAP
   • Environmental engineers discover a chemical spill. The        are specifically designed to promote interoperability among
     chief engineer describes the spill and the contaminated       different services and architectures, they are already widely
     area to an analysis application located on her PDA. This      deployed in wired networks.
   Unfortunately, though BPEL aims to be transport- and            In the interest of portability, SOAP does not mandate an un-
protocol-agnostic, it makes several assumptions about the          derlying network transport. Though SOAP is most frequently
underlying network which limit its ability to model perva-         coupled with HTTP, some SOAP implementations support a
sive computing applications. BPEL assumes that the number          wide array of transports ranging from Bluetooth to SMTP.
of participants in the application is known at design time,        When coupled with an advertisement mechanism like Zeroconf
and cannot be changed at runtime. While this assumption            [5] or Bluetooth service discovery, users can discover and
is reasonable in traditional wired networks, it does not fit        invoke remote SOAP services without prior knowledge of their
typical pervasive computing settings, where participants may       existence.
come and go at any time. Further, BPEL only supports a                At the most abstract level, a BPEL process is essentially
small set of communication patterns, which hinders its use         a list of service invocations, with the ability to perform sets
in dynamic networks. Nevertheless, despite BPEL’s limited          of invocations in parallel or in a specific sequence. Much of
communication features, its processing constructs are highly       BPEL’s power comes from its ability to store the results of
expressive. Our experience developing the Sliver middleware        these invocations in global variables, which processes can pass
[4] shows that BPEL already can be used to develop complex,        as inputs to other Web services. Between service invocations,
standards-based applications on lightweight devices.               BPEL processes optionally may examine or change parts of
   In this paper, we show that by augmenting BPEL’s com-           these variables using the XPath [6] query language. Processes
munication capabilities, it can be adapted further into a pow-     also may change their behavior at runtime based on variables’
erful standard for executing pervasive applications, even in       contents, by using branching constructs and while loops.
mobile settings. Section II describes the BPEL standard and        Finally, processes may indicate series of actions that should
outlines its potential for pervasive computing. In Section III,    be carried out asynchronously when events fire, such as when
we discuss several extensions to BPEL which support group          specific messages arrive at the process or when a timer expires.
communication and re-use of partner links in pervasive com-        Using these simple constructs, workflow designers can string
puting applications. We discuss the Sliver middleware, which       simple services into complex, adaptive, and interoperable
incorporates these extensions, in Section IV. A prototype          applications.
over-the-air deployment system using the Sliver middleware            Because BPEL is a Turing-complete language [7], the
is described in Section V. We evaluate a sample application        computations that are performed in between service invo-
deployed using this system in Section VI. Finally, we discuss      cations can be extremely powerful. However, this powerful
work on related systems in Section VII, and give concluding        computational model is coupled with an inflexible commu-
remarks in Section VIII.                                           nication model. BPEL represents all communication links —
                                                                   whether incoming or outgoing — as abstract partner links.
                 II. P ROBLEM S TATEMENT                           From the process’s point of view, a partner link is simply
                                                                   a communication channel which allows the initiator to send
   BPEL is a powerful language which leverages software            exactly one request, and the recipient to reply with at most
services to model and execute applications as workflow pro-         one response. Each partner link is bound to a single remote
cesses. However, current limitations in BPEL’s communication       endpoint at a time. In the interest of being transport-agnostic,
model hinder its ability to interact with other hosts in a         BPEL processes have very limited control over the bindings
dynamic network. In this section, we discuss briefly features       of these partner links: the current version of BPEL does not
of the SOAP and BPEL standards as they relate to pervasive         allow processes to inspect or modify a partner link’s binding,
computing. We also highlight the need for BPEL extensions          except by copying bindings directly between two partner
to support pervasive computing adequately.                         links. It is also assumed that the BPEL middleware has some
   When deploying applications that span multiple hosts, the       policy for pairing partner links to endpoints; this mechanism
need for standardized message formats is paramount. This is        is not exposed to the process. Most BPEL middleware have
especially true when interactions among hosts are unplanned,       an API for mapping outgoing partner links to endpoints at
as is the case in many pervasive computing settings. The SOAP      deployment time, and automatically bind incoming partner
standard addresses this need, by describing an XML-based           links to the source of the incoming messages. Because partner
encoding for messages. SOAP provides an object serialization       links are described in terms of their types and not their
scheme that converts objects into architecture-independent,        endpoints, workflow designers can model interactions with
language-independent XML strings. Like most object-oriented        remote services that may not be identified until runtime —
languages, SOAP builds complex messages by aggregating             an important feature in pervasive computing settings.
primitive types like integers and strings.                            Unfortunately, though process designers do not need to
   In addition to specifying a message encoding scheme,            predict the identity of partners at design time, they must
SOAP provides a simple framework for service invocation.           declare a fixed set of partner links with well-known types
Traditionally, this invocation framework has been used as a        nevertheless. So, the process designer must effectively predict
standards-based RPC mechanism, where each remote method            at design time the number and kinds of partners that will
is exposed as a SOAP service. However, SOAP supports a rich        participate in the workflow. In wired network settings, this
range of interaction patterns beyond simple request/reply pairs.   assumption is often reasonable. However, in pervasive settings,
                                                                    <partnerLinks>
many applications assume — and often benefit from — the                <partnerLink ... />*
dynamic nature of the network. Peers may enter or leave the           <ext:partnerGroup name="ncname"
network at practically any time. This dynamic behavior is both          partnerLinkType="qname" />*
                                                                    </partnerLinks>
an asset and a liability: new peers may provide additional data
or services when they arrive, but existing peers may sever                            Fig. 1.   Partner Group Declarations
communication links unexpectedly if they leave the network.
   This discrepancy currently forces process designers to use       <ext:add partnerGroup="ncname" partnerLink="ncname"
                                                                      mustNotBeMember="no|yes"? />
one of two inadequate options for dealing with interactions         <ext:remove partnerGroup="ncname"
among hosts. First, a designer may estimate the maximum               partnerLink="ncname" mustBeMember="no|yes"? />
number of participants during the process’s lifetime, and create
                                                                    Fig. 2.   <add> and <remove> Activity Semantics for Partner Groups
a single-use partner link for each. For example, a workflow for
an auction would have a single partner link for the seller, and
a partner link for each potential bidder. This approach places
                                                                    we propose for the BPEL language to permit its deployment
artificial constraints on the process’s scope, and quickly leads
                                                                    and use in pervasive computing settings.
to unwieldy code duplication.
   Second, a designer may declare one partner link for each                             III. BPEL E XTENSIONS
type of interaction. Incoming messages are handled as asyn-
                                                                      To address the issues highlighted above, we propose several
chronous events, so that the process designer does not have to
                                                                    extensions to the BPEL language. Briefly, these extensions
predict at design time when or how often these interactions
                                                                    make the following changes:
will occur. For example, in the auction application, there
would be two partner links: one for the seller, and one shared        1) Processes may declare partner groups, or partner links
among all the bidders. However, this approach assumes that                that are bound to multiple incoming endpoints simulta-
the underlying BPEL middleware allows partner links to be                 neously.
bound to different hosts during the process’s lifespan: e.g.,         2) Processes may send multicast messages to all members
that the link shared among the bidders is bound to one host               in a partner group.
between the time that a bid is received and a response is sent,       3) Processes may send or receive an arbitrary number of
after which another host can be bound to the same link. As                messages over a partner link or partner group.
noted above, BPEL provides no guarantees about how partner            4) Processes may make limited changes to the bindings of
links are bound to remote endpoints, much less the lifespan               partner links, with well-defined behavior.
of these bindings. Moreover, this approach only works if no         For the sake of consistency, we describe our extensions with
two participants will ever issue the same kind of request           the same notation used in [2]. Tags with the ext: prefix are
concurrently, since each partner link can only be bound to          part of our extensions; all other tags are part of the standard
one endpoint at a time. This constraint effectively prohibits       BPEL specification.
applications from using long-lived transactions.
   BPEL’s simple message interaction patterns further compro-       A. BPEL Extensions for Partner Groups
mise its communication power. Though SOAP allows service               As we discussed in Section II, BPEL processes communi-
providers to send and receive any number of messages in an ar-      cate with remote hosts over partner links. These partner links
bitrary order, BPEL is much more restrictive. BPEL processes        are declared in a single <partnerLinks> delimited section
only support one-way request (the partner sends exactly one         located at the beginning of the process description. We extend
message and immediately disconnects) and request-response           this <partnerLinks> section to introduce the notion of partner
(the partner sends exactly one message and then receives            groups, as Figure 1 illustrates. We define partner groups to
exactly one message) interaction patterns. As we discuss later      be unbounded lists of partner links. Like a partner link, each
in Section III, these simple interaction patterns are insufficient   partner group has a unique name and an associated type (i.e.,
in pervasive computing settings.                                    the kinds of services that the links can invoke on the workflow,
   Despite BPEL’s shortcomings, its characteristics fit many         and vice versa). Unlike partner links, partner groups can be
important needs of pervasive computing applications. When           bound to any number of endpoints simultaneously, and can
BPEL is coupled with SOAP, any device equipped with a               be manipulated by the process at runtime using additional
standard SOAP middleware can participate in the application.        operations discussed below. These two traits are essential in
Because BPEL models applications in a standardized XML              mobile settings: they allow a process to refer to any number of
format, new applications can be deployed over-the-air to            remote hosts, without requiring the process designer to predict
devices equipped with a general-purpose BPEL execution              this number at design time.
engine. Finally, because of BPEL’s widespread acceptance in            Initially, partner groups are not bound to any endpoints. Fig-
wired settings, many modeling and verification tools (such as        ure 2 describes two new BPEL activities (add and remove)
JDeveloper BPEL Designer [8] and NetBeans Enterprise Pack           which change the membership of partner groups. The add
[9]) exist to assist developers with constructing applications in   activity adds an endpoint (taken from a specified partner link)
BPEL. In the next section, we will describe several extensions      to a partner group. By default, if the endpoint is already a
<ext:reply                                                         <ext:close partnerLink="ncname" />
  (partnerGroup="ncname" | partnerLink="ncname")                   <ext:unbind partnerLink="ncname" />
  moreMessages="no|yes"? ... />
                                                                            Fig. 4.   <close> and <unbind> Activity Semantics
           Fig. 3.   Extended <reply> Activity Semantics


                                                                         bound immediately after the message is sent, and the
member of the group, then the operation will do nothing. If the          communication channel is closed1 .
mustNotBeMember attribute is set to yes, then the process             3) Processes may explicitly unbind partner links or close
will throw a mustNotBeMember fault instead. Likewise, the                their underlying communication channels as needed.
remove activity removes an endpoints from a partner group.
                                                                   These rules permit processes to reuse partner links efficiently,
If the mustBeMember attribute is set to yes, then attempting
                                                                   while allowing process designers to predict and control how
to remove a non-existent member from a group will throw a
                                                                   this reuse occurs. Note that many BPEL engines, such as
mustBeMember fault.
                                                                   Sliver and ActiveBPEL, already exhibit the first two behaviors;
   To leverage these partner groups, we extend the definition
                                                                   but only Sliver (with the extensions presented in this paper)
of the reply activity, as shown in Figure 3. This extended
                                                                   provides the third behavior.
reply activity has two additions that differentiate it from a
normal BPEL reply activity. First, the reply may be sent to           Figure 4 shows two new BPEL activities (close and
a partner group instead of to a partner link. In this case, the    unbind) which support the third behavior. The close activ-
same message is sent to all members of the group. Second, the      ity allows the process to close a partner link’s communication
moreMessages attribute indicates whether or not the partner        channel, and then unbind the partner link programmatically.
is allowed to continue sending or receiving messages over the      The unbind activity unbinds a partner link, but does not
link after this message is sent. By default, moreMessages          close the underlying connection. As we discuss below, these
is set to no, and the process uses the simple single-request,      activities are useful for implementing multicast and publish-
single-response interaction pattern normally used by BPEL. If      subscribe communication schemes, which BPEL previously
moreMessages is sent to yes, then the process can continue         did not support.
to send and receive messages over the link, permitting complex
                                                                   C. Impact of BPEL Extensions
interaction patterns.
   The draft specification for WS-BPEL 2.0 [10] will allow             Though these extensions are conceptually simple, they add
processes to emulate multicast behavior using standard activ-      substantial power to BPEL’s existing communication model.
ities: processes can declare variables which effectively act as    In [11], Wohed evaluates BPEL’s capabilities with respect to
lists of bindings; copy bindings from partner links into these     six communication patterns commonly used by collaborative
variables; and then iterate over the contents of these variables   applications. Wohed concludes that BPEL cannot support two
using a forEach activity. (As of this writing, the current         of these six patterns: publish-subscribe and multicast. These
version of BPEL is WS-BPEL 1.1; WS-BPEL 1.1 does not               patterns are especially important in pervasive and mobile
allow processes to copy partner link bindings into variables,      applications, since they are the only patterns out of the six
and does not support the forEach activity.) Nevertheless, the      which do not require the process designer to specify a fixed
extensions proposed here are simpler for process designers         set of endpoints.
to use, since multicast is treated as a first-order activity.          The BPEL extensions described in this section address this
Moreover, WS-BPEL 2.0 will not address the other issues            issue. As we illustrate later in Section VI, processes can
highlighted in Section II: namely, BPEL’s inability to support     implement multicast messaging by maintaining a partner group
complex message interaction patterns or to effectively handle      whose membership reflects the set of multicast listeners. When
an unbounded number of participants.                               new listeners connect to the process, they are added to this
                                                                   partner group, and the partner link is explicitly unbound using
B. BPEL Extensions for Partner Link Re-Use                         the unbind activity. Because the partner link is unbound after
   As we discussed in Section II, in order for BPEL processes      each new listener connects, an unlimited number of listeners
to effectively support an unbounded number of participants,        can re-use the same link. Disconnection messages are handled
they must expect multiple hosts to use the same incoming           in a similar fashion, by using the remove activity to remove
partner link at different times. However, BPEL does not            the listener from the group, and the close activity to close
provide a clear semantics for the lifespan of bindings between     the corresponding communication channel. Messages then can
hosts and partner links. To address this issue, we propose the     be sent to all the members of this group using the extended
following semantics for incoming partner links:                    reply activity.
                                                                      Publish-subscribe behavior can be implemented similarly,
   1) Partner links can accept incoming connections if and
                                                                   by using a different partner group for each kind of message
      only if they are not already being used, i.e., if and only
      if they are not currently bound to any host.                    1 For the purpose of explanation, we assume in this section that the under-
   2) When a reply task is invoked and its moreMessages            lying communication protocol is connection-oriented. In situations where this
      attribute is no, the corresponding partner link is un-       is not true, attempts to “close” the communication channel are ignored.
subscription (in the interest of brevity, we omit further discus-   remove unused bytecode and assign compact names to classes
sion). Thus, the extensions proposed in this section support        and methods.
the development of sophisticated pervasive and mobile appli-           In the remainder of this section, we will briefly discuss
cations which use any of the six important communication            the design of Sliver’s constituent layers. More detailed design
patterns noted in [11].                                             information, including sample code, may be found in [4].
                 IV. S LIVER M IDDLEWARE                            A. Transport Layer
   We have implemented the extensions described above as               The transport layer is responsible for the transmission
part of the Sliver middleware. Sliver is a lightweight SOAP and     of messages produced by the upper layers. Because mobile
BPEL execution engine designed for deployment on mobile             devices support a wide range of communication media and
devices. Sliver supports a wide range of computing platforms,       protocols, Sliver’s transport layer uses pluggable communi-
ranging from mobile phones to desktop PCs. In this section, we      cation providers. This design is inspired by the pluggable
will discuss briefly the design and implementation of Sliver.        protocol layers used by TAO [13] and Apache Axis 2.0 [14].
   Sliver’s architecture features several characteristics moti-     Sliver’s transport layer features a streamlined API specifically
vated by the specific needs of mobile devices. First, Sliver pro-    designed to facilitate the support of new protocol providers.
vides a clean separation between communication and process-         If a developer wishes to support a new protocol, he must
ing. Communication components can be interchanged without           implement only two public interfaces with a total of eleven
affecting the processing components. This separation allows         public methods. Currently, Sliver supports raw TCP/IP sockets
Sliver to support a wide variety of communication media             and Bluetooth L2CAP on J2SE and MIDP devices, as well as
and protocols, ranging from HTTP to Bluetooth. Second,              HTTP on J2SE devices.
Sliver only depends on two lightweight external libraries,
which themselves were designed with mobile devices in mind.         B. XML/SOAP Parser
This minimizes Sliver’s footprint and ensures that Sliver can          Because Sliver leverages standards like SOAP and BPEL,
be deployed on a broad range of devices. Third, Sliver’s            all messages exchanged over the transport layer are encoded
SOAP components do not depend on its BPEL components.               in XML form. Sliver uses the third-party kXML [15] and
Developers can deploy SOAP services on mobile devices               kSOAP [16] packages to parse XML and SOAP documents.
without needing Sliver’s full BPEL engine, further reducing         These packages are designed with mobile devices in mind:
Sliver’s footprint.                                                 they have a small combined footprint (47 KB of storage space)
   The resulting architecture is shown in Figure 5. At the          and operate on most available Java runtimes.
lowest level of the architecture, the transport layer wraps var-       In the interest of brevity, we do not discuss here how
ious network media and protocols with a consistent interface.       SOAP encapsulates data in XML form; the interested reader
The transport layer exchanges message objects in the form           may consult [3] for more information. However, it is worth
of serialized XML strings. These strings are converted to and       noting that, like many other object-oriented languages, SOAP
from Java objects by the XML and SOAP parser layers.                constructs objects out of primitive types (integers, strings, etc.)
   The SOAP server layer wraps user-provided Java services          and other well-known objects. Each type of object has an
with a Web service interface. When deserialized messages ar-        associated name and namespace. SOAP namespaces are used
rive from the XML and SOAP layers, the SOAP server directs          to differentiate between different types with the same base
them to the corresponding service. The service’s response is        name, and are roughly analogous to Java packages or C++
serialized by the XML and SOAP layers, and is then sent over        namespaces.
the network by the transport layer.
   Many of these layers are re-used by Sliver’s BPEL server.        C. SOAP Server
The XML parser layer, in conjunction with the BPEL parser              The SOAP protocol provides a standard for service invoca-
layer, converts user-provided BPEL documents into concrete          tion in addition to message encoding. Sliver’s SOAPServer
executable processes. The BPEL server layer hosts the pro-          class implements a SOAP service handler, which dispatches in-
cesses that these layers produce. Like the SOAP server, the         coming service invocations to the corresponding user-provider
BPEL server consumes the requests that arrive from the              service. Again, in the interest of brevity, we do not discuss in
transport layer and routes them to the appropriate processes.       detail how these service invocations are encoded. We note that
   In its current version, Sliver supports BPEL’s core feature      requests and responses are encapsulated as SOAP objects, and
set and has a total code base of 190 KB including all dependen-     that these objects contain the call’s parameters/return values as
cies (excluding an optional HTTP library). Most applications        nested children. Like any other SOAP object, request messages
will only use a subset of Sliver (e.g., because they only use       have an associated type name and namespace, which are used
one of Sliver’s included transport providers). Hence, Sliver’s      to direct requests to the appropriate service.
effective footprint may be reduced by bundling applications
with only the components of Sliver which each application           D. BPEL Parser
uses. This procedure can be automated by post-processing               Unlike standard SOAP services — which are generally
application bundles with utilities such as ProGuard [12], which     stand-alone entities implemented in any of a wide variety of
                                                     SOAP                        BPEL
                                                     Service                    Process

                                                        SOAP Server                         BPEL Server


                                                                 SOAP Parser                          BPEL Parser


                            Service Discovery                                  XML Parser

                                                     Transport                                    BPEL Documents


                                          Third-party library         Sliver        Provided by user


                                          Fig. 5.   The architecture of the Sliver execution engine




languages — BPEL processes use a standardized XML schema                   The bindIncomingLink method maps incoming partner
to describe interactions among other SOAP services. Sliver              links to the kinds of messages that they accept as input.
represents each BPEL tag with a corresponding Java class;               Likewise, the bindOutgoingLink method maps outgoing
e.g., the reply tag is represented by the Reply class. Each             partner links to concrete endpoints. These methods allow
class has a constructor which uses the kXML library described           applications which embed Sliver to apply a wide variety of
in Section IV-B to tokenize and parse the corresponding part of         partner link mapping policies flexibly, according to the appli-
process descriptions. These constructors make local validation          cation’s needs. Such policies may range in complexity from
decisions which verify the BPEL document’s validity; e.g., the          using simple hard-coded mappings, to dynamically remapping
Reply class’s constructor throws an exception if it encounters          partner links at runtime using the service discovery layer
a reply tag without a partnerLink or partnerGroup                       described below.
attribute. These local decisions eliminate much of the need for            Sliver’s BPEL server layer is able to host a wide variety of
a heavy-weight, fully-validating XML parser library.                    useful workflow processes. A framework has been proposed
   BPEL subdivides processes into nested scopes; state in-              which allows for the analysis of workflow languages in terms
formation (like variables and communication links to Web                of a set of 20 commonly recurring workflow patterns [17].
services) is shared among all the activities within a scope.            Sliver currently supports 14 of these 20 patterns in full, and
Sliver maintains all the information known about each scope             partially supports one other pattern. Even on resource-limited
at parse time (e.g., the types and names of variables) in               PDA and mobile phone hardware, the cost of executing most
ScopeData objects. A ProcessInstance object is also                     patterns in Sliver is on the order of 100 ms. The interested
instantiated for each workflow instance; it tracks information           reader may consult [4] for a full performance evaluation.
which varies across instances (e.g., the values of variables).          F. Service Discovery
[4] discusses how these constructs are maintained and used in
                                                                           In pervasive computing environments, remote services occa-
further detail.
                                                                        sionally may connect and disconnect as their hosts move in and
   Sliver supports all of the basic and structured activity
                                                                        out of range. To support such environments, Sliver includes a
constructs in BPEL, with the exception of the compensate
                                                                        framework for discovering remote services at runtime using
activity, and supports basic data queries and transformations
                                                                        Bluetooth service discovery. The services discovered using
expressed using the XPath language [6]. Sliver also supports
                                                                        this mechanism can be used to update the BPEL server’s
the use of BPEL Scopes and allows for local variables, fault
                                                                        service bindings programmatically as new service providers
handlers, and event handlers to be defined within them.
                                                                        are discovered at runtime. Though this framework currently
                                                                        only provides service discovery using Bluetooth, it could be
E. BPEL Server
                                                                        adapted easily to support other discovery protocols, such as
   The BPELServer class hosts the BPEL processes that the               Zeroconf.
BPEL parser generates. BPELServer extends SOAPServer                       To avoid radio interference, Bluetooth hops across 79
to invoke these processes in place of SOAP services. It                 frequencies in a pseudo-random fashion. This policy causes
also adds several additional methods to its public API. The             device discovery to cost anywhere from 625µs to 2.5s per
addProcess method creates a BPEL process in the specified                device [18], depending on how long it takes for their radio
namespace; it reads the processs BPEL specification from the             frequencies to coincide. Sliver alleviates this cost by allowing
provided InputStream. This method invokes the BPEL parser               the application to optionally bypass the device discovery
described above, which encapsulates the entire workflow in a             procedure, and only search for services on well-known de-
Process object.                                                         vices and devices cached from previous queries. Sliver will
also query as many devices in parallel as permitted by the           vertised using a well-known 128-bit identifier. This identifier is
underlying hardware.                                                 unique for each type of service, but shared across all providers
                                                                     of that service: i.e., there is a single 128-bit ID which all
        V. OVER - THE -A IR P ROCESS D EPLOYMENT                     process repositories share. Interested devices can locate any
   Apart from middleware suitability, software provisioning          number of process repositories in the network at runtime by
is another key concern in mobile and pervasive applications.         searching for this 128-bit ID, and then interact with them using
In these environments, interactions among devices may occur          the well-known SOAP interface.
both frequently and unexpectedly. It is unreasonable to expect          Figure 6 shows a screenshot from the process repository
each device to store all of the software that it may ever need, or   application. Using a simple graphical interface, users can
for device owners to predict which software to deploy ahead-         browse the local device’s filesystem and select which BPEL
of-time. For example, consider the auction scenario described        processes to advertise. As we discuss later in this section, each
in Section I. Though the artist will likely have had foresight to    BPEL process must also have a corresponding user-provided
deploy an auction application on his phone, it is unlikely that      WSDL definition file. On demand, the user can also start and
the art collectors would have deployed a compatible client for       stop the SOAP service which exposes the repository to the
this auction application ahead-of-time.                              Bluetooth network.
   MIDP addresses this issue using over-the-air provisioning
(OTA), as described in [19]. Using this mechanism, developers        B. Process Server
can package software as self-contained applications, which              The second component of the OTA system is the server
mobile devices can download and deploy over a wireless               which executes BPEL processes. This application uses Blue-
connection. Unfortunately, MIDP’s existing OTA scheme has            tooth service discovery to compile a list of all service reposi-
significant infrastructure requirements which are impractical to      tories in range, as described above. The user is presented with
fulfill in most pervasive environments. Notably, MIDP requires        a GUI which lists all the repositories that were discovered.
developers to host their applications on an HTTP server; it          To reduce the cost of discovering these repositories, the
also assumes that clients can somehow locate this server at          application will populate this list with repositories located
runtime, but does not specify a concrete discovery mechanism.        on well-known and cached devices whenever possible. If the
Moreover, MIDP does not permit applications to share code:           cache is stale, then the user may invoke a Refresh command
any common libraries must be duplicated in each application.         to perform a new service discovery query.
This policy is especially wasteful in pervasive computing               Once the user selects a repository to explore, the server
applications, where communication middleware comprises a             application uses the SOAP interface described above to obtain
substantial portion of the codebase, and bandwidth and storage       a list of processes stored in the repository. The user is
space are limited.                                                   presented this list, from which she may select the process to
   BPEL processes, on the other hand, are highly compact:            download. After a process is selected, the server application
complex applications can be modeled in a few kilobytes               uses the repository’s SOAP service to download the process’s
of text. A general-purpose BPEL execution platform would             BPEL code. Once the BPEL code is downloaded, it is parsed
offer considerable storage and bandwidth savings: though the         and executed by Sliver’s BPEL server. The server application
initial cost of deploying the engine would be relatively high,       GUI includes a subset of the client GUI described below, so
the incremental cost of each additional application would be         that the user can interact with processes hosted on the local
negligible. Moreover, since BPEL relies on Web standards like        device. This procedure is illustrated in Figure 7.
SOAP, it would be possible to create a single, general-purpose          As we discussed in Section II, the BPEL code does not indi-
client for interacting with these applications. As a proof-of-       cate how to map partner links to concrete endpoints. However,
concept, we have created a prototype system which provisions         these mappings can be defined using a separate WSDL spec-
BPEL processes over-the-air using Sliver. In the remainder of        ification file. Hence, the process server advertises each pro-
this section, we will discuss the key components of this system      cess’s user-supplied WSDL specification along with its BPEL
in further detail.                                                   markup. After submitting the BPEL code to the Sliver mid-
                                                                     dleware, the server application parses the WSDL file to obtain
A. Process Repository                                                the links’ mappings. It then programmatically maps these links
   The first major component of our system is the process             using the BPELServer’s bindIncomingLinks method,
repository. This component advertises and distributes user-          allowing the process to be deployed without any extra user
provided BPEL process files. The repository is exposed to             input. Note that for the sake of simplicity, our server ap-
other devices in the local Bluetooth network as a SOAP               plication does not currently handle outgoing link bindings.
service. Other devices can connect to the SOAP service using         It is conceptually straightforward to add this support, by
the Bluetooth L2CAP protocol, and invoke methods which list          using Sliver’s service discovery framework to locate external
the available processes and retrieve the corresponding BPEL          services.
code from the repository.                                               As with the repository service, these processes are exposed
   To support runtime discovery, this SOAP service is also           to the Bluetooth network as SOAP services and advertised
advertised as a Bluetooth service. Bluetooth services are ad-        using Bluetooth service advertisements. The process server
   Fig. 6.   Sliver Process Repository application   Fig. 7.   Sliver Process Server application             Fig. 8.   Sliver Client application



also creates a separate SOAP service which allows the client                parser adapted from Xydra [20]. These two lightweight parsers
to retrieve the WSDL descriptions of processes with which                   support a useful subset of WSDL and XSD. Namely, the
it wishes to interact. Like the repository’s SOAP service, this             combination does not support WSDL imports; XSD derived
SOAP service has a well-known ID and interface.                             types; or XSD restrictions. All three features are convenient,
                                                                            but are significantly more complex to parse than other parts
C. Process Client                                                           of the standards. Also, the first two features do not offer
   The final major component of this system is the client                    any additional expressive power, and could be removed from
application. This client is fully generic: users can discover and           WSDL documents using a series of static transformations. We
participate in workflow processes without any prior knowledge                feel this trade-off is reasonable: while these omissions may
of them. On startup, processes hosted on local servers are dis-             create a slight burden for the process developer, they also make
covered using Bluetooth service discovery and are presented                 OTA deployment feasible, greatly increasing the processes’
to the user in a list. Once the user selects a process from a list,         utility.
he may select a message type to send to the process and input                                      VI. S AMPLE A PPLICATION
the message’s contents. After the initial message has been sent,
any responses from the process are displayed on the screen.                    To demonstrate the effectiveness of our BPEL deployment
   As we described in Section II, BPEL uses SOAP as its                     and execution environment in pervasive computing settings,
underlying message-passing mechanism. This trait allows the                 we have used Sliver to implement the auction application
client application to be fully generic. SOAP defines a consis-               described in Section I. We have deployed this application on
tent structural representation for all messages that the BPEL               a Linux PC using Sun’s Java Wireless Toolkit [21], and a
process will produce and consume. Hence, Sliver’s SOAP                      Nokia 6682 mobile phone2 . Each component of our applica-
serialization components are suitable for interacting with any              tion is distributed as monolithic .JAR file, which has been
remote BPEL process.                                                        post-processed with ProGuard in order to reduce bytecode
   However, the client not only must consider the structure                 size. In this section, we discuss how this auction application
of the messages, but also their contents. That is, SOAP stan-               leverages the BPEL extensions described in Section III and the
dardizes how to express a message object as structured XML;                 deployment mechanism described in Section V to interact with
but it does not mandate which data types are composed to                    hosts in a pervasive computing environment. This application,
create that message. The latter is expressed using the process’s            along with the Sliver middleware which it embeds, is available
WSDL description, which describes message contents using                    as open-source software at [22].
an embedded XSD schema. Using this WSDL document, the                          The auction workflow consists of a 4.5KB BPEL document
client application can assemble a customized form-style UI on               and a 4.2KB WSDL descriptor. Despite the application’s small
the fly for each process, as is shown in Figure 8.                           size, it offers a considerable amount of functionality. Sellers
   Unfortunately, WSDL and XSD are complex standards, and                   may create a new auction with a user-specified description,
mobile devices cannot reasonably be expected to host a full                   2 This particular application uses the MIDP UI toolkit, which prevents its
WSDL and XSD parser. We address this issue by deploying                     native deployment on J2SE devices. This is not a limitation of Sliver, which
a custom WSDL parser, which includes a lightweight XSD                      natively supports both J2SE and MIDP devices.
<partnerLinks>
  <ext:partnerLink name="buyer" ... />                               hosted on the server will not initiate outgoing connections to
  <ext:partnerGroup name="buyers" ... />                             other services. These assumptions do not represent inherent
  ...                                                                limitations of Sliver’s design or of BPEL: rather, they were
</partnerLinks>
...                                                                  made to streamline the user interface, and could be lifted with
<eventHandlers>                                                      additional UI code.
  <onMessage operation="bid" partnerLink="buyer" ...>
    <sequence name="handleBid">                                                          VII. R ELATED W ORK
      <ext:add partnerGroup="buyers"
          partnerLink="buyer" />                                        [23] proposes HSN-SOA, a decentralized system for man-
      ...                                                            aging networked appliances in pervasive computing settings.
      <ext:reply partnerGroup="buyers"
          operation="bid" variable="auctionStatus"                   Using the service scenario scripting (S 3 ) editor, users generate
          moreMessages="yes" />                                      workflow graphs which describe reactive interactions among
      <ext:unbind partnerLink="buyer" />                             appliances (e.g., when the user turns on the TV, the TV
  </onMessage>
  ...                                                                turns on the speakers and dims the lights). The S 3 editor
</eventHandlers>                                                     autonomously subdivides these graphs and distributes the plan
                                                                     fragments to the corresponding devices in the local network.
      Fig. 9.   Code Fragment to Send Multicast Auction Updates
                                                                     After the plan is fragmented and distributed, no centralized
                                                                     coordinating server is required to execute the plan. Though
                                                                     HSN-SOA does not use BPEL, it relies heavily on other
price, and length. Interested buyers may submit bids for the         Web standards: appliances are exposed to the local network
auction, or simply request information about the auction’s           as SOAP services, and their capabilities are advertised using
status (e.g., the item’s current price). The seller and all buyers   WSDL descriptions. However, HSN-SOA implicitly assumes
are automatically notified when the auction’s price changes,          a stable network, and requires users to describe plans in terms
and when the auction ends.                                           of specific appliances. Hence, it does not address environments
   The process’s functionality and compactness draws heavily         where devices are added to or removed from the network after
from the extensions described in Section III. As new buyers          the plans have been written.
participate in the auction, they are collected into a single            [24] describes a prototype system that autonomously gen-
partner group. This permits an unbounded number of buyers            erates BPEL workflows in pervasive computing settings. The
to participate in the auction, and allows the process to send        user issues a description of a goal or task to a Task Selection
multicast updates to all buyers with a single line of BPEL           Service residing on his mobile device. This service invokes a
code. The process also takes advantage of the ability to specify     Task Planner Service on a centralized server, which generates
when partner links close, in order to send an unlimited number       and executes a customized BPEL process. In turn, this custom-
of update messages back to the seller and buyers. The code           generated process invokes Web services on the local network,
snippet in Figure 9 illustrates the use of these extensions in the   including services which reside on the user’s device, in order
auction process. In all, the entire process is modeled in under      to carry out the plan. The server also generates a Web front-
130 lines of BPEL code, including abundant whitespace.               end to the process, so that the user may monitor its execution
   Owing to Sliver’s compactness and modularity, the entire          from his mobile device using a Web browser. This approach
system can be deployed with low storage space and bandwidth          avoids many of the shortcomings in BPEL’s communication
impact. The auction process is initially deployed using the          scheme, since processes can be generated on-the-fly based on
repository application discussed in Section V-A. This reposi-        what devices are available at the time. However, it requires that
tory application requires 48KB of storage space initially, and       a heavyweight centralized server be available to all devices in
an additional 8.7KB of space to store the process.                   the network, which may be unreasonable in many pervasive
   After being deployed on the repository application, the           networks. Scalability is also a concern, since all processes are
auction process can be discovered and downloaded by the              hosted and executed on the centralized server rather than on
process server application described in Section V-B. The             the mobile devices.
process server application consumes 181KB of storage space,
and uses 8.7KB of bandwidth to download the auction process.                  VIII. C ONCLUSIONS AND F UTURE W ORK
Once the auction process is deployed, the client described              In this paper, we have proposed and evaluated a series
in Section V-C can discover and interact with it. The client         of BPEL extensions that support the creation of flexible,
application consumes 88KB of storage space, and only needs           standards-based pervasive computing applications, even when
to download the 4.2KB WSDL file in order to participate in the        the devices involved are mobile. As a proof-of-concept, we
auction. Though this system is lightweight, it is not specific to     have used the Sliver middleware to implement a system for
the auction application: it can be reused for any other BPEL         deploying, executing, and participating in BPEL processes
process stored in the process repository.                            over-the-air. This system comprises three Java applications
   Our implementation currently assumes that the repository,         ranging from 48KB to 181KB in size, and has been de-
server, and clients are all located on different devices. As we      ployed on MIDP-compatible devices. Sliver does not currently
discussed in Section V-B, we also assume that the processes          support some of BPEL’s most advanced features, including
Compensation. Many of these advanced features are intended                     [8] Oracle, “Oracle BPEL process manager,” http://www.oracle.com/
for long-running business transactions and will be used rarely                     technology/products/ias/bpel/index.html, 2006.
                                                                               [9] Sun Microsystems, Inc., “NetBeans enterprise pack,” http://www.
in pervasive and mobile applications. Nevertheless, we plan to                     netbeans.org/products/enterprise/, 2006.
address Sliver’s remaining BPEL compliance issues in future                   [10] OASIS Open, “Web services business process execution
work, and consider ways to further modularize Sliver.                              language version 2.0 public review draft,” http://docs.oasis-
                                                                                   open.org/wsbpel/2.0/wsbpel-specification-draft.html, August 2006.
   Standardization efforts like BPEL play a significant role in                [11] P. Wohed and et. al., “Pattern based analysis of BPEL4WS,” Queensland
developing pervasive computing applications. These standards                       University of Technology, Tech. Rep. FIT-TR-2002-04, 2002.
are one part of a larger effort to deploy robust collabora-                   [12] E. Lafortune, “ProGuard,” http://proguard.sourceforge.net/, 2006.
                                                                              [13] F. Kuhns and et. al., “The design and performance of a pluggable
tive applications in mobile settings. This effort encompasses                      protocols framework for CORBA middleware,” in Proceedings of the
other important topics, ranging from user interface design to                      Sixth International Workshop on Protocols for High Speed Networks
data routing mechanisms, that have yet to be fully resolved.                       (PfHSN ’99). Kluwer, B.V., 2000, pp. 81–98.
                                                                              [14] Apache Software Foundation, “Axis 2.0 - axis2 architecture guide,” http:
However, standards-based middleware like Sliver demonstrate                        //ws.apache.org/axis2/1 0/Axis2ArchitectureGuide.html, 2006.
the feasibility of deploying sophisticated collaborative appli-               [15] S. Haustein, “kXML 2,” http://kxml.sourceforge.net/kxml2/, 2005.
cations on mobile devices, and offer a concrete platform on                   [16] S. Haustein and J. Seigel, “kSOAP 2,” http://ksoap.org/, 2006.
                                                                              [17] W. M. P. van der Aalst, A. H. M. ter Hofstede, B. Kiepuszewski, and
which these other challenges can be explored.                                      A. P. Barros, “Workflow patterns,” Distributed and Parallel Databases,
                            R EFERENCES                                            vol. 14, no. 1, pp. 5–51, 2003.
                                                                              [18] M. Duflot, M. Kwiatkowska, G. Norman, and D. Parker, “A formal
[1] C. E. Ortiz, “J2ME technology turns 5!” http://developers.sun.com/             analysis of Bluetooth device discovery,” Int. J. Softw. Tools Technol.
    techtopics/mobility/j2me/articles/5anniversary.html, 2004.                     Transf., vol. 8, no. 6, pp. 621–632, 2006.
[2] OASIS Open, “OASIS web services business process execution lan-           [19] C. E. Ortiz, “Introduction to OTA application provisioning,”
    guage (WSBPEL) TC,” http://www.oasis-open.org/committees/tc home.              http://developers.sun.com/techtopics/mobility/midp/articles/ota/,
    php?wg abbrev=wsbpel, 2006.                                                    November 2002.
[3] D. Box and et. al., “Simple object access protocol (SOAP)                 [20] O. Chipara and A. Slominski, “Xydra — an automatic form generator
    1.1,” W3C, Tech. Rep. 08 May 2000, 2000. [Online]. Available:                  for web services,” http://www.extreme.indiana.edu/xgws/xydra/, 2003.
    http://www.w3.org/TR/2000/NOTE-SOAP-20000508/                             [21] I. Sun Microsystems, “Sun Java wireless toolkit for CLDC,” http://java.
[4] G. Hackmann, M. Haitjema, C. Gill, and G.-C. Roman, “Sliver: A BPEL            sun.com/products/sjwtoolkit/, 2006.
    workflow process execution engine for mobile devices,” Washington          [22] G. Hackmann, “Sliver,” http://mobilab.wustl.edu/projects/sliver/, 2006.
    University, Department of Computer Science and Engineering, Tech.         [23] M. Nakamura and et. al., “Implementing integrated services of net-
    Rep. WUCSE-06-37, 2006.                                                        worked home appliances using service oriented architecture,” in Pro-
[5] E. Guttman, “Autoconfiguration for IP networking: Enabling local                ceedings of the 2nd International Conference on Service Oriented
    communication,” IEEE Internet Computing, vol. 05, no. 3, pp. 81–86,            Computing (ICSOC ’04), 2004, pp. 269–278.
    2001.                                                                     [24] A. Ranganathan and S. McFaddin, “Using workflows to coordinate web
[6] J. Clark and S. DeRose, “XML path language (XPath) version 1.0,”               services in pervasive computing environments,” in Proceedings of the
    W3C, Tech. Rep. 16 November 1999, 1999. [Online]. Available:                   2004 IEEE International Conference on Web Services (ICWS 2004),
    http://www.w3.org/TR/1999/REC-xpath-19991116                                   2004.
[7] W. Emmerich and et. al., “Grid service orchestration using the business
    process execution language (BPEL),” Journal of Grid Computing, vol. 3,
    no. 3, pp. 283–304, 2005.

				
DOCUMENT INFO
Shared By:
Categories:
Stats:
views:53
posted:3/5/2010
language:English
pages:10