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

Die aktuellen Entwicklungen v. a. rund um mobile Anwendungen und Devices und 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-Webkommunikation 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 und passende Clientbibliotheken für .NET und HTML5/JavaScript-Clients zum Einsatz.

Transcript

1. Christian Weyer | Thinktecture AG Für alle Leichtgewichtige web-basierte Architekturen mit ASP.NET Web API & SignalR think mobile!
2. Architectures for… • Enterprise • ISV • Web … any difference ? 2
4. Modern Business Applications Reach! 4
5. Ubiquitous access • .NET clients • Silverlight clients • Pure HTML(5) • JavaScript & jQuery • Android (Java) • iOS (Objective-C) • Embedded (C/C++) • Java 5
6. Web/HTTP APIs with ASP.NET Web API 6
7. 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“ – „on the web, not of the web“ • Web/HTTP („REST“, anyone?) – fully embrace HTTP – least common denominator technologies – less functionality (KISS?) – reach and interoperability said to be better – „easier to use“ 7
8. Which one is ‚better‘? 8
9. Which one is more ‚polite‘? 9
11. Distributed application architectures for modern applications • Reach vs. rich • Base foundation vs. features • Light-weight vs. heavy-weight 11
13. HTTP – the application protocol • Application protocol • URIs • Verbs • Headers • Content types • Content negotiation • Status codes 13
14. 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 14
15. Implementing a Web API • ASP.NET Web API technology stack • 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 15
16. Hosting & Clients • Two hosting options – ASP.NET Web Application (IIS) – Self-host server option (console application, Windows service, etc.) • HttpConfiguration is the common denominator • In v2: 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 16
17. Routing • Maps a URL space to your Web API controllers – {controller} + “Controller” • Can be tailored using default values and route constraints – Like more RPC-ish behavior • Alternative: attribute-based routing 17
18. 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 18
19. 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 19
20. 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 available at /help 20
21. Query composition • Supports OData URL query syntax • Queries enabled by simply returning IQueryable<T> from a method – e.g. for paging, filtering • Orthogonal to format and content negotiation 21
22. Push Services with ASP.NET SignalR 22
23. 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 Push Service Consumer Send data External event (Database) External event (Message queue) External event (Other actor) Notify [data] 23
24. Technical approaches for push • Periodic Polling • Long Polling – HTTP Streaming / Comet 24
25. 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 Server Client 25
26. 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? 26
27. 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 27
28. 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 28
29. 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 1. Write hub class 2. Add route in host process 3. Done 29
30. 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 30
31. 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 public void SendMessage(string message) { var msg = string.Format("{0}: {1}", Context.ConnectionId, message); Clients.All.newMessage(msg); } 31
32. 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 32
33. 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’ 33
34. jQuery without proxy file • Late binding approach • Simple steps to get going 1. Create hubConnection • Derived from $.connection 2. Get dynamic proxy 3. Wire up events based on method/event handler name via on 4. Start & invoke methods based on method name via invoke • Same connection-related event handlers • Cross-domain support same as with static proxy var connection = $.hubConnection(); var proxy = connection.createHubProxy('chat'); proxy.on('newMessage', onNewMessage); connection.start(); proxy.invoke('sendMessage', $('#message').val()); 34
35. .NET client • Client NuGet package contains binaries for all supported .NET flavors – .NET 4.x, SL5 – WP8, WinRT • Mental model resembles proxy-less JavaScript approach • Simple steps to get going 1. Create HubConnection 2. Create hub proxy via CreateHubProxy 3. Wire up event handlers via On 4. Start connection with Start 5. Call methods via Invoke var hubConnection = new HubConnection("http://localhost/services"); var chat = hubConnection.CreateHubProxy("chat"); chat.On<string>("newMessage", …); hubConnection.Start().Wait(); … 35
36. Hosting • Hosting sits on top of OWIN – IAppBuilder API • Simple steps to get going 1. Define startup class with IAppBuilder method signature 2. Map hubs onto IAppBuilder (route) • In ASP.NET: Startup class used in WebApplication.Start to spin up server – HTTP or HTTPS base URL 36
37. 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 37
38. Resources • christian.weyer@thinktecture.com • http://www.thinktecture.com • thinktecture’s GitHub Repositories – https://github.com/thinktecture • Christian Weyer’s GitHub Repositories – https://github.com/ChristianWeyer • ASP.NET Web API – http://www.asp.net/web-api • WebApiContrib – https://github.com/WebApiContrib • ASP.NET SignalR – http://www.asp.net/signalr 38