Resource Oriented Architecture in Wireless Sensor Network

1,025 views

Published on

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,025
On SlideShare
0
From Embeds
0
Number of Embeds
7
Actions
Shares
0
Downloads
0
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Resource Oriented Architecture in Wireless Sensor Network

  1. 1. Resource Oriented Architecture in Wireless Sensor Network Sun SPOT Smart Logger in the context of a supply chain SYSTEMATIC THOUGHT LEADERSHIP FOR INNOVATIVE BUSINESS Thomas Pham, Intern at SAP Research CEC Zürich (Switzerland) January 2009
  2. 2. Outline of the presentation 1. Introduction 1.1. Context of the project 1.2. Approach : DPWS vs REST 2. Integration Scenario : Video presentation 3. The system Components 3.1. Global Overview 3.2. The Enterprise Logistics Application 3.3. The Gateway Application 3.4. The Sun SPOT Application 4. The encountered difficulties 5. Future Work 6. Conclusion © SAP 2007 / Page 2
  3. 3. Introduction Internship : SAP Research CEC Zürich Diploma Work : University of Applied Sciences of Western Switzerland How to integrate and simplify the interoperability of heterogeneous and limited devices in sensors networks with existing information systems ? © SAP 2007 / Page 5
  4. 4. 1.1 Context of the project SOCRADES : (Service-Oriented Cross-layer InfRAstructure for Distributed smart Embedded deviceS)  European R&D project, 15 partners from 6 countries  SAP’s contribution is in the enterprise integration  Need to increased flexibility and agility of manufacturing processes  The challenge : coupling high-level back-end systems (e.g. ERP) with shop-floor Smart Devices Web Services based shop floor integration  Enable dynamic reconfiguration of devices  High level services compositions  Automatic workflow processing  ...  > Need to integrate all kind of heterogeneous and distributed devices with existing information systems © SAP 2007 / Page 4
  5. 5. 1.2 Approach : DPWS vs REST SOCRADES : is based on Service Oriented Architecture  Use DPWS (Device Profile for Web Services) Based on WS-* standards for providing (Big) Web  Services at the device level  But, ... for limited devices it involves : Complex XML messages (e.g. WSDL, SOAP)  Redundancy and addition of useless XML contents  Less space storage, limited bandwidth  More “calculation power”, less battery’s autonomy  Strong-coupling : fixed integration scenario  © SAP 2007 / Page 4
  6. 6. 1.2 Approach : DPWS vs REST Our Approach : a Resource Oriented Architecture  REST (Representational State Transfer) Web Services  Based on existing Web standards : HTTP + URI + Hypermedias  Resource & Representation concepts  Light , simple  uniform interfaces (GET, POST, ...)  Flexible and easily integrable  JSON (JavaScript Object Notation) as interchange format  more compact than XML  easier for human comprehension Objectives :  Prototype : REST concepts on limited devices  Design an integration scenario © SAP 2007 / Page 4
  7. 7. Integration Scenario © SAP 2007 / Page 5
  8. 8. Video presentation © SAP 2007 / Page 4
  9. 9. The System Components © SAP 2007 / Page 5
  10. 10. 3.1 Global Overview Example of network topology in which the system could be integrated : A. The Enterprise Logistics Application  – manage users and theirs deliveries track shipments and events notifications – B.  1. The gateway Application  – devices discovery & forward communications  2. The device’s Manager browse and manage software & hardware – resources  C. The embedded Application on sensors device tiny HTTP Web server – – periodic values sampling – rules monitoring system – provide event notifications © SAP 2007 / Page 4
  11. 11. 3.2 The Enterprise Logistics Application Developed JAVA with J2EE Standards   EJB 3  JPA + TopLink  WS-*  JSP + JSF SAP : JAVA is the main computer language for new  technologies. SAP Solutions compliant with J2EE standards  Glassfish Application Server :   instead of SAP Netweaver CE, because  better suited to a quick prototyping REST / WS Adapter is the notification endpoint   enable devices to send their message “RESTfuly” © SAP 2007 / Page 4
  12. 12. 3.3 The Gateway Application  The “server” : act as bi-directional proxy bridge between networks  use of RESTlet framework : provide a standalone Web server  simplify and rebuild HTTP messages  register and manage Sun SPOT connections of new discovered devices  The “client” : HTML + AJAX application developed with GWT  async XmlHttpRequest to the resources  access to device’s resources via : http://{gateway_ip:port}/{spot_name}/ ... 802.15.4 TCP / IP Wireless Connection Connection Gateway Application Server Outgoing WebServers Request/Response Forwarder Périphérique de capteurs UI Enterprise Client Enterprise Server Application WebServer UI Enterprise GatewayID Client UI Gateway Broadcaster Application Client © SAP 2007 / Page 4
  13. 13. 3.4 The Sun SPOT Application Developed in J2ME on Squawk JVM  Gateway locator,  tinyWeb Server  De/serialize HTTP resquest/response  provide resources tree (actuators/sensors/management)  HTTP methods : GET, POST, UPDATE, DELETE  CRUD signification  Resources allow parameters (application/x-www-form-urlencoded)  provide rules system for sensors values monitoring  HTTP client to push event notifications to the endpoint © SAP 2007 / Page 4
  14. 14. 4. The encountered difficulties Principally with Sun SPOT : few documentation, experimental technology  no TCP/IP implementation stack on Sun SPOT 802.15.4 network :  involves no possibility to directly address devices  soon IPv6-over-LowPan  Particularities of Sun SPOT API & strange behaviors  no device discovery protocol  negotiation to open StreamConnection (MAC + port)  Sun SPOT debugging  not possible via USB  only remotely by the air via the Sun SPOT BaseStation  but ... as it was dedicated to the Gateway Application -> problem  solution : use of another Sun SPOT acting as it. © SAP 2007 / Page 4
  15. 15. 5. Future Work  Request/response Buffer on the Gateway Limit solicitations of the limited devices to ensure :  better responsiveness – autonomy –  The JSON structure that represent embedded resources Our solution is quite personal :  because it doesn’t exist a standard JSON structure representing resources of – sensors Solution to explore :  RDF/JSON (Resources Description Framework) – open the way of Semantic Sensor Web – © SAP 2007 / Page 4
  16. 16. 6. Conclusion  Existing Web standards on any embedded devices : enable a simple interoperability of heterogeneous devices  improve the flexibility and adaptability of various device’s components  facilitate the integration with professional business applications   For me : rewarding experience  discover a lot of new technologies  Collaborations with dynamic and interesting smart people  © SAP 2007 / Page 4
  17. 17. Thanks for your attention ! © SAP 2007 / Page 5
  18. 18. Your questions ? For more informations, please to contact : dominique.guinard@sap.com mihai.vlad.trifa@sap.com thomas.pham@ithings.ch © SAP 2007 / Page 5

×