Using BPEL to Realize Business Processes for an ...

Using BPEL to Realize Business Processes for an Internet of Things Nils Glombitza, Sebastian Ebers, Dennis Pfisterer, and Stefan Fischer Institute of Telematics, University of L¨ ubeck Ratzeburger Allee 160, 23538 L¨ ubeck, Germany {glombitza, ebers, pfisterer, fischer}@itm.uni-luebeck.de

Abstract. In the vision of an IoT, trillions of tiny devices extend the Internet to the physical world and enable novel applications that have not been possible before. Such applications emerge out of the interaction of these devices with each other and with more powerful server-class computers on the Internet. Programming such applications is challenging due to the massively distributed nature of these networks combined with the challenges of embedded programming. In addition, resource constraints, device heterogeneity, and the integration with the Internet further complicate this situation. In this paper, we present a programming-in-thelarge approach for resource-constraint devices such as wireless sensor nodes. Our approach is to model such applications using the Business Process Execution Language (BPEL), which is successfully and widely used in the Internet to model complete applications and business processes. However, BPEL and its associated technologies are too resourcedemanding to be directly applied in resource-constraint environments. We therefore use the BPEL model as input to a code generation process that generates custom-tailored, lean code for different target platforms. The resulting code is fully standard-compliant and allows a seamless integration of IoT devices in enterprise IT environments. We present an exhaustive evaluation on real hardware showing the first-rate performance of the approach. Keywords: BPEL, WSN, Sensor Networks, Business Process Modeling, Web Services

1

Introduction

In the vision of the IoT, trillions of tiny devices extend the Internet to the physical world and enable novel applications that have not been possible before. Such applications emerge out of the interaction of these devices with each other and with more powerful server-class computers on the Internet. Programming such applications is challenging due to the massively distributed nature of these networks combined with the heterogeneity of the devices. In this paper, we present a programming-in-the-large approach for resource-constraint devices such as wireless sensor nodes. Our approach is based on the observation that programming

individual applications in an Internet of Things (IoT) is hardly possible anymore and the fundamental challenge is the integration with the Internet on an application level. In the Internet, Service Oriented Architectures (SOA) are increasingly used to model, implement, and execute complex applications and business processes. The predominant language for modeling this is the Business Process Execution Language (BPEL) orchestrating individual services to complete applications. BPEL uses standard Web Services as communication technology. Web Services are based on standard Internet technologies such as SOAP and XML for message encoding and HTTP and TCP/IP for message transport. By contrast, wireless sensors nodes are often programmed using low-level embedded languages and accessed using proprietary protocols. The main reasons for this are the embedded nature and the severe resource constraints of wireless sensor nodes. The desire for long lifetimes paired with constrained energy supply from batteries implies that computing power, memory capacity, and networking bandwidth are several orders of magnitude smaller than those found in backend IT systems and require optimized software and networking solutions. In this paper, we present a standard-compliant approach to integrate resourceconstraint devices into BPEL-based processes. However, BPEL and its associated technologies are too resource-demanding to be directly applied in resourceconstraint environments. We therefore use BPEL models as input to a code generation process that generates custom-tailored, lean code for different target platforms. The resulting code is fully standard-compliant and allows a seamless integration of IoT devices to the Internet. Using our approach, IoT devices become first-class citizens in business processes and allow the execution of business processes directly on sensor nodes. We present an exhaustive evaluation on real hardware showing the first-rate performance of the approach. The remainder of this paper is structured as follows. In the following section, we introduce a motivating use-case which is also used in our evaluation. Section 3 introduces fundamental technologies of Web Service-based business process modeling and execution and Section 4 introduces related work. Section 5 introduces our concept in detail and Section 6 presents implementation details. Finally, Section 7 evaluates our approach and Section 8 concludes this paper with a summary.

2

Use Case

As a use case, we consider a logistics process where companies are concerned with storing and shipping trailers with dangerous goods. For their storage inside port areas as well as on ferry ships, strict laws and rules apply. For instance, dangerous goods must be declared at port authorities and shipping lines. In addition, trailers carrying different types of dangerous goods must have a minimum distance between them. In this work, we present two business processes which are part of the process of shipping dangerous goods and both processes are actually executed on sensor nodes.

The first, quite simple, process is concerned with storing cargo data on a sensor node attached to a trailer. This process receives a cargo information message (carrying cargoID and amount encoded as two integer values) from the cargo dispatcher, checks if there is enough space on the trailer and stores this data. It replies with a message containing the amount of stored cargo (encoded as an integer).

send cargo information and position

alarm

rule is violated

confirm

process cargo information

send new parking information

send alarm

Trailer a (cargo monitoring)

Port authority

handle new location information

reply own cargo information and position

Trailer b

Fig. 1. Monitoring Dangerous Cargo in the Parking Lot of a Port (CargoMonitoring)

The second process (executed on each trailer’s sensor node) is more complex and ensures that two trailers with dangerous goods never park too close to each other (cf. Figure 1). Imagine that trailer a parks inside a port’s area and a second trailer b arrives and parks close to a. Additionally, b joins the ad-hoc network built by all parking trailers. b sends its cargo information and position to a which replies with the same information. Both check if they are allowed to park that close together. If this is not the case, they invoke an alarm service at the port authority. Afterwards, they are waiting to be told to park at a new position; this is answered with a confirmation.

3

Fundamentals

In this section, we introduce conceptual and technological fundamentals required to realize Web Service-based business process modeling and execution in sensor networks. 3.1

Business Process Modeling

The BPEL (Business Process Execution Language, [16]) language is the de-facto standard in enterprises to model and execute Web Service-based business processes. BPEL processes are typically designed using graphical tools that provide a domain-specific and process-oriented definition of processes. These tools allow domain experts to realize the business processes’ IT realization without a need

for IT experts. BPEL processes are often generated automatically during modelto-model transformations from other, sometimes proprietary, business process modeling standards. In BPEL, individual activities are provided by external Web Services which are used by a BPEL process. A Web Service used by a BPEL process is called a Partner Link. Each BPEL process itself exposes its functionality in the form of one or many Web Services. Hence, a BPEL process can again be used by another BPEL process. To model the flow of a business process, BPEL provides basic activities and functions for simple data manipulations as well as exception and transaction handling. With so-called structured elements such as loops or conditional commands, the control flow between activities can be modeled. Since BPEL is an XML-based language, direct storage and execution (which means interpretation of the BPEL document at run-time) on a sensor node is not possible due to the resource-constraints imposed by typical sensor network hardware. We discuss how BPEL can be applied to sensor networks in Section 5. 3.2

Web Services for Sensor Networks

Management

As mentioned above, Web Services are the basis for describing, executing, and using BPEL-based business processes. To make use of them in sensor networks, sensor nodes must be able to use and to expose Web Services. In this section, we discuss the challenges of using Web Services on sensor nodes and discuss viable solutions. As shown in Figure 2, the normal Web Service technology stack uses wellknown Internet technologies such as XML and SOAP [20] for encoding Web Service messages as well as HTTP or SMTP over TCP/IP for conveying these messages from source to sink. However, these technologies easily overburden the scarce resources of WSN platforms. Using Web Services in such environments therefore requires two things: an efficient encoding of XML/SOAP-messages and a lean transport protocol instead of the resource-demanding HTTP over TCP/IP.

BPEL, WWF, ...

Business Process

WSDL

Description

SOAP Message XML HTTP, SMTP, ... TCP/IP, UDP/IP

SOAP Message Compression LTP Any Routing/ Networking Protocol

Transport

Fig. 2. Extended Web Service Technology Stack

In previous work, we have presented a solution for each of these two challenges. In [18], we introduced a highly efficient compression scheme for XML messages called microFibre and in [8], we propose a lightweight Web Service transport protocol (called Lean Transport Protocol, LTP) which can optionally use technologies such as microFibre to convey compressed XML messages (called SOAP message compression or SMC in the following). The integration of LTP and SMC into the standard Web Service architecture is depicted in Figure 2. Even if HTTP and XML are the predominant choice in the Internet, the Web Service technology stack does not prescribe their use. A property of our LTP and SMC is that they are fully standard-compliant to Web Services. In the following, we briefly introduce the main features and properties of LTP and SMC. The basic idea of microFibre (or SMC in general) is to exploit structural knowledge about the exchanged XML messages and provide a custom-tailored (de-)compression code. This is possible since Web Services and the SOAP messages exchanged between server and client are well-defined in WSDL (Web Services Description Language, [3]) and XML Schema documents. This structural knowledge can be exploited to compress XML documents adhering to such a grammar more efficiently than using general or none-schema-based XML compressors. In principle, LTP/SMC supports any payload type (e.g., plain XML or microFibre encoding) but in the following, we use microFibre due to its high compression ratios and its mature code generation framework that produces (de)serialization code for various WSN platforms and programming languages. For more information please refer to [8, 18]. As mentioned above, LTP is a light-weight Web Service transport protocol. It allows an exchange of Web Service messages between 1. 2. 3. 4.

sensor nodes within a single WSN, hosts in the Internet (e.g., enterprise IT servers), sensor nodes and hosts in the Internet, and sensor nodes in different (remote) WSNs.

To support these communication patterns, LTP is realized as an overlay network. To address arbitrary Web Service endpoints, a standard-compliant URLbased addressing scheme is used (e.g., ltp://[email protected]/ WS). The message exchange is transparent to the user or developer. In the Internet, LTP packets are forwarded using TCP or UDP while inside a sensor network arbitrary transport and routing protocols are supported. For instance an application specific tree-routing protocol or even the recently standardized IPv6-based 6LowPAN [12] could be used. Gateways then convert between the WSN and the Internet protocols. Thus, we can adapt LTP to the applicationspecific needs of the WSNs since due to clustering, duty cycling, etc., routing protocols in WSNs are very application-specific. In addition to the message exchange as core feature of LTP, it optionally provides header compression as well as message fragmentation in order to address limited bandwidth and radio packet sizes of WSNs. For more information and a thorough evaluation, please refer to [8, 9].

4

Related Work

In literature, some authors present approaches that use SOA programming paradigms as well as Model-driven Software Development (MDSD) to develop sensor network applications. But to the best of our knowledge, there is no contribution that combines MDSD (or business process modeling in particular) with a Web Service-based SOA in WSNs. In this section, we present related work and discuss similarities and differences to our contribution. In [1], Amundson et al. present a SOA-based approach for WSNs. While Web Services are used in the Internet, proprietary protocols are used inside the WSN. A gateway is needed to convert between both communication protocols. PandPandey et al. [17] and Glombitza et al. [8] present approaches to integrate sensor networks into business processes utilizing the BPEL standard for the process definition and execution. However, both approaches run the business processes in the backend. With Flow [14,15], Naumowicz et al. present a graphical editor and different domain specific languages for implementing WSN applications. Fuchs et al. [6] propose an activity diagram based approach to execute tasks on different sensor nodes. In both approaches, neither Web Services nor the SOA concept is utilized. Sliver [11] is a light-weight BPEL-Engine running on PDA-class devices. It is based on standard-compliant Web Service technologies but demands for too many resources to run on sensor nodes. A first approach to run BPEL processes on sensor nodes is proposed by Spieß et al. [19]. BPEL processes can be executed distributed inside the WSN as well as in the backend. However, as communication technology no Web Services are used. In [10], Glombitza et al. present SM4RCD (State Machine for Resource Constrained Devices) as state machine-based domain specific language to orchestrate Web Services. SM4RCD is executed on sensor nodes and utilizes standard-compliant Web Services as communication technology.

5

Designing Business Processes for Sensor Networks

As mentioned in the introduction, business processes are characterized by a permanent adoption to constantly changing market requirements and enterprise strategies. This business process-driven necessity can only be fulfilled if the IT systems allow for a fast and flexible adoption as well. Current enterprise IT systems fulfill this requirement by using different business process modeling and execution methods. However, for WSNs, no such technology exists as of today. We propose to use graphical business process modeling methods to realize business processes which are executed on sensor nodes. To realize this, the following three requirements have to be fulfilled: 1. Reusability of functionalities encapsulated in self-contained services. 2. Communication via standardized protocols enabling the use of distributed services which can even be used in inter-enterprise relationships. 3. A business process-specific, graphical language to define business processes by composing services and defining arbitrary control flows.

In the following, we first introduce our approach on the conceptual layer (cf. Section 5.1) before describing the technological perspective (cf. Section 5.2). 5.1

Concept

Our approach combines the SOA (Service Oriented Architecture) concept with business process modeling methods in order to achieve a fast and flexible as well as business process-driven definition of processes in WSNs. Service Oriented Architecture. According to the SOA concept, application logic is encapsulated in self-contained services which provide their functionalities via clearly defined interfaces and loosely coupled communication connections. Thus, existing services can be easily combined to new services providing higher-level functionalities. In such a SOA realization, services can range from basic services (e.g., the storing of a bill of loading) to high-level services (e.g., the monitoring of dangerous goods). In our approach, not only every functionality of enterprise IT components but also the functionalities of sensor nodes are encapsulated in services. As result, an easy and flexible reuse of existing functionalities is provided which reduces development times and costs of WSN applications. Business Process Modeling. Using the SOA concept improves application and business process development in WSNs since a reimplementation of already existing functionalities is avoided. However, highly specialized WSN experts are still needed to orchestrate existing services to new ones since this task has to be done using classical or WSN-specific programming languages such as C, C++ or nesC. Thus, a technical process realization by a domain expert is impossible. Business processes always have to be designed by a domain expert from the business perspective in a first step before a WSN expert can realize this process as an executable application. As a result, error-proneness and timeto-market are still very high. In our approach, we propose to use standard business process modeling languages in order to allow for a fast, flexible and less error-prone definition of business processes from a business perspective. Thus, allowing domain experts to easily define these processes with a graphical tool support. Furthermore, all process models are platform-independent and can be easily executed on different WSN and enterprise IT platforms. 5.2

Architecture

In enterprise IT environments, Web Services are the predominant technology used to realize SOAs. As described in Section 3.1 and depicted in Figure 2, there are a lot of business process modeling languages which orchestrate services to business processes using Web Services as middleware. The most important Web Service-based business process modeling and execution language is BPEL which is widely spread in enterprise IT environments. To be compatible to these systems as well as to benefit from existing tools, we propose to use BPEL on the

business process as well as Web Services on the communication layer to realize business process modeling in WSNs. Web Services. As depicted in Figure 2, BPEL requires SOAP Web Services using WSDL (Version 1.1) as its interface definition language. In Section 3.2, we introduced our approach of realizing efficient Web Services which are applicable in WSNs (LTP for Web Service message transport and SMC for the efficient compression of SOAP messages). LTP and SMC are fully compliant to the SOAP (Version 1.2) and WSDL (Version 1.1) standards which allows them to be used as a Web Service transport binding for BPEL (for details please refer to [8]). Using LTP/SMC, a transparent message exchange between sensor nodes and enterprise IT systems is achieved (cf. Section 3.2). As a result, BPEL processes running on sensor nodes can use services in different WSNs and enterprise IT environments and vice versa. Executing BPEL on Sensor Nodes. In our approach, we use standardcompliant BPEL (Version 2) to define process models. Such BPEL files can be created either manually or using visual BPEL designers. Since BPEL is an XML standard, an XML document representing a BPEL model is generated as output of such a design process. In enterprise IT environments, these models are executed by heavy-weight process execution engines which interpret BPEL XML documents. Since we are targeting sensor nodes as execution platform, interpretation at run-time is not feasible. The storage of the XML process models alone would overburden most WSN platforms. Instead, our approach is to generate custom-tailored code out of the process models.

Parsing & Validating

Linking to a Web Service framework

Linking to an operation system

Genrating WS messaging code

Genrating process logic code

Generating Compiling for process manatarget platform gement code

Fig. 3. Process of Transferring a BPEL Model into Executable Code for Sensor Nodes

Figure 3 depicts the transformation process of BPEL models into code for a WSN platform. After parsing and validating the process model, it is bound to a specific Web Service framework. Architecturally, arbitrary Web Service frameworks for sensor networks are supported but in our current implementation, we only support LTP/SMC as presented in Section 3.2. Afterwards, the generated code is linked to a specific operation system. Again, arbitrary WSN operating systems are supported. In its current version, we support TelosB [4], Pacemate [13], and iSense [2] sensor nodes. A challenge when transforming a BPEL model to code for sensor network platforms is that such platforms (including iSense) do not support multithreading due to resource constraints imposed by the hardware. But as BPEL processes are characterized by parallel control flows, the generated code must emulate the parallel execution of several control flows. We solve this by sequentially executing parallel control flows which only increases execution time but otherwise yields

identical results. Some very special BPEL flows cannot be realized without real multithreading. These—and possible workarounds—are discussed in Section 6. In the next three steps, C++ code for the different process-specific components is generated from the BPEL model. First, for every Partner Link (i.e., an external Web Service used by the BPEL process) of the model, code for the Web Service communication is generated using the WSDL descriptions of the referenced Web Service endpoints. Second, the process flow of the BPEL process is transformed to C++ code representing the application’s logic. And finally, the BPEL runtime is generated which contains code to manage all process instances and incoming messages and to control the process flow. After generating the code comprised of the Web Service clients and servers, the BPEL runtime, and the application logic is compiled for the target platform. The code generation approach has several advantages over interpretation of BPEL: i) Memory and CPU consumption: An interpretation of BPEL would overburden the capabilities of sensor nodes in terms of CPU and memory consumption, ii) Performance: The generation of optimized code for a specific platform, which is compiled to machine code, improves the performance, iii) Code size: The required features of the process engine and the process logic are already known at compile time. Thus, only these are included in the generated code, iv) Compile-time validation: A lot of errors can be detected during compilation which would occur during runtime if interpreting, and v) Logging: Logging instructions are only generated for debugging.

6

Realization

In our approach, we use standard-compliant BPEL. Thus, there was no need to implement a graphical editor to design or adopt BPEL processes; any standardcompliant BPEL editor can be used. We developed a code generator which transforms the XML source code of the BPEL process to C++ code. The generated code can be directly run on any target platform for which a GCC C++ compiler [7] is available. The generated classes Process and Dispatcher represent the BPEL Process Flow and a lean BPEL Runtime, respectively. Additional to creating and destroying process instances on demand, the runtime relays messages from and to the individual process instances. The code for the Web Service messaging layer is generated by microFibre, which is incorporated as module in our code generator but could be easily replaced by a different serializer. As transport binding, compressed SOAP over LTP is used in order to realize the communication patterns presented in Section 3.2. In our approach, we use iSense as operating system and LPT as the Web Service transport layer. These components are used as static libraries which are independent of the process logic. Note that the implementation of the business logic itself is completely independent of these static libraries. The only generated component which depends on the operating system is the runtime component. However, the runtime solely depends on the availability of an interface to register

tasks. Thus, our approach is easily adoptable to any operating system which provides an interface to register tasks. BPEL expects to run multiple processes or parts of them in parallel. The lack of multi-threading capabilities of typical WSN devices leads to two problems: (a) We cannot technically run multiple activities of a process in parallel, which can be modeled using BPEL. (b) Many BPEL processes have to wait for events like the expiration of timers and the arrival of messages. Since we are limited to single-thread execution, setting the process into sleep mode would do the same to the whole device. If the process waits busily, the runtime is blocked and cannot forward the awaited incoming message which would block the whole device, as well. Problem (a) was solved by executing activities modeled to be run in parallel one after another, which might lead to longer overall execution times, but does not influence the semantics. To encounter Problem (b), the originally continuous BPEL graph has to be split into multiple sub-graphs. A sub-graph ends whenever the process has to actually wait for an event, e.g., an incoming message. Each sub-graph’s individual entry point is marked by the processing of an event, e.g., the reception of an awaited message. Hence, even on single-thread devices, the process can wait for events passively.

7

Evaluation

The main benefit of our approach is the enormous reduction of the development effort. We used the COCOMO (Constructive Cost Model, [?]) approach to estimate the development time of realizing the CargoMonitoring use case manually and compared the result to the actual time it took to realize the same process with our approach. With BPEL, it took less than one hour while the estimated development time for a manual implementation is about 7 person months. In the following we present measurements which show that our concept is feasible in the WSN domain and does not impose significant overhead. We evaluated both processes introduced in Section 2 which will be referred to as LoadCargo for the first and CargoMonitoring for the second one, respectively. While LoadCargo’s message payloads just comprises simple integer values, the payload in CargoMonitoring consists of complex data structures. Additionally, LoadCargo is stateless and does not call other Web Services. It is not a typical business process example and due to its simplicity, a process like that would rather be implemented manually. Anyway, it will show the maximum overhead introduced when using our code generation engine. On the contrary, CargoMonitoring is stateful, sends and receives complex messages and calls other Web Services to fulfill its task. Since this is common in ordinary business processes, it is used to show the overhead which is typically to be expected. We compare the memory usage, code and message size as well as the round-trip times of the C++ applications generated by our code generation engine to functional equivalent

but manually implemented and optimized applications to evaluate the overhead introduced by the code generation process. We measure the memory usage of the processes utilizing the WSN-simulator Shawn [5] which simulates a 32 bit platform using the iSense operating system. We use debugging messages to detect the amount of the individual allocations and deallocations of stack and heap memory. Due to the ressource constraints of the devices, this cannot be directly run on sensor node hardware. However, the code and message sizes as well as the round-trip times are evaluated on a Pacemate1 sensor node which runs the iSense OS, too. 7.1

Memory usage

Table 1 summarizes the results of the memory consumption over time. The amount of memory required to enable the application to receive and process messages is denoted as minimal amount. Table 1. Statistical evaluation of the RAM memory usage (in byte) LoadCargo min max avg Generated Process 211 1754 827.6 Manual Implementation 60 1482 660.5

CargoMonitoring min max avg 247 1909 1164.6 200 1798 1100.6

As can be seen by comparing the generated application to its manually implemented equivalent, the overhead significantly depends on the complexity of the process. Since LoadCargo is stateless, the previously described runtime component can be completely omitted in the manual implementation. This results in a 2.52 times higher minimal and a 0.25 times higher average memory usage of the generated application. However, CargoMonitoring is stateful and calls other Web Services which renders the runtime component mandatory. The generated application requires a 0.24 times higher minimal and a 0.06 times higher average amount of memory compared to the manual implementation. 7.2

Code and message sizes

The results of the code size evaluation are depicted in Figure 4(a). Since LTP is used as static library, its code size is constant throughout the evaluation. The Web Service messaging component is generated by microFibre. It is considered to be optimal in the manual implementations of the two processes. However, its code size significantly depends on the quantity of message types as well as the complexity of their payloads. See Table 2 for detailed information about the 1

32 bit ARM processor

messages sent and received by the two processes. When comparing the code size of the process logic which comprises the process flow and runtime component, a significant overhead of about 74, 5% can be noted in LoadCargo. Since this process is stateless and does not call other Web Services, the runtime part is completely omitted in the manual implementation. This is not stipulated by our code generator since it is not a typical business process scenario. In the more complex scenario CargoMoitoring, the runtime part is mandatory for both variants. Due to the optimization of the process flow implementation, we observe an overhead of about 4, 7%. 6.0000

18,000 Process SMC LTP

Code size [byte]

5.0020

4.9980

BPEL

manually

5.0000

14,000

4,476

4,264

4,120

12,000 10,000

3,076 1,388

784 1,388

4,120

8,000

7,052

7,052

7,052

Rountriptime [ms]

16,000

4.0000

3.0000 2.0270 2.0000

6,000

1.0010 1.0000

4,000

7,052 0.0000

2,000

BPEL

0

manually LoadCargo

BPEL

manually

BPEL

LoadCargo

manually

CargoMonitoring

CargoMonitoring

(b) Round-Trip Time

(a) Codesize Fig. 4. Codesize and Round-Trip Time

Table 2. Message Sizes of the Evaluation Processes Process

Message

SendCargoInformation ReplyStorageInformation AlarmRequest AlarmResponse SendCargoInformation CargoMonitoring ReplyCargoInformation SendNewParkingInformation ReplyNewParkingConfirmation LoadCargo

7.3

Size 2 2 12 3 9 9 5 1

B B B B B B B B

Round-trip

As can be seen in Figure 4(b), the round-trip times considerably differ between the two processes which is due to the higher complexity of the process logic as

well as the amount of messages sent and received by CargoMonitoring. Considering CargoMonitoring, the round-trip time of the generated application nearly equals the one of the manually implemented application. Again, a significant difference can be observed comparing the generated and manually implemented version of LoadCargo, which is due to the overhead introduced by the BPEL runtime component of the generated application. These results match those of the previously evaluated parameters: The higher the complexity of the process, the smaller is the amount of the overhead of the generated code compared to a manual implementation. Since the advantages of a model driven software development particularly show for complex scenarios, a small overhead is to be expected when our code generation engine is applied to typical business processes.

8

Conclusion

In this paper, we present a programming-in-the-large approach for resourceconstraint devices such as wireless sensor nodes. In this scenario, applications are modeled using the Business Process Execution Language (BPEL) instead of using low-level embedded programming languages. Our approach is based on a code generation step which transforms BPEL models to source code which easily fits on resource-constraint devices as we show in an exhaustive evaluation conducted on real hardware. Using our approach, sensor nodes become first-class citizens in enterprise IT environments where they offer their services as Web Services and run an application logic as defined in a BPEL model. In addition, as part of the BPEL definition, they consume Web Services offered by other sensor nodes or Internet-based enterprise servers. Using this approach, domain experts can use graphical tools to model business processes without requiring expert knowledge on embedded programming. Our approach is fully standardcompliant and uses the well-defined extension mechanisms of the Web Service technology stack. In addition to qualitative properties such as faster time-tomarket or a less error-prone development process, our exhaustive evaluation shows the first-rate performance of our implementations.

References 1. Amundson, I., Kushwaha, M., Koutsoukos, X., Neema, S., Sztipanovits, J.: Efficient integration of web services in ambient-aware sensor network applications. In: 3rd IEEE/CreateNet International Workshop on Broadband Advanced Sensor Networks (BaseNets 2006) (2006) 2. Buschmann, C., Pfisterer, D.: iSense: A Modular Hardware and Software Platform for Wireless Sensor Networks. Tech. rep., 6. Fachgespr¨ ach Drahtlose Sensornetze der GI/ITG-Fachgruppe Kommunikation und Verteilte Systeme (2007) 3. Christensen, E., Curbera, F., Meredith, G., Weerawarana, S.: Web Services Description Language (WSDL) 1.1. Tech. rep., World Wide Web Consortium W3C (2001), http://www.w3.org/TR/wsdl.html

4. Crossbow Technology Inc.: TELOSB - TelosB Mote Platform (2009), http://www. xbow.com/ 5. Fekete, S., Fischer, S., Kroeller, A., Pfisterer, D.: Shawn. Simulator for sensor networks by the SwarmNet project (2004), http://www.swarmnet.de/shawn 6. Fuchs, G., German, R.: UML2 Activity Diagram based Programming of Wireless Sensor Networks. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering and ICSE Workshops (2010) 7. GCC team: GCC, the GNU Compiler Collection (2010), http://gcc.gnu.org/ 8. Glombitza, N., Pfisterer, D., Fischer, S.: Integrating Wireless Sensor Networks into Web Service-Based Business Processes. In: MidSens ’09: Proceedings of the 4th International Workshop on Middleware Tools, Services and Run-Time Support for Sensor Networks. pp. 25–30. ACM, New York, NY, USA (2009) 9. Glombitza, N., Pfisterer, D., Fischer, S.: LTP: An Efficient Web Service Transport Protocol for Resource Constrained Devices. In: Seventh Annual IEEE Communications Society Conference on Sensor, Mesh, and Ad Hoc Communications and Networks (IEEE SECON’ 10) (2010) 10. Glombitza, N., Pfisterer, D., Fischer, S.: Using State Machines for a Model Driven Development of Web Service-Based Sensor Network Applications. In: Proceedings of the 32nd ACM/IEEE International Conference on Software Engineering and ICSE Workshops. Cape Town, South Africa (2010) 11. Hackmann, G., Gill, C., Roman, G.C.: Extending BPEL for Interoperable Pervasive Computing. In: Proceedings of the 2007 IEEE International Conference on Pervasive Services. pp. 204–213 (2007) 12. Kushalnagar, N., Montenegro, G., Schumacher, C.: IPv6 over Low-Power Wireless Personal Area Networks (6LoWPANs): Overview, Assumptions, Problem Statement, and Goals. RFC 4919 (Informational) (Aug 2007), http://www.ietf.org/ rfc/rfc4919.txt 13. Lipphardt, M., Hellbrueck, H., Pfisterer, D., Ransom, S., Fischer, S.: Practical experiences on mobile inter-body-area-networking. In: Proceedings of the Second International Conference on Body Area Networks (2007) 14. Naumowicz, T., Schr¨ oter, B., Schiller, J.: Demo Abstract: Software Factory for Wireless Sensor Networks. In: 6th European Conference on Wireless Sensor Networks (EWSN 2009) (feb 2009) 15. Naumowicz, T., Schr¨ oter, B., Schiller, J.: Poster Abstract: Prototyping a Software Factory for Wireless Sensor Networks. In: 7th ACM Conference on Embedded Networked Sensor Systems (SenSys 2009) (nov 2009) 16. OASIS WS-BPEL Technical Committee: Webservices – Business Process Execution Language Version 2.0. Tech. rep., http://www.oasis-open.org/committees/ wsbpel 17. Pandey, K., Patel, S.: A Novel Design of Service Oriented and Message Driven Middleware for Ambient Aware Wireless Sensor Network. In: International Journal of Recent Trends in Engineering (IJRTE) (may 2009) 18. Pfisterer, D., Wegner, M., Hellbr¨ uck, H., Werner, C., Fischer, S.: Energy-optimized Data Serialization For Heterogeneous WSNs Using Middleware Synthesis. In: Proceedings of The Sixth Annual Mediterranean Ad Hoc Networking Workshop (MedHoc-Net’ 07). pp. 180–187 (Jun 2007) 19. Spieß, P., Vogt, H., Jutting, H.: Integrating sensor networks with business processes. In: Real-World Sensor Networks Workshop at ACM MobiSys (Jun 2006) 20. World Wide Web Consortium (W3C): SOAP Specifications. Tech. rep. (2007), http://www.w3.org/TR/SOAP/