Connecting Apps, Devices and Services

463 views
354 views

Published on

Session about influence of the new Microsoft strategy to technology shift. How we thing about services and how we will build them soon. You thin SOAP or REST. Wrong! The way might be different.

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

No Downloads
Views
Total views
463
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide

Connecting Apps, Devices and Services

  1. 1. Services for Devices Connected & Distributed Apps Damir Dobric daenet GmbH Microsoft Integration MVP, Windows Azure VTSP damir.dobric@daenet.com
  2. 2. AGENDA State of technology & Devices Service API Styles REST or SOAP or ??? Cloud, Bus, Connecting, Fir ewall & Co. Workflow Manager
  3. 3. Moore's Law o Trend for number of transistors on integrated circuit. o It doubles approximately every two years. o Strongly linked to: o processing speed, o memory capacity, o and even the number and size of pixels in digital cameras. o Impact on nearly every segment of the world economy
  4. 4. Limit of vertical scale ?
  5. 5. 256 Core Processor
  6. 6. Connected Devices?
  7. 7. Services: Where we are today? Web Services RPC-ApiStyle Resource-APIStyle Message-APIStyle
  8. 8. High-Level Architecture Interaction Consumer Service API Style
  9. 9. Request Response Client Service Interaction Book Service Design Patterns. Robert Daigneau
  10. 10. Request Acknowledge Client Service Interaction Book Service Design Patterns. Robert Daigneau
  11. 11. Remote Procedure Call (RPC) API Style var order = proxy.CreateOrder(order); Book Service Design Patterns. Robert Daigneau
  12. 12. Resource API Style sendRequest(“PUT”, http://server/myservice/orders); Book Service Design Patterns. Robert Daigneau
  13. 13. REST or SOAP ?  Two different approaches (apple or pear ?)  Compete only in very simple scenarios.  SOAP: Better for enterprises and services based on standards, policies and governance.  REST: Better (mostly) for web. Very simple and suitable for broad set of devices. SOAP (RPC) o o o o Protocol independent Support WS* Powerful Proxy tooling Protocol overhead REST (Resource) o Support for HTTP only o No support for WS* o No proxy support o No protocol overhead
  14. 14. ”Message” API Style But, there is also the Book Service Design Patterns. Robert Daigneau
  15. 15. Broker Broker
  16. 16. DEMO SERVICE BUS QUEUES
  17. 17. Why Queue? o Load Balancing (Competing Consumer) Broker • Offline Mode Broker
  18. 18. DEMO SERVICE BUS TOPICS & SUBSCRIPTIONS
  19. 19. Topics & Subscriptions
  20. 20. DEMO SERVICE BUS TOPICS & SUBSCRIPTIONS
  21. 21. How about devices & services? Participants can support different protocols: HTTP, SBMP, AMQP Message is received as pull. Public IP Service Bus Can use Relay or Queue NO VPN required!! Service This does not work if both participants are on private IP. All participants are behind firewall
  22. 22. Messaging across platforms var azure = require('azure'); Node JS WindowsAzure.Messaging.Managed.dll Windows RT WindowsAzure.ServiceBus.dll Windows (System32) Service Bus WindowsAzure.Messaging.Managed.dll Windows Phone Java Script SB REST SDK
  23. 23. Consistent Messaging Support
  24. 24. Recap
  25. 25. DAENET GmbH Damir Dobric daenet GmbH Microsoft Integration MVP, Windows Azure VTSP damir.dobric@daenet.com https://daenet.de Thank You  Blog Twitter: /ddobric http://developers.de/blogs/damir_dobric/default.aspx https://twitter.com/ddobric

×