Deliverable D6.5. Grant agreement for: Collaborative Project Grant agreement no.:

Transcription

1 Universal Integration of the Internet of Things through an IPv6- based Service Oriented Architecture enabling heterogeneous components interoperability Grant agreement for: Collaborative Project Grant agreement no.: Start date of project: October 1st, 2011 (36 months duration) Deliverable D6.5 Business Process Management tools and Cloud Computing Applications Integration Report Contract Due Date 31/05/2014 Submission Date 31/05/2014 Version v1.0 Responsible Partner Author List Dissemination level Keywords RMP Sébastien Gaïde, Lou Fedon, Ian Thomas PU Internet of Things, IPv6, Cloud Computing, SaaS, PaaS, IaaS Project Coordinator: Mandat International (MI) Sébastien Ziegler

2 Table of Contents List of Figures... 3 List of Acronyms Introduction Purpose and Scope of the document Task T Structure of the document RunMyProcess platform Short History and purpose of the Platform Web services integration IaaS/PasS/SaaS - Different kinds of Cloud computing Cloud computing and IPv IoT6 Integration IoT6 architecture Making IoT visible to processes Legacy connectors CoAP connectors Making processes visible to IoT Composite API CoAP bridge Mobile phones interfaces Integration Summary and Validation Milestone MS Second year Demonstration Composite Business Ecosystems for the Web of Everything: A Vision Simplification and Externalization of Function Composition and Abstraction Resource Management Service Convergence Unified Discovery, Subscription and Monetization Insight and Analytics Conclusions and recommendations for further integration within the IoT6 platform References

3 List of Figures Figure 1: RunMyProcess Connectors... 6 Figure 2: IoT6 Architecture Figure 3: IoT6 Architecture Protocol Stack Figure 4: The Web of Everything Figure 5: RunMyProcess CoAP integration Figure 6: Temperature sensor CoAP connector configuration Figure 7: Temperature sensor CoAP connector result Figure 8: Composite API Figure 9: STIS KAIST connector configuration Figure 10: RunMyApp in the Google Play Store Figure 11: RunMyApp Example Figure 12: RunMyApp Example Figure 13: IoT6 integration Summary Figure 14: Milestone Diagram Figure 15: Milestone Main API Figure 16: Google Calendar API Composite Diagram Figure 17: Google Calendar Integration API Figure 18: Temperature Sensor API Composite Diagram Figure 19: Temperature Sensor Integration API Figure 20: Dropbox API Composite Diagram Figure 21: Dropbox Integration API Figure 22: Milestone Execution Output Figure 23: Second year review scenario Figure 24: Second year review technical overview Figure 25: Second year review Alerts Follow up Applications Figure 26: Composite Business Ecosystems for the Web of Everything Figure 27: Cloud Platforms and the Web of Things

4 List of Acronyms CoAP: Constrained Application Protocol DoW: Document of Work EC2: Amazon Elastic Compute Cloud GAE: Google App Engine GCE: Google Compute Engine HTTP: Hyper Text Transfer Protocol IaaS: Infrastructure as a Service IoT: Internet of Things JSON: Javascript object notation IPv6: Internet Protocol version 6 JSON: JavaScript Object Notation PaaS: Platform as a Service REST: REpresentational State Transfer SaaS: Software as a Service TCP: Transmission Control Protocol UDG: Universal Device Gateway UDP: User Datagram Protocol VM: Virtual Machine WSN: Wireless Sensor Network 4

5 1. Introduction 1.1. Purpose and Scope of the document The IoT6 research project aims at researching and exploiting the potential of IPv6 to develop a service oriented architecture overcoming the current Internet of Things fragmentation. The purpose of this deliverable is to document the activities and outcomes of Task T6.4: Interfacing with Mainstream Business Process Management Tools and Cloud Computing applications. It describes how a business process management tool (namely the RunMyProcess Platform) has been interfaced with the Internet of Things and how the demonstrated applications have been designed and developed. It also exposes a vision, composed of interactions between SaaS applications, the Internet of Things and legacy web services, called Composite Business Ecosystems for the Web of Everything Task T6.4 Task 6.4 is researching and exploring the integration with business processes management tools such as Maintenance Process Management (MPM) applications, with an orientation towards Cloud computing applications and a focus on Software as a Service (SaaS). This task will develop an interface with a main stream business process management tool to be used in the demonstration (the RunMyProcess Platform). It will also explore the potentiality of such an integration to interface the Internet of Things with a large number of applications, services and mobile phones interfaces. The business process management tool in order to be compatible with the IoT6 architecture must be able to do the following: Be called using the CoAP protocol Call other objects using the CoAP protocol Exchange data using the JSON format The main goal of Task T6.4 is to demonstrate that this is possible and to explore what kind of new applications can result from this integration Structure of the document The document firstly introduces the RunMyProcess platform, which will be used as a reference platform in the SaaS business process management tool. A brief description of the different kinds of Cloud computing services is given, since not all platforms are made equal, especially regarding the IPv6 point of view. This is followed by a status report on Cloud computing and IPv6, in order to obtain a global picture of the availability of IPv6 on the most used platforms. IoT6 integration in the RunMyProcess platform is then presented from the missing functionalities to a description of the demonstrations made during the project lifetime. A vision of what could be done using this integration between IoT and the Cloud computing world is then presented. Finally, the conclusions and recommendations to go further into the integration within the IoT6 world are given. 5

6 2. RunMyProcess platform 2.1. Short History and purpose of the Platform Founded in 2007 by Matthieu Hug, Eric Mahé and Alexandre Lachmann, RunMyProcess develops and operates an innovative platform specialized in business application development for the enterprise world. The Fujitsu RunMyProcess platform makes use of business process management (BPM) concepts to provide a unique mix of structured workflows; integration and agility, helping customers from all around the world meet their evolving business needs. By leveraging an easy-to-use, drag-and-drop design and more than 2,500 available connectors for SaaS and other applications as well as full integration with Google Apps, Fujitsu RunMyProcess customers can rapidly build and deploy highly customized business applications, accessible on the Web through a browser and based on a pay-per-use model. In April 2013, Fujitsu announced that it has finalized a contract with RunMyProcess to acquire all shares of the company. With this acquisition, Fujitsu added integration Platform as a Service (ipaas) to its Cloud offerings to bolster its Cloud portfolio as it expands its global Cloud business. As of today 400 customers in 44 different countries use the Fujitsu RunMyProcess platform, using its 2500 connectors to other web services to execute 5 million processes per month Web services integration Leveraging all the web services using a common interface is the objective at the origin of the RunMyProcess platform development. This is done by allowing the user to configure what is called a connector on the platform. A connector hides most of the technical details from the user. Only an endpoint address, and the types of data to send and receive are needed. The platform flattens the different kinds of data formats/structures and presents everything to the user in the same way. No matter what protocol he/she wants to use (HTTP, SOAP...) or data format (XML, JSON, CSV...) the user is presented with the same interfaces. As shown in Figure 1, this integration allows the use of all kinds of web applications: web services, legacy services, and social networking services, etc. Figure 1: RunMyProcess Connectors 6

7 Web services integrations may be regarded as one of the targets of the Task T6.4. We want to be able to involve IoT in the process execution, and to do that some parts of the IoT6 architecture will have to be integrated by adding new supported protocols to the RunMyProcess platform IaaS/PasS/SaaS - Different kinds of Cloud computing As of today, there are three main kinds of Cloud computing platforms. They are differentiated by the level of abstraction they provide. Basically, at the lowest level you will have to install an Operating System yourself, and at the highest level you will only deal with functional problems. All the technical details regarding the core of your business will be handled by the platform. IaaS IaaS, Infrastructure as a Service, represents the lowest level of Cloud computing platform. This level abstracts the hardware components of a computer service hosting. As such server, storage, network are provided as a service, i.e. like software could be provided: you start your servers, add some mass storage and plug your network connection using some tools (web console application, command line tools, web API...) accessed from you own computer. But if you do not deal with hardware issues, then it will be necessary to have some system administration skills, since once connected to the virtual server, you are in charge! You will have to install your Operating System, install all the software components needed to make your product work, and you are responsible for all the security aspect of your system. PaaS PaaS, Platform as a Service, is one level up on the abstraction scale. Generally speaking, PaaS will abstract everything up to the software components you have to write to realize your product. Therefore, the Operating System, data base manager, network configuration and most of the security aspects will be handled by the platform, or will be configurable by a non-technical person. The PaaS will enforce the use of certain technologies that may be seen as constraints, but it is necessary in order to make it easier for you to plug your own components in the platform. Therefore, it is possible that you may be forced to use a short list of languages to write your software, or to structure your data according to the storage technologies provided by the platform. SaaS SaaS, Software as a Service, platforms provides a complete solution to answer specific needs. The only knowledge needed is your core business knowledge, all the technical aspects are handled by the platform, what kind of hardware, or software technologies are in use is not necessary to know, you just concentrate on using the service to run your business. It is interesting to note that each level of abstraction may be based on the previous level: a PaaS may be designed on a IaaS, and a SaaS may be served by an application running in a PaaS or a SaaS. Of course, some services may be placed in-between two service levels. For example, the RunMyProcess platform can be placed between SaaS and PaaS: the service and all the technical details are provided by RunMyProcess (SaaS) but allow you to develop your own applications and run them on the platform (PaaS), there is a name for such a kind of platform: Business Process as a Service (BPaaS). Other specialized services can also be found, such as Storage as a Service (STaaS) (Dropbox, Box.net, Google Drive, Amazon S3...) 7

8 Some well-known IaaS, PaaS and SaaS products are: IaaS: PaaS SaaS Amazon Elastic Compute Cloud: Google Compute Engine: Microsoft Azure: Microsoft Azure: Google App Engine: Fujitsu RunMyProcess: Google Apps: Salesforce: Zoho: Note that Microsoft Azure can be regarded as both IaaS and PaaS: you can instantiate Linux or Windows VMs and manage all the technical details, or use the Microsoft technologies and development tools to deploy your application in a controlled environment with load balancing, data base storage and failure recovery provided. 8

9 3. Cloud computing and IPv6 Ideally, Cloud computing (IaaS) services should provide IPv6 connectivity out of the box, then all applications deployed on these services would be able to be involved in the IoT6 world. Unfortunately, this is not the case. As we will see, IPv6 adoption in the Cloud is currently slow, and when available, IPv6 features are always only partially supported. Let's start with the most popular IaaS service: Amazon AWS [6]. It is not possible to have natively an IPv6 address associated to an EC2 instance. It is of course, possible to access IPv6 services using some 6to4 tunneling services but the instance itself has no IPv6 address. The load balancing service of AWS is IPv6 aware [7] since May 2011, so your services can be accessed using an IPv6 address, if the Elastic Load Balancing (ELB) service is used. Another AWS service, Route 53, is IPv6 compatible and it can be leveraged to associate your public names with IPv6 addresses [8]. Amazon AWS official position regarding native IPv6 support in EC2 instances is not clear. Some official answer [9] to IPv6 related questions seems to indicate that no schedule is available. Another well-known IaaS service, Rackspace [10], is providing about the same kind of IPv6 support: Rackspace Cloud Load Balancers are IPv6 aware [11] since mid-2011 but their Cloud Servers are not. Since the 2011 s IPv6 readiness announcement, no news has been published regarding IPv6 support for Cloud servers. Our questions about IPv6 support have yielded no answer either. This is not that bad, considering that many other services do not support IPv6 at all. Among them is Google Compute Engine [12]. As officially stated, IPv6 is not yet supported [13], but Google is committed to support IPv6, only no official date is provided. At least our questions about this support have been kindly answered [14]. The situation is similar to the Microsoft Azure [15] services that do not support IPv6 natively in its IaaS incarnation. Due to this lack of complete IPv6 support, our integration developments have been deployed on privately hosted hardware, connected to the Internet via a fully IPv6 compliant Internet Service Provider. 9

10 4. IoT6 Integration 4.1. IoT6 architecture The main objective of Task T6.4 is to integrate Cloud computing into the IoT6 world. To achieve that goal, the chosen Cloud computing platform had to be adapted to be compatible with the IoT6 architecture. The global IoT6 architecture can be seen in Figure 2, part of [4]. The RunMyProcess platform is located on the left side of the schema, providing Cloud Computing (SaaS) and User Interfaces services, and the integration in IoT6 will allow communication with the right side of the diagram. Figure 2: IoT6 Architecture As any other component willing to be part of the IoT6 picture, the RunMyProcess platform had to understand the protocol stack defined in [4] and as shown below in Figure 3: Figure 3: IoT6 Architecture Protocol Stack 10

11 Some parts of this stack (HTTP, SOAP, XML and JSON) are already provided by the platform, for they are standard technologies in the legacy web. Others (CoAP, EXI) had to be added. Once this integration is done, the RunMyProcess platform will be a new component of the Web of Everything, a vision detailed in Section Making IoT visible to processes Figure 4: The Web of Everything That part of the integration work will allow process designers to leverage IoT objects in their workflows. Depending on the way these objects are accessed, it may be already possible to do it (legacy connectors) or the result of Task T6.4 is needed (CoAP connectors) Legacy connectors Making the legacy web services available is at the core of the RunMyProcess platform. All objects that are made accessible using a supported protocol are then already usable in a process. Below, are the supported protocols, and the data format (media types): HTTP/HTTPS FTP/FTPS/SFTP SMTP/SMTPS XML, JSON, CSV and other character separated values, key/value, plain text Requests made using these protocols can be authenticated using one of these methods (available depending on the protocol): Login/password HTTP Basic AWS S3 / Fujitsu SOPOS Custom HTTP Authentication header Google 2-Legged OAuth (useful to access Google Apps API) 11

12 On an IPv6 compliant hosting service, all these protocols are accessible either in IPv4 or IPv6, and IPv6 addresses formats are supported in the connector configuration. Unfortunately, these protocols are relatively hard to handle by small objects, so that new, lighter, protocols have been designed to access those objects (e.g. CoAP) CoAP connectors This is the really interesting part of the integration. CoAP connectors allow workflows to access a whole new kind of objects. To respect the IoT6 architecture, CoAP connectors must enforce the version 12 of the CoAP specifications [16]. To achieve this integration, we have decided to use the Californium [17] Java library, since it's maintained and enforces CoAP draft versioning by branching its source code. The EXI format support is based on the OpenEXI framework [18]. Figure 5: RunMyProcess CoAP integration The lower part of the Figure 5 is of interest (CoAP Connector). As shown on the right hand side of the schema (Request Processing), the CoAP integration will imply the need to translate data and protocol structure back and forth from CoAP to HTTP in order to have a CoAP connector configuration that looks like any other connector configuration, to enforce the RunMyProcess platform paradigm. So, here are the different parts of the configuration that are translated by the platform during a CoAP connector call: Content types Requests verbs (fortunately CoAP is REST based so that it has a very similar verb set as HTTP) Response codes Some media types are transformed to be easily used in a process : o EXI is translated back and forth to XML, so that RunMyProcess user deals only with human readable data o Octet streams are represented as JSON Array of bytes, so that it is easily constructed and exploited in a process When a CoAP connector is called during the lifetime of a process, the RunMyProcess 12

13 engine will start a CoAP channel manager (if not already started) that is made of a thread that will handle the UDP part of the CoAP communication. Basically, this thread is used to send the request and wait for an answer, or decide that a problem occurred during the call. This mechanism will also make the request synchronous from a process point a view, even if the CoAP call is asynchronous by nature. The process is sleeping like any other connector call, waiting passively for the connector response, so that everything is happening as if it was a legacy connector use. Below, is an example of a CoAP connector configuration and test. This connector calls a temperature sensor located in the Mandat International offices. Figure 6: Temperature sensor CoAP connector configuration When called using the CoAP protocol, the sensor will send the current temperature: Figure 7: Temperature sensor CoAP connector result The returned value (P_result=29731) is expressed as an absolute temperature value and can be converted to Celsius degrees using this formula: (29731/ )=24.16 Celsius degrees. 13

14 4.3. Making processes visible to IoT The goal of the exploration of Task T6.4 is making all the power of a Business Process Management platform accessible to any object and making it possible to call any kind of objects (HTTP, CoAP). Making the platform accessible to these objects was a requirement. Let's review what kind of addition to the platform was needed to achieve this goal Composite API Composite API is an addition made in the RunMyProcess platform as a result of the exploration work done for Task T6.4. Prior to this, the only executable components that were callable were processes. The problem with calling a process and retrieving the response is that the caller has to poll the process status, and only when the execution of the process has ended is the response available. This is due to the asynchronous nature of a process execution. This is usually not a problem for a classical web component like a web application, that can use AJAX calls easily, but it can become a real problem for small components like the one IoT6 is targeting. The need for a new executable component emerged soon into the exploration work and the notion of Composite API has been added to the RunMyProcess platform. Basically, a Composite API allows the user to have access to all the power of a process (web services integration, drag & drop workflow designer and all the power of a true development language at each step of the process execution), but with two additional advantages: The process execution is synchronous, so that the caller will receive the response within the same request that has started the Composite API; The result of the Composite API can be transmitted like any other web API in the body of the response, using some standard formats, with standard HTTP result codes and standard HTTP headers CoAP bridge If we refer to Figure 5: RunMyProcess CoAP integration, and focus on the upper part of it (CoAP Gateway), we want to enable any kind of objects to integrate with the platform: for example call an API to start a process. Of course, this is natively possible by using some HTTP(S) requests, but we want to do that, using CoAP also in order to increase the set of compliant objects. The solution that was implemented is based on Californium (again, CoAP 12 draft branch) in order to leverage the experience acquired when developing the CoAP connectors integration and uses the CoAP proxy features provided by the library. To make this integration as seamless as possible, an independent CoAP proxy module has been developed, this module will proxy any CoAP calls to the RunMyProcess platform, making all the protocol/data format transformation needed to make the calls understandable by the process engine. The CoAP proxy sits alongside the RunMyProcess application server, this non-intrusive implementation allows an easy maintenance and evolution lifecycle. Other protocols may be added to the platform in the same manner. As of today, one area of the server has been mapped from CoAP to HTTP: the Composite API subset of the RunMyProcess API. This is due to the fact that calling a process will 14

15 involve some polling mechanism, but calling a composite API will not, and this makes them more usable by the web of things. We will now look at a call to the CoAP proxy, and then at the received response: java -jar cf-client snapshot.jar POST "coap://[2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683/api/pub/ /ho st/81327/service/113779?p_mode=test" '{"id":"72ng625b39"}' :01:30 [util.log] INFO - ==[ START-UP ]======================================================== :01:30 [coap.tokenmanager] INFO - Token value: 239 ==[ CoAP REQUEST ]============================================ Address: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683 MID : -1 Type : CON Code : POST Options: 10 * Uri-Path: api (3 Bytes) * Uri-Path: pub (3 Bytes) * Uri-Path: (18 Bytes) * Uri-Path: host (4 Bytes) * Uri-Path: (5 Bytes) * Uri-Path: service (7 Bytes) * Uri-Path: (6 Bytes) * Content-Type: text/plain (0 Bytes) * Uri-Query: P_mode=TEST (11 Bytes) * Token: 14 (1 Bytes) Payload: 19 Bytes {"id":"72ng625b39"} =============================================================== :01:30 [layers.coapstack] INFO - CoapStack started :01:30 [layers.tokenlayer] INFO - Requesting response for /api/pub/ /host/81327/service/113779: :5683#EF :01:30 [layers.tokenlayer] FINE - Stored new exchange: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683#EF :01:30 [layers.matchinglayer] FINER - Storing open request: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683#EF :01:30 [layers.transactionlayer] FINEST - Stored new transaction for [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]: CON Receiving response :01:32 [layers.transactionlayer] FINEST - Cleared transaction for [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]: CON :01:32 [layers.matchinglayer] FINER - Matched open request: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683#EF :01:32 [layers.matchinglayer] FINER - Cleared open request: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683#EF :01:32 [layers.tokenlayer] FINER - Cleared exchange: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683#EF :01:32 [layers.tokenlayer] INFO - Incoming response from /api/pub/ /host/81327/service/113779: :5683#EF // RTT: 1801,662000ms ==[ CoAP RESPONSE ]============================================ Address: [2a01:e35:2e41:e820:ca2a:14ff:fe55:5d49]:5683 MID : Type : ACK Code : 2.05 Content Options: 4 * If-Match: C F 6E 2F 6A 73 6F 6E 3B D D 38 (30 Bytes) * Content-Type: application/json (1 Bytes) * Max-Age: 0 s (0 Bytes) * Token: EF (1 Bytes) Payload: 95 Bytes {"id":"72ng625b39","rfid_number":"urn:epc:id:sgtin: ","out put":"true"} 15

16 =============================================================== Time elapsed (ms): Here, the client side of the call is seen. Let's assume it comes from a connected object, supporting the CoAP protocol. The object is posting a request with some payload (an ID), and then receives the response from the Composite API. Shown below are some parts of its configuration. The Composite API space is mapped using the /api/ part of the URL, the rest of it is classical RunMyProcess API URL. On the CoAP proxy/server side, we can follow the request in and out: :12:16 [layers.tokenlayer] INFO - Incoming request: :53805#2D :12:16 [endpoint.localendpoint] INFO - Dispatching execution: /api/pub/ /host/81327/service/ :12:16 [endpoint.localendpoint] FINER - Dispatching execution: /api/pub/ /host/81327/service/ :12:16 [endpoint.resources.proxyhttpclientresource] FINER - Outgoing http request: POST EST HTTP/ :12:16 [endpoint.resources.proxyhttpclientresource] FINER - Acknowledge message sent :12:18 [endpoint.resources.proxyhttpclientresource$2] FINER - Incoming http response: HTTP/ OK :12:18 [coap.communicatorfactory$proxycommunicator] INFO - Incoming message, sending to coap stack :12:18 [layers.tokenlayer] INFO - Responding request: :53805#2D Here, the request is coming from our ISP provided modem/router ( ), and forwarded to the RunMyProcess application server, hosted on the same instance as the CoAP proxy (localhost:8080). The response is then sent back to the router, and received by the IPv6 CoAP client (==[ CoAP RESPONSE ]== part of the previous trace). Below is the design of the called Composite API, showing how the response is constructed: Figure 8: Composite API The composite API is simple, using the provided ID in the POST-ed content, it will request some information (an RFID) using another connector (HTTP-based) that sends a request to a KAIST provided service located in Korea. The following is the STIS connector configuration: 16

17 Figure 9: STIS KAIST connector configuration We have demonstrated how a connected object could leverage the CoAP integration provided by the RunMyProcess platform to use some other IPv6, legacy web services by using this simple example. 4.4 Mobile phones interfaces With the integration of the CoAP connectors and the CoAP proxy, the Business Process Management platform is now able to leverage the functionalities provided by things (by calling them) and also to help these things to realize their tasks (by being called, and by providing all the power of the web of everything). The outcome of this integration is a starting point to explore the integration of mobile phone interfaces. To ease the integration of mobile phones in workflows designed by using the RunMyProcess platform, we have developed a mobile application, with those goals in mind: Ease the access of the platform to mobile users; Make web applications interfaces look good on phones and tablets; Make mobile devices be part of the Web of Everything by leveraging its functionalities (geo-location, camera...). This application, RunMyApp, is now available on the Google Play store [19], and is scheduled to be available in the Apple App Store in Q

18 Figure 10: RunMyApp in the Google Play Store Basically, RunMyApp will help the mobile user by managing the information associated to its RunMyProcess account (credentials, or Google Apps account also used on the user s Android device) by displaying the web interfaces in a format more convenient on the device and by leveraging some HTML5 technologies (app cache, local storage) to handle network connections events (connection, disconnection) so that the requests are differed when the connection is lost, and the data is more aggressively cached. Figure 11: RunMyApp Example 18

19 Figure 12: RunMyApp Example 2 With the availability of RunMyApp, mobile devices are now enable to be part of the Web of Everything, the vision made possible by the IoT6 integration in the Cloud computing world, explained in Section Integration Summary and Validation The integration of the RunMyProcess platform has therefore, been performed from both sides using the IoT6 stack. Sensors and actuators can communicate with the RunMyProcess platform and vice-versa using CoAP as a common language. Figure 13: IoT6 integration Summary 19

20 To validate the integration, two demonstrations have been developed and presented Milestone MS21 The first demonstration has been developed to validate the milestone MS21. In the DoW, MS21 is described as such: MS21: Interaction with business process working flawlessly, successfully tested and presented to the coordinator. To do so, a demonstration that combines integration to two main SaaS applications: Dropbox and Google Apps and to a sensor were developed and tested.those three interactions have been combined in a Composite API. Figure 14: Milestone Diagram This means that this composition exposes an API, as shown in Figure 15: 20

21 Figure 15: Milestone Main API Each interaction will be now described in more details Google Calendar Integration We have created a simple interaction with Google Apps Calendar, a classic Google Apps service. A Composite API was created again to regroup a login step and the actual resource request: retrieving all the events of a calendar. Figure 16: Google Calendar API Composite Diagram 21

22 Figure 17: Google Calendar Integration API UDG Integration We have also exposed a temperature sensor through a Composite API. Our main goal was to create a new API for the temperature sensor that exposes the temperature in Celsius. This Composite API combines retrieving the temperature and converting it to Celsius degrees using the following formula Temperature C = Temperature ,15 22

23 Figure 18: Temperature Sensor API Composite Diagram Figure 19: Temperature Sensor Integration API Dropbox Integration We have also created a simple interaction with Dropbox combining in a Composite API a login step to Dropbox and a request to retrieve an account main configuration. 23

24 Figure 20: Dropbox API Composite Diagram Figure 21: Dropbox Integration API Demonstration Combining the three Composite APIs described previously, a full integration of both classical SaaS applications and objects-based applications can be executed. 24

25 Figure 22: Milestone Execution Output Second year Demonstration Another demonstration was performed during the second year review to validate the integration of the RunMyProcess platform with third-party SaaS services on the web and Mandat International s (MI) Universal Device Gateway (UDG). The scenario can be summed up as such: 1. The UDG sends an alert to the RunMyProcess platform; 2. The RunMyProcess platform sends a text message via a SaaS provider to a predefined phone number and logs the alert; 3. The end user opens an Alert Follow-up application that lists all alerts history and marks the last alert as a false alert; 4. The RunMyProcess platform notifies the UDG that the alert is false, by shutting down a revolving light. 25

26 Figure 23: Second year review scenario This scenario demonstrates: 1. The integration of the IoT world with the RunMyProcess platform through the CoAP Notify alert call; 2. The integration of the RunMyProcess platform with SaaS providers through the Send SMS request call; 3. The integration of the RunMyProcess platform with the IoT world through the Notify alert is false call. Figure 24: Second year review technical overview This Use Case also demonstrates that the IoT world can benefit from the low costs of other RunMyProcess features built in NoSQL database configuration and the Web interface design 26

27 and hosting. Figure 25: Second year review Alerts Follow up Applications 27

28 5. Composite Business Ecosystems for the Web of Everything: A Vision Allowing the Internet of Things to be part of the workflow executed on a Cloud platform and making this platform accessible to these things, has opened up opportunities for new business models. These new models will be at the origin of Composite Business Platforms, a vision that we will detail further here. Our long-term vision is to create a platform that provides all of the technical and business capabilities required to enable Composite Business Ecosystems to be implemented quickly and consistently across the entire Web of Everything (Figure 26. Composite Business Platforms). In this way, we aim to foster new kinds of business service ecosystems that enable specialization within existing industries as well as the emergence of totally new cross-industry business models. Figure 26: Composite Business Ecosystems for the Web of Everything All of the resources created or mediated through our platform can be published to a catalogue to facilitate discovery, reuse and monetization, issues that can easily prevent the emergence of composite solutions if not adequately addressed. In concert, these capabilities allow us to rapidly orchestrate existing web resources, introduce new resources into the Web via intermediation, and expose new composite APIs and business processes for further discovery, consumption, and composition. Beyond the issue of feasibility, however, we further believe that introducing composition and enhancement within the Cloud also brings a number of significant advantages above and beyond speed and ease of use (Figure 27: Cloud Platforms and the Web of Things). These benefits extend the utility of WSNs beyond simple peer-to-peer networks operating in a particular location or which are specialized for a predefined purpose and enable much more 28

29 flexible and emergent uses of individual sensors, groups of sensors acting as peers within a specialized cluster and the wider Web of Everything. Figure 27: Cloud Platforms and the Web of Things 5.1 Simplification and Externalization of Function By externalizing complex application and process logic, individual sensors, and other constrained devices can remain relatively simple and focused on their main purpose. We believe that this has the potential to vastly increase the ease of maintenance, adaptability and accessibility of applications within the Web of Everything. Rather than being forced into using complex embedded environments and strict domain models that tightly couple usage and limit flexibility amongst diverse devices, applications can be created using mainstream tools to leverage the basic functions of constrained devices in larger contexts. We believe that this in turn has the potential to encourage the emergence of new and unforeseen uses and therefore, support business model experimentation. 5.2 Composition and Abstraction The ability to easily compose resources allows us to create meta-sensors - that is higher level virtual sensors which enable consumers to address combinations of homogeneous or heterogeneous resources - across one or more WSNs - as if they were a single entity (e.g. create a single service that addresses all lights in a building or which aggregates several different data sources to provide a more holistic view of a situation). In our view, such composed meta-sensors will be a key enabler to the success of the Web of Things, as we believe it will be critical to find a strategy for simplifying and abstracting the burgeoning number of devices without losing flexibility. Composing resources in this loose manner allows us to achieve the dual benefit of abstracting complexity for consumers where necessary while maintaining the separation between each individual entity and the collection (i.e. to retain adaptability). 29

30 5.3 Resource Management We believe that without the ability to effectively manage access to constrained resources, there is a serious risk that performance degradation and/or power issues will result. In this context, we believe that Cloud platforms can be used to create composite APIs that add e.g. throttling or caching and which leverage subscription and payment capabilities to shape consumer behavior. This will allow resource owners to manage access to their resources in a way that is appropriate to their capabilities and context in order to limit the scalability issues inherent in constrained environments. Without such easy mediation, the onus would be on resource owners and consumers to individually manage their interactions across the large web of relationships with which they are involved. 5.4 Service Convergence The support of inbound CoAP calls from actors within the Web of Things will enable both intermediation between WSNs and also the presentation of any integrated SaaS or API service back into the Web of Things as if it were a sensor. This intermediation will help to reduce the barriers to integration between the virtual and physical worlds and encourage the emergence of new and unforeseen patterns of use. Together, we believe that the combination of outbound and inbound integration will enable the more rapid satisfaction of a wide range of composition, intermediation and enhancement Use Cases within a consistent and high productivity environment. 5.5 Unified Discovery, Subscription and Monetization As the number and variety of devices on the Web of Things continues to expand, so it becomes more difficult to find, subscribe to and leverage the services provided by such devices. When viewed from the perspective of the Web of Everything, however, this problem becomes a subset of the issues experienced in finding any kind of useful Web service to consume. Cloud platforms have been making good progress in simplifying the subscription and consumption of Web and Cloud based services through the use of marketplaces. Such marketplaces can be tied into a specific platform (e.g. Salesforce AppExchange, Google Apps Marketplace) or independent and focused on a niche such as APIs (e.g. Mashery, Apigee or Mashape). We believe that these kinds of marketplaces can help to make Web resources easier to find due to categorization, tagging or search capabilities and also more consistent in terms of subscription, management and monetization. It is therefore, our intention to extend the scope of our marketplace technology to encompass the scope of resources present within the Web of Things. 5.6 Insight and Analytics Monitoring and managing large networks of divergent devices is set to be a daunting task, especially when they are combined with other services as part of a larger end to end digital supply chain. To address this issue, we need to gain visibility into the status and performance of devices and other services so that we can mitigate any impacts on the overall value chain. In this context, we believe that by intermediating between services and tracking their performance, Cloud platforms could highlight potential issues based on response times or error frequencies. Over time the volume of data gathered about the nature of interactions within complex value webs could be used to make suggestions or undertake predictive analytics based on likelihood of failure. 30

31 6. Conclusions and recommendations for further integration within the IoT6 platform The purpose of this deliverable was to document the activities and outcomes of Task T6.4. After a brief explanation of the different kind of services available under the generic name of Cloud computing, the current state of IPv6 availability offered by these platforms has been presented. The conclusion is that the IPv6 adoption by these services is much slower, even if most of the service providers are committed to deliver IPv6 on all their products. This limited adoption work around is in using the service of an IPv6 compatible ISP and some proprietary hardware, to mimic a fully IPv6 Cloud computing platform. It has been described how the RunMyProcess Business Process Management tool has been interfaced with the Internet of Things by adding new functionalities to allow CoAP connectors and the development of a CoAP proxy to make the platform visible by CoAP objects. A vision made of interaction between SaaS applications, the Internet of Things and legacy web services, called Composite Business Ecosystems for the Web of Everything has been presented. During the development of the BPM/IoT6 integration some other IoT6 works have produced outcomes, new technologies, new specifications that can be used to improve our integration. Additional possibilities which we could use for example are adding some integration to leverage the Digcovery system, or demonstrating how the mobile phones integration made possible by Task T6.1 could make our Web of Everything vision more concrete. 31

32 7. References 1. Thomas, I.S., Gaïde, S., Hug, M.: Composite Business Ecosystems for the Web of Everything. In: 7th International Conference on Innovative Mobile and Internet Services in Ubiquitous Computing (2013) 2. Thomas, I.S., Gaïde, S., Fedon, L.: Making IT All Work Together. 3. Ziegler, S., Crettaz, C.: IoT6 use-case scenario and requirements definition report IoT6 D1.3 Updated version of IoT6 architecture & SOA specifications 5. CoAP IETF Core specification draft Amazon AWS: 7. AWS Load Balancers and IPv6: 8. AWS and IPv6 tutorial: 9. AWS and IPv6 official position: Rackspace: Rackspace Cloud Load Balancers and IPv6: Google Compute Engine: GCE and IPv6 official position: GCE and IPv6 discussion with RMP: Microsoft Azure: CoAP specifications: Californium framework: OpenEXI framework: Google Play store: 32