Internet of Things Aware WS-BPEL Business Process

Dulce Domingos, Francisco Martins and Carlos Candidoˆ LaSIGE - Faculty of Science, Lisbon University, Campo Grande, Lisbon, Portugal

Keywords: Internet of Things, Business Process, WS-BPEL.

Abstract: Business process can benefit from the deployment of the Internet of Things, since they can use sensor context information to optimize their execution and to react to emergent situations in real-time. Nowadays, the WS- BPEL is the de-facto standard language used to define processes through the composition of web services. However, as this language is based on the service orchestration paradigm, it complicates the way process can use context information. This paper presents a WS-BPEL extension that includes context variables. These vari- ables maintain sensor values. Their updates are done automatically by using the publish/subscribe paradigm. In addition, to support more reactive behaviours, this extension also includes the when-then construct. To realize this extension, we use the language transformation mechanisms, so it can be as much independent as possible from the process execution engine.

1 INTRODUCTION The work we present in this paper aims at simpli- fying the use of updated sensor context information in The Internet of Things (IoT) aims at bridging the business processes and at defining more reactive pro- gap between the physical world and its representation cesses. We define a WS-BPEL extension to include within information systems. It will definitely have a context variables, which are update asynchronously deep impact on business processes, since they can use through the publisher/subscriber paradigm, according the context information IoT provides to optimize their to the WS-Notification standard. We support context execution and to adapt to environment changes, in real variable with a language transformation. This option time. has the advantage of being independent from the pro- The WS-BPEL (OASIS, 2007) is a OASIS stan- cess execution engine. dard used to define processes as web services compo- In addition, our WS-BPEL extension also include sitions, i.e., orchestrations of web services. To facil- the when-then construct. The when condition can in- itate the IoT integration into business processes, re- clude context variables. We also support this con- cent works provide the information and functionali- struct with a language transformation. However, our ties of physical objects as web services. These web implementation depends on an auxiliary service that services can be implemented directly in sensors or detects the modification of variable values. In our pro- through middleware (Zeng et al., 2011). The service- totype, we use Apache ODE listeners (Apache ODE, oriented approach has the advantage of facilitating in- 2013). teroperability as well as it also encapsulates hetero- We present a motivating scenario in the next sec- geneity and specificities of physical objects. As the tion. Section 3 resumes the standards we use in this WS-BPEL is based on service orchestration, the sen- work. We describe related work in section 4 and our sor information that web services provide can be eas- WS-BPEL extension in section 5. The last section in- ily integrated into processes by using a synchronous cludes conclusions and future work. request/reply paradigm. However, with this paradigm, if a process needs to have updated information about environment 2 MOTIVATING SCENARIO changes, it has to get sensors information periodically, overloading the process execution engine and increas- Our motivating scenario is based on a common busi- ing the number of exchanged messages between the ness application: the transportation of goods. sensor network and the execution engine. A distribution company receives a container of

Domingos D., Martins F. and Cândido C.. 505 Internet of Things Aware WS-BPEL Business Process. DOI: 10.5220/0004449905050512 In Proceedings of the 15th International Conference on Enterprise Information Systems (ICEIS-2013), pages 505-512 ISBN: 978-989-8565-60-0 Copyright c 2013 SCITEPRESS (Science and Technology Publications, Lda.) ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

strawberries on a pier discharge. After unloading, the 3.3 Web Services Notification container is placed on a truck and transported to the distribution center, from where they are distributed to Web Services Notification (WSN) (OASIS, 2006) de- retail stores. The container has temperature sensors fines a set of specifications that aim at defining how and they are used to monitor the strawberries state. web services interact using notifications or events. During transportation, the temperature inside the con- The communication uses the publisher/subscriber tainer raises above the value that guarantees strawber- paradigm, where an entity can publish information to ries quality. If the company maintains the destination others without having to know them in advance. The of strawberries, they will reach consumers in bad con- specifications provide WSDL interfaces. We point out ditions. To avoid this waste, when they get the infor- the interfaces for two services: the publisher service mation about the raise of temperature, they change the (NotificationProducer) and the service that receives container destination and it is forwarded to a closer notifications (NotificationConsumer). They specify distribution center. the minimum operations that each service must pro- In this use case scenario, we illustrate the benefits vide: the publisher service has to provide the sub- of monitoring context information, i.e., the tempera- scribe and get-CurrentMessage operations, and the ture of the container, and consequently, the possibil- consumer service has to provide the operation to re- ity to change the process to react to context modifica- ceive notifications, the notify operation. When invok- tions. ing the subscribe operation, the subscriber must de- To include this behaviour into a WS-BPEL pro- fine, among other things, the EPR to where the notifi- cess definition, the modeler has to define the interac- cations should be sent. tion with sensors, deviating his focus from the main process logic. 3.4 Web Services Business Process Execution Language

3 CONCEPTS Web Services Business Process Execution Language (WS-BPEL) (OASIS, 2007) is the OASIS standard In this section we present an overview of WS-BPEL. executable language for defining business processes Before that, we present the other standards we use in through web services orchestration. A business pro- this work. cess definition includes two elements: a WSDL file that describes the business process functionalities 3.1 Web Services Addressing (web services) with their messages data structures, services addresses, among others, and a WS-BPEL Web Services Addressing (WS-Addressing) (Box and file that defines the business process logic. et al., 2004) defines transport-neutral mechanisms The WS-BPEL includes different types of activi- that allow web services to communicate addressing ties, such as flow control activities (If, While, Scope, information. This specification defines elements to Flow), communication activities (Receive, Reply, In- uniquely identify web services endpoints using Ex- voke), assign values activities (Assign), fault handlers tensible Markup Language (XML). One of the ele- (Throw, Rethrow), to name a few. We can declare vari- ments is the EndPointReference (EPR), whose field ables of any primitive type, complex type (consisting address represents the web service address. Be- of several primitive data types), and messages. Mes- yond this field, an EPR offers optional fields (such as sage variables are used almost exclusively in commu- the ReferenceParameters), for instance, to distinguish nication activities. Variables can be global or local, if EPRs with the same address. declared within a Scope. Processes in WS-BPEL export and import func- 3.2 Web Services Description Language tionalities by using web services. Web services are modeled as partnerLinks. Every partnerLink is char- Web Service Description Language (WSDL) (Chris- acterized by a partnerLinkType, which is defined in tensen et al., 2001) is a XML-based language used the WSDL definition. A partnerLinkType specifies to describe the functionalities that web services offer. the role and the type of a partner. An input commu- A WSDL web service description includes its name, nication activity is associated with the MyRole and an address (EPR), the service binding (defines the proto- output communication activity is associated with the cols), operations available, exchanged messages, and PartnerRole. possible faults. It contains all the information needed In order to distinguish process instances, WS- to contact a web service. BPEL provides the Correlation mechanism. A corre-

506 InternetofThingsAwareWS-BPELBusinessProcess

lationSet is defined by 1) the primitive data type that Traditionally, context information is obtained ac- will be used and 2) the rule set (one per message type). cording to a synchronous request/response paradigm, The correlationSet is associated with communication and business processes use it in predefined points. activities. Each correlationSet can only be initialized They use context information to: (i) determine the ser- once and, if we use it in an Invoke, we have to define vices that compose processes (Yu and Su, 2009), (ii) when the Correlation is established: in the sending choose between multiple implementations for a spe- operation, in response, or in both. The Correlation- cific service (Ranganathan and McFaddin, 2004), or Sets property defines, through XPATH, the message (iii) determine whether a service should participate in elements exchanged by processes that identifies each future compositions (Karastoyanova et al., 2005). conversation (i.e., each process instance). In (Wieland et al., 2007), the authors propose an The WS-BPEL standard supports extensibility, by extension to WS-BPEL, named Context4BPEL, in or- allowing namespace-qualified attributes to appear in der to explicitly model how context influences work- any WS-BPEL element and by allowing elements flows. The Context4BPEL is defined according to the from other namespaces to appear within WS-BPEL WS-BPEL extension mechanisms. This extension in- defined elements. In addition, WS-BPEL provides cludes mechanisms to: (1) manage context events to two explicit extension constructs: extensionAssign- allow the asynchronous reception of events; (2) query Operation and extensionActivity. context data, and (3) evaluate transition conditions All extensions used in a process must be declared. based on context data. However, Context4BPEL is This statement is made by inserting into the Exten- realized as a ”BPEL Runtime Extension” and conse- sions construct language the namespaces associated quently also needs that the process execution engine with the extensions and the MustUnderstand attribute supports it. In addition, the context information man- with the value yes or no, which states whether the pro- agement depends on the Nexus platform. cess execution engine has to support the extension. In (Wieland et al., 2009), the authors propose There are two different options to realize an ex- a WS-BPEL extension that includes reference vari- tension (Kopp et al., 2011). With a ”BPEL Language ables. With this kind of variables, the services can Transformation”, extension constructs are translated exchange pointers to variables instead of their val- into standard BPEL constructs. The generated stan- ues. Pointers are represented with EPRs. Accord- dard BPEL code can be deployed on a process execu- ing to the value of an attribute of the extension, ref- tion engine that ignores the extension. With the other erences are evaluated (1) upon activation of Scope, option, the ”BPEL runtime engine”, the extension is (2) before variables are used, (3) periodically, or (4) realized by changing the process execution engine in through an event sent from a external service. This ex- order to support the additional functionalities. tension is realized as a ”BPEL Language Transforma- tion”, replacing references with WS-BPEL variables, inserting links to partners and interaction activities. 3.5 XSL Transformations The type (4) of references evaluation is similar to our work: the transformation adds a constructor onEvent Extensible Stylesheet Language Transformations to the process definition. However, these authors do (XSLT) (Clark et al., 2007) is a specification that de- not state how the external service addresses the event fines the syntax and semantics of a language to trans- to the onEvent web service. Additionally, references form and render XML documents. XSLT is designed evaluation depends on the RRS Service (Reference for use as part of the Extensible Stylesheet Language Resolution Service), a specific service available on (XSL), which is a style language for XML. XSL in- the platform the authors propose. cludes an XML vocabulary to specify formatting and George et al. (George and Ward, 2008; George, uses XSLT to describe the document transformation. 2008) also propose a solution based on context vari- ables. These authors extend WS-BPEL by adding new attributes to variables. However, the process def- inition must also contain explicitly the Invoke oper- 4 RELATED WORK ation to realize the subscription. To realize the ex- tension, they use a ”BPEL Runtime Extension” op- In our work, we use context with the same meaning tion, by changing the process execution engine, and as George et al. (George and Ward, 2008; George, they distinguish process instances through the Muse 2008). These authors define context as an environ- Apache platform (Apache Muse, 2013). ment state, which is external to the process, whose value can change independently of the process lifecy- cle, and can influence process execution.

507 ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

5 IoT WS-BPEL EXTENSION 5.2 Context Variables: Language Transformation In this section we present how we extend the WS- BPEL with context variables and with the when-then As previously mentioned, WS-BPEL extensions can construct. We also describe how we realize the exten- be realized as a runtime extension or as a model trans- sion and we present an overview of our prototype. formation. We realize the context variable part of our WS-BPEL extension with a model transforma- 5.1 Context Variables - Language tion. This option has the advantage of making it inde- Extension pendent of the process execution engines. However, as the model transformation operation adds new ac- Our main goal is to simplify the access to context tivities, variables, etc., the process that is executed do information within WS-BPEL processes through the not match exactly the process the modeler defined. new concept of context variable. This way, each vari- In the following, we detail the transformation we able represent the current value of a specific sensor. realize. We use the WS-Notification standard in the As the language already provides a constructor for communication between processes instances and sen- variables, we decided to define context variables by sors. This transformation includes editing the WS- adding new attributes to the constructor. The new BPEL file and creating a WSDL file. attributes represent the minimum information neces- sary to realize the subscribe operation according to 5.2.1 Editing the WS-BPEL File the WS-Notifications standard, and, consequently, the minimum information required to identify a sensor Firstly, we remove the extension attributes from the through a web service. context variables. These variables are now WS-BPEL The following example illustrates the definition of standard variables of type xsd: anyURI. a context variable named tempVar, which maintains Next, we change the main Sequence of the pro- the value of a sensor. The web service that provides cess by inserting a Flow activity after the first Receive this value is identified by the attribute publisherEPR activity, named Start. Inside the Flow activity, we de- with the topic Temperature. fine a Sequence activity to include the original pro- cess definition and a Sequence activity for each con- Example of a variable context definition: text variable. This way, Sequence activities that re- ceive notifications run in parallel with the Sequence ... activity that has the original process definition. tion and the reception of notifications. Subscription Operation. The subscription operation In addition, the extension has to be defined in the is done with an Invoke activity. This Invoke activity process. In the following we present the extension calls the publisher EPR defined in the context vari- definition, and its namespace and prefix. able. As the subscription operation is a two-way op- eration, we define two variables: the inputVariable Example of the extension definition: and the outputVariable. Before the Invoke activity, sage according to the WS-notification standard. The context variable and the EPR to where the publisher sends notifications. The EPR is generated by concate- ... nating the process name with the name of the context variable. The output variable is initialized in the In- In the next section we describe the realization of voke response. As we initialize the Correlation in the this part of our extension. Invoke response, we declare its initialization in the re- sponse. Below we show the subscription message and the Invoke activity.

Example of subscription message (Subscribe):

508 InternetofThingsAwareWS-BPELBusinessProcess

http://192.168.1.71:8080/ode/processes/ myProcesstempVar All process instances use the same port to receive notifications. To distinguish instances, we use the Correlation. In the following we describe how we Temperature use the Correlation to guarantee that each subscriber (process instance) receives its notifications. As each context variable maps to a different sub- scription, we define a correlationSet for each context variable. We use the Correlation with two messages Invoke to perform the subscription: (SubscriptionResponse and Notify). Thus we define anyURI (any type). We use the Correlation in the In- 5.2.2 Adding WSDL Files Each context variable is related with two services: Operation to Receive Notifications. Processes re- the subscribe service and the service to where noti- ceive notifications through a Receive activity (i.e., an fications are sent (the consumer service). We define inbound message activity). This activity uses a vari- these services in an additional WSDL file, which the able to save the notifications and the Correlation. In transformed WS-BPEL process imports. This way, the following we illustrate the Receive activity. we avoid modifying the original WSDL file. We get the address of the subscribe service directly from the Operation to receive notifications: definition of the context variable, and we generate the WSDL file also includes the Correlation properties 5.3 When-then: Language Extension Finally, after the Receive activity, we add an As- We define the when-then as a top level construct. It sign activity to copy the value of the notification mes- is not an activity. As event handlers, when-then con- sage to the context variable, as we present in the fol- structs are installed in parallel with each other. This lowing. construct has a condition and an activity, which is ex- ecuted once, when the condition becomes true. In the following we present the when-then syntax and Assign operation that updates the context variable: an example. In this example, we illustrate the use of a when-then construct that executes a Sequence with two empty activities when the value of tempVar is greater than 35. The when-then syntax: wsnt:NotificationMessage/wsnt:Message

509 ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

bool-expr • the CorrelationSet, and • the Sequence activity. activity The first operation of the Sequence activity is the As- sign. We use the Assign operation to initialize the message we use to invoke the register operation in the A when-then example: auxiliary web service. This message has the condi- tion, the EPR used to receive the message notifying ... that the when condition becomes true, and the identi- fication of the process instance. $tempVar > 35 We illustrate this Assign operation in the follow- ing. Inicialization of the message used to invoke the web service that monitors the when condition: ... name="testeWhenSubscriptionCreation"> 5.4 When-then: Language Transformation We also realize this part of the extension with a lan- guage transformation approach. However, we use an http://localhost:8080/ode/processes/ auxiliary web service to detect the modification of SubscribertesteWhen variable values, avoiding busy waiting. In our im- plementation, these web services use the Listeners of $tempVar > 35 Apache ODE. In the following we detail the language transfor- -1 mation, which includes editing the WS-BPEL file and creating a WSDL file. Before that we describe the auxiliary web service. The auxiliary web service monitors the value of when $ode:pid conditions. It provides the RegisterWhen operation that this service monitors. This service uses an ODE when:InstanceId Listener to be informed when the value of a variable has been modified. In this situation, it evaluates con- ditions, and, when they become true, it sends a Un- lockWhen to the respective process instance. After the Assign operation, we add an Invoke ac- tivity to call the RegisterWhen operation and a Re- 5.4.2 Editing the WS-BPEL File ceive activity. This activity is associated with the Un- lockWhen operation, and, as it is a blocking activity, Firstly we remove the when-then construct. To ex- it will not continue until the process instance receives ecute the when-then code in parallel with the main a message notifying that the conditions has become process logic, we add a Flow activity. We point out true. Both activities use the CorrelationSet, which that the final WS-BPEL process definition only has distinguishes processes instances through their iden- an additional Flow activity with all the code added to tification (InstanceId). Finally, after the Receive, the support context variables and when-then constructs. Sequence has the original activities of the when-then For each when-then, we add: construct. • two message variables used with web service in- 5.4.3 Adding WSDL Files teractions, • the PartnerLink and its roles, The WSDL files include two web services interfaces:

510 InternetofThingsAwareWS-BPELBusinessProcess

Figure 1: The prototype and its tools.

• the auxiliary web service and to provide an extension to the Eclipse WS-BPEL • the web service that corresponds to the Receive Designer plugin, the tool we use to model processes. activity used to wait for the message notifying that the conditions has become true. The EPR of this web service is generated by concatenating the pro- ACKNOWLEDGEMENTS cess name with the name of the when-then con- struct. This work was partially supported by the FCT through In addition, it includes the messages, the PartnerLink- the PATI project (PTDC/EIAEIA/103751/2008) and Type, and the correlation rules. the LaSIGE multi annual funding.

5.5 Prototype REFERENCES We develop the prototype with the following tools: Apache Muse (2013). URL: http://ws.apache.org/muse/ • Eclipse EE + BPEL Designer plugin - modeling Page visited on February 10th, 2013. tool (Eclipse IDE, 2013; BPEL Designer Project, Apache ODE (2013). URL: http://ode.apache.org/ Page vis- 2013), ited on February 10th, 2013. • Saxon Home Edition - XLST Processor (Saxon Apache TomCat (2013). URL: http://tomcat.apache.org/ Home Edition, 2013), Page visited on February 10th, 2013. Box, D. and et al. (2004). Web services address- • Apache ODE - WS-BPEL execution en- ing (ws-addressing). IBM, W3C. URL: http:// gine(Apache ODE, 2013), and www.w3.org/Submission/ws-addressing/. • Apache Tomcat (Apache TomCat, 2013). BPEL Designer Project (2013). URL: http://www.eclipse.org/bpel/ Page visited on February Figure 1 illustrates our toolchain prototype and 10th, 2013. how it performs model transformations. Christensen, E., Curbera, F., Meredith, G., and Weer- awarana, S. (2001). Web service definition language. Microsoft, IBM. Clark, J., Deach, S., and Kay, M. (2007). Xsl transforma- 6 CONCLUSIONS AND FUTURE tions. Saxonica, Adobe. WORK Eclipse IDE (2013). Eclipse IDE for Java EE Developers. URL: http://www.eclipse.org/ Page visited on Febru- Business processes can benefit significantly from the ary 10th, 2013. IoT information. The work we present in this pa- George, A. (2008). Providing context in ws-bpel processes. per aims at simplifying the access to this informa- Technical report, Journal of the Electrochemical Soci- tion within WS-BPEL processes. Through a WS- ety. BPEL extension, processes can include context vari- George, A. A. and Ward, P. A. S. (2008). An architecture for providing context in ws-bpel processes. In Proceed- ables, whose value is updated transparently and asyn- ings of the 2008 conference of the center for advanced chronously: the extension is responsible for the op- studies on collaborative research: meeting of minds, erations required to perform the communication be- CASCON ’08, pages 22:289–22:303, New York, NY, tween process instances and sensors, allowing process USA. ACM. modelers to focus on business logic. We realize the Karastoyanova, D., Houspanossian, A., Cilia, M., Ley- extension through a language transformation mecha- mann, F., and Buchmann, A. (2005). Extending bpel for run time adaptability. In Proceedings of the nisms, allowing it to be as independent as possible Ninth IEEE International EDOC Enterprise Comput- from the process execution engine. ing Conference, EDOC ’05, pages 15–26, Washing- Future work includes maturing the prototype to ton, DC, USA. IEEE Computer Society. add more validations in the language transformation, Kopp, O., Grlach, K., Karastoyanova, D., Leymann, F., to support context variables defined inside Scopes, Reiter, M., Schumm, D., Sonntag, M., Strauch, S.,

511 ICEIS2013-15thInternationalConferenceonEnterpriseInformationSystems

Unger, T., Wieland, M., and Khalaf, R. (2011). A classification of bpel extensions. Journal of Systems Integration, 2(4):3–28. OASIS (2006). Web services notification (ws- notification) version 1.3. OASIS. URL: https:// www.oasis-open.org/committees/wsn/. OASIS (2007). Web services business process execution language version 2.0. Organization for the Advance- ment of Structured Information Standards. Ranganathan, A. and McFaddin, S. (2004). Using work- flows to coordinate web services in pervasive com- puting environments. In Proceedings of the IEEE In- ternational Conference on Web Services, ICWS ’04, pages 288–, Washington, DC, USA. IEEE Computer Society. Saxon Home Edition (2013). URL: http://saxon. sourceforge.net/ Page visited on February 10th, 2013. Wieland, M., Gorlach,¨ K., Schumm, D., and Leymann, F. (2009). Towards reference passing in web service and workflow-based applications. In Proceedings of the 13th IEEE international conference on Enterprise Distributed Object Computing, EDOC’09, pages 89– 98, Piscataway, NJ, USA. IEEE Press. Wieland, M., Kopp, O., Nicklas, D., and Leymann, F. (2007). Towards context-aware workflows. In CAISE´ 07 Proceedings of the Workshops and Doctoral Con- sortium. Citeseer. Yu, L. and Su, S. (2009). Adopting context awareness in service composition. In Proceedings of the First Asia- Pacific Symposium on Internetware, Internetware ’09, pages 11:1–11:10, New York, NY, USA. ACM. Zeng, D., Guo, S., and Cheng, Z. (2011). The web of things: A survey (invited paper). Journal of Communications, 6(6).

512