Für alle: Leichtgewichtige Architekturen mit ASP.NET Web API & SignalR

Die Entwicklungen vor allem rund um mobile Anwendungen und Devices sowie Cloud Computing bedeuten für viele Softwareprojekte ein Umdenken, vor allem in der Architektur. Wer das heute ignoriert, könnte sich morgen in Kalamitäten befinden. Wie bekomme ich eine leichtgewichtige Integration meiner Systeme mit interoperabler Kommunikation gestemmt? Wie kann ich Daten von meinen Services mittels Real-Time-Web-Kommunikation in meine Clients hinein pushen? In diesem Vortrag wird Christian Weyer aufzeigen, wie man diesen neuen Anforderungen architekturell begegnen kann. Dabei kommen Frameworks wie ASP.NET Web API, SignalR oder das neue ASP.NET 5 zum Einsatz.

Transcript

1. Christian Weyer | Thinktecture AG Für alle Leichtgewichtige Architekturen mit ASP.NET Web API & SignalR
2. Christian Weyer • Co-founder, co-owner and principal consultant at Thinktecture AG • Focus on – Mobile & web-based application architectures – Interoperability, cross-device – Pragmatic end-to-end solutions • Microsoft MVP for ASP.NET (Architecture) ASP.NET Web API / vNext Advisory Board Member ASPInsider, AzureInsider • Google GDE for Web Technologies • christian.weyer@thinktecture.com • @christianweyer 2
3. Central question J • How to move our Windows Forms or WPF or UWP app to mobile devices and to the browser?
4. Architectures for… • Enterprise • ISV • Web • … any difference today?
   Services 4
8. Modern Business Applications Reach!
9. Ubiquitous Access • .NET clients • Silverlight clients • Pure HTML(5) • JavaScript & jQuery • Android (Java) • iOS (Objective-C) • Embedded (C/C++) • Java • Any client, any device, actually 9
11. MacOS X Windows Desktop iOS Android Windows Mobile Browser Browser Browser Windows 10 / UWP Linux
12. Web/HTTP APIs with ASP.NET Web API
13. Architectural Approaches to Service Orientation • „SOAP“ / WS-* – transport protocol independent – „secure, reliable and transacted“ (WS-*) – sophisticated and complex protocol stack – interoperability may become difficult – „the best RPC so far“ • Web/HTTP („REST“, anyone?) – fully embrace HTTP – least common denominator technologies – less functionality (KISS?) – reach and interoperability said to be better – „easier to use“ 13
14. Which one is ‚better‘? 14
15. Which one is more ‚polite‘? 15
17. Distributed Application Architectures for Modern Applications • Reach vs. rich • Base foundation vs. features • Light-weight vs. heavy-weight 17
19. HTTP – the Application Protocol • Application protocol • URIs • Verbs • Headers • Content types • Content negotiation • Status codes 19
20. Web API Framework Requirements • Need a first class HTTP programming model • Easily map resources to URIs and implement the uniform interface • Rich support for formats and HTTP content negotiation • Separate out cross cutting concerns • Lightweight, Internet scale • Realize REST-ful or RPC-ish architectures – Being pragmatic, not idealistic 20
21. Implementing a Web API • ASP.NET Web API technology stack – Based on OWIN • Derive from ApiController • Implement your actions – Actions map to HTTP methods – Prefix method name with desired HTTP method – e.g. PostComment – Use [HttpGet/Post/Put/Delete] if you prefer a different name – Supports async with Task<T> – Actions expose explicit DTO data, HttpResponseMessage or JsonValue / dynamic 21
22. Hosting & Clients • Several hosting options, e.g. – ASP.NET Web Application (IIS) – Self-host server option (console application, Windows service, etc.) • HttpConfiguration defines behavior • OWIN as base for hosting Web API, SignalR etc. • HttpClient is a cross-.NET HTTP client API • JavaScript: jQuery’s $.ajax, or $http in AngularJS 22
23. Routing • Maps a URL space to your Web API controllers – {controller} + “Controller” • Can be tailored using actions, default values and route constraints – Like more RPC-ish behavior • Alternative: attribute-based routing – Defines routes with .NET attributes 23
24. Working with HTTP • “First class experience” for using HTTP – exposing HTTP as an application protocol in its full glory and not hiding it • Use of HttpRequestMessage and HttpResponseMessage – way of giving direct access to the HTTP protocol, without parsing and encoding complexity • Use IHttpActionResult – Better testability; pre-defined action results 24
25. Model Binding & Formatters • Model binding can “shred” the request and bind it to individual parameters • Values are taken from the URL (route variables, query parameters) or from the body • MediaTypeFormatters are used to deserialize the request body based on the content type – XML, JSON, form-url-encoded supported out of the box • Request data is validated as it is bound to the parameters 25
26. Content Negotiation • Response format is determined based on HTTP content negotiation • Request Accept header expresses desired format(s) • Server selects a format for the response based on the request and the available MediaTypeFormatters • Help/documentation page optionally available at /help • Use Swagger for open documentation standard 26
27. Push Services with ASP.NET SignalR
28. Push Services Pattern • ‘Push Services’ are really not an official pattern – Observer pattern, anyone? • Model a service that – accepts incoming connections from callers – is able to push data down to callers – abstracts from communication nitty-gritty details • Realize Publish-Subscribe semantics – Based on standard web technologies with reach in mind – With maximum reach into any device, platform 28 Push Service Consumer Send data External event (Database) External event (Message queue) External event (Other actor) Notify [data]
29. Technical Approaches for Push • Periodic Polling • Long Polling – HTTP Streaming / Comet 29
30. Long Polling • Poll but don’t respond untill there’s data • Server holds on to the HTTP request until there is data to return • (Re-)Poll after data received or after the connection times out • Consumes server threads & connection resources 30 Server Client
31. Technical Approaches for Push • Periodic Polling • Long Polling – HTTP Streaming / Comet • Forever Frame • Server-Sent Events (SSE) • Web Sockets • Easy: Web Sockets are the way to go! – Only with Windows 8/Server 2012 – Network considerations – Maybe some time, but not today • Alright, let’s just write code for any technology & technique! – Erm… really? For any server and any client platform? 31
32. ASP.NET SignalR as a Solution • SignalR is – a server-side framework to write push services – a set of client libraries to make push service communication easy to use on any platform – optimized for asynchronous processing • Abstracts from the different techniques to implement pushing data – Mental model is a persistent connection – Volatile, non-durable • ‘Signal’, anyone? – Sending data to a signal. E.g. represented by a connection ID • Part of the ASP.NET brand, but not tied into ASP.NET runtime and APIs 32
33. ASP.NET SignalR Development • Extensible framework & pipeline – Based on interfaces & DI • Two programming models – Persistent connections – Hubs • Hubs offer a pre-defined application-level protocol in an RPC-ish style – Easy-to-get-going means for 80/20 situations 33
34. Hubs Concept • Hubs are classes to implement push services in SignalR – Abstraction on top of persistent connection – Convention-over-configuration • Hubs provide a higher level RPC framework – Perfect for different types of messages to send between server and client • Hub conventions – Public methods are callable from the outside – Send messages to clients by invoking client-side methods • Simple steps to get going – Write hub class – Add route in host process – Done 34
35. Programming Model • Hub name reflected into external API – [HubName] can alias name • Return simple type, complex type or Task • Complex objects and arrays of objects automatically serialized/deserialized to/from JSON – Default is JSON.NET • Context holds connection- and request-specific information – ConnectionId – Request – Headers – RequestCookies – QueryString – User 35
36. Pushing Data: Clients • Clients property as dispatching point to send messages to clients • Holds dynamic properties and methods • Target method with parameters is dynamically ‘injected’ into code path, serialized, and embedded into response 36 public void SendMessage(string message) { var msg = string.Format("{0}: {1}", Context.ConnectionId, message); Clients.All.newMessage(msg); }
37. Hub Consumers • Consumers can be classic client applications or other services/hubs • SignalR provides a variety of client libraries • Microsoft SignalR team – .NET 4.0+ – WinRT – Windows Phone 8 – Silverlight 5 – jQuery – C++ • Community – iOS native – iOS via Mono – Android via Mono 37
38. jQuery Client • HTML5-based applications often use jQuery • JSON-based wire protocol makes it easy to integrate with JavaScript • SignalR jQuery plugin offers two approaches – Proxy-based with generated proxy – Without proxy but ‘late binding’ 38
39. jQuery without Proxy File • Late binding approach • Simple steps to get going – Create hubConnection • Derived from $.connection – Get dynamic proxy – Wire up events based on method/event handler name via on – Start & invoke methods based on method name via invoke • Same connection-related event handlers • Cross-domain support same as with static proxy 39 var connection = $.hubConnection(); var proxy = connection.createHubProxy('chat'); proxy.on('newMessage', onNewMessage); connection.start(); proxy.invoke('sendMessage', $('#message').val());
40. .NET Client • Client NuGet package contains binaries for all supported .NET flavors • Mental model resembles proxy-less JavaScript approach • Simple steps to get going – Create HubConnection – Create hub proxy via CreateHubProxy – Wire up event handlers via On – Start connection with Start – Call methods via Invoke 40 var hubConnection = new HubConnection("http://localhost/services"); var chat = hubConnection.CreateHubProxy("chat"); chat.On<string>("newMessage", …); hubConnection.Start().Wait(); …
41. Hosting • Hosting sits on top of OWIN – IAppBuilder API • Simple steps to get going – Define startup class with IAppBuilder method signature – Map hubs onto IAppBuilder (route) • In ASP.NET: Startup class used in WebApplication.Start to spin up server – HTTP or HTTPS base URL 41
42. Summary • Flexible lightweight architectures – Based on the Web • Web APIs for exposing services with reach – ASP.NET Web API as lean technology stack • Push Services for implementing bi-directional communication – ASP.NET SignalR as enabling framework • Good base for a number of different application architectures – Web-based, native, Desktop, mobile 42
43. Resources • christian.weyer@thinktecture.com • http://www.thinktecture.com • Demo with Web API, SignalR and AngularJS 1 – https://github.com/ChristianWeyer/WebApiSignalRAngularDemo • ASP.NET Web API – http://www.asp.net/web-api • WebApiContrib – https://github.com/WebApiContrib • ASP.NET SignalR – http://www.asp.net/signalr 43