This session will present extensions to the Azure StockTrader application to run on mobile devices including Windows Phone, IPhone, and Android devices. The sample application includes a backend powered by the Windows Azure Service Bus and SQL Azure with Federations to enable data display and user interface to be optimized for these devices from a Windows Azure backend service.
Learn about the technology choices facing mobile application developers, technologies adopted for the sample and why those choices were made. The application is an end-to-end sample that includes full sample code and documentation
Presenter: Chris J.T. Auld (with his New Zealand accent?), in a Level 200 session.
Disclaimer: These are conference session notes I compiled during various sessions at Microsoft Tech Ed 2012, September 11-14, 2012. The majority of the content comprises notes taken from the presentation slides accompanied, occasionally, by my own narration. Some of the content may be free hand style. Enjoy… Rob
Follow me on Twitter @ausrob
Introduction
Session about the Stock Trader application. Started out life as a sample Java application. Featuring data tier scale out, a HTML5 UI, an Android, Windows Phone and iPhone app with a significant shared code base.
Approaches and patterns for migrating legacy app to Azure.
- Using SQL Azure federation
- Azure Service Bus
- Options for mobile front ends
- Moving to Azure is more than compatibility
- Federations allow limitless scale out
Getting into Stock Trader
- N-tier application
- Web/Middle/Data tiers
- Multiple modes of operation
- Single/Scale-out
- On premise or Azure
- Across hybrid clouds
- High performance
- Benchmarks & capacity planned
- Secure
- Data tier
On-Premise Mode [“Private Cloud”]
Internet –> Middle Tier –> Data Tier
Migration to Azure – “Life and Shift”, not a lot of code rewriting. Removed MSMQ, Database migrated to SQL Azure (not really optimised), DB is the throttle point (limited throughput, and non-deterministic, based on query throttling). Shared load determines throttling (not just your DB load!)
Objectives
- Separate Exchange and Brokerages Aspects
- Split database
- Show cloud B2B scenario
- Scale at the data tier
- Database sharding / horizontal scale out
- Deliver rich interfaces
- Mobile, all common platforms
- HTML5
- Windows 8 UI
Split to multi-database. Enabled federation and sharding. Application doesn’t need to know about the sharding strategy due to federation.. But needs some major application rewrite. Introduced some additional WCF services. Using brokered messaging via enqueing messages.
Exposed RESTful endpoint for User Interfaces. Push messages are non-deterministic, implemented a polling interface via the .Net Service Bus using topics and subscriptions. Clients poll the Service Bus.
[Demo]
Basic web experience, now moving to show the Windows 8 application. Full screen formerly-known-as-Metro application. Detailed user interface, ideal for push content. Neat integrated search functionality.
Azure Optimized vs Compatible
- Critical changes for cloud applications
- stateless application/tier
- scale out database (if using RDBMS)
- some services not supported (e.g. distributed tx, DTC managed tx, MSMQ)
- Opportunities for optimization
- Service Bus for messaging
- Service Bus for offload of polling
Using SQL Azure
Benefits
- High availability
- Full TDS + T-SQL Compatibility (though I’m sure there are limitations)
Challenges
- Limited scale up (I/O in particular)
- Query throttle is non-deterministic (shared load) – see above
- Primary replica may be bottleneck
- Be aware disconnections can occur
- Federations and sharding can happen under transactional load
- No point-in-time backup (it’s coming)
Figure out how to scale out your data tier! Implement retry pattern for connection drop-outs. ‘Always On’ in Sql Server 2012 is the same as SQL Azure’s implementation, therefore needs to be dropped connection aware.
Horizontally partitioned the SQL database. Looks a bit like partitioning, but across the data schema.
Moving to Federations
- Federation Key
- Primitives
- varchar –> varbinary (in app layer)
- Primary Keys
- identity columns not supported (and you wouldn’t want to use)
- use uniqueidentifier (a bit like replication)
- flows through to service layer (rewrite)
- use string in service layer; cast to int/guid for OnPre/Cloud
- Application Connectivity
- “USE FEDERATION”
- Must use robust retry logic
- Use this to determine which federation to use
- Code sample has a nice wrapper class for handling operations with federated shards
- Fan-Out Queries (no built-in support in Azure)
- Retrieves list of quotes
- Set filtering off and query each member sequentially (filtering limits queries to the selected federation)
- Room for optimization! (another session will explain)
- Multiple Databases
- Move to multiple databases (was not necessarily required)
- Could have defined multiple federations in a single DB
Transactions
- Can’t connect to federation within a TransactionScope
- Connection pooling has issues
- OnPrem used MSMQ, DTC – not in Azure
- No transactional support across Federations, period.
- Need to suppress transaction scope when working with the service bus (using TransactionScopeOptions.Suppress)
- Unknown if transactions will be supported across multiple federations (transaction = logical scale bottleneck)
- Different data design strategy to deal with referential integrity
- Duplicate “read only” data between federations
De-coupling BSL (Business Service Layer) using Azure Service Bus
OnPrem: BSL->MSMQ->Order Processing
Azure: BSL->[Azure Service Bus] Brokered Message Capability (Queued)->Order Processing –> Bus [as Topic] –> BSL
- Two separate contracts
- plain old WCF
- Hosting (IIS)
Brokered Messaging
- Rule based routing
- Uses ‘Topics’ and ‘Queues’
- Meta data applied to a message (drives routing rules)
- Inject username into metadata
- apply filters to the ‘sender’
Service Bus for High Volume Messaging
- Speed is everything
- Automated trading platforms
- Thousands of clients
- polling is high frequency
End goal: offload polling to Service Bus (or could be Windows Azure Mobile Services as an alternative)
- Trader creates a topic
- Sends news items to the topic
- Clients register with the registration service (subscribe)
- allows scale out of topics
- 2,000 subscriptions per topic
- Scale out topics (create multiple)
- (Topic = 2000, therefore z topics = 2000 x Z)
Cross Platform Mobile App Dev
- HTML5 (+Phone Gap)
- Doesn’t look great on all OSes
- No AppStore discovery
- X-Browser issues
- No offline on WP7
- Animations are poor
- Not all APIs are available
- It’s JavaScript….
- Mono
- UI written by hand (per platform) – good and bad
- Go native if necessary
- C#, .NET in VS.Net
- Linq, lambdas.. etc
- Access almost all platform APIs
- Native
- Target specific OSes
- multiple code bases to maintain
- Objective C….. I object!
Shared Code
- Shared files co-located (one csproj for each platform)
- Each solution has
- platform specific
- shared project
- Similar to MVVM pattern for all platforms
- Shared Models
- Shared Repository
- Maybe ViewModels could have been shared
- Can use shared interface with platform specific implementation
- e.g. AndroidResourceStringProvider: IResourceStringProvider
So that makes sense. So far so good. Build each concrete class in the platform-specific projects. Easy enough.
Summary
- Common patterns for migrating from OnPrem to Azure
- An approach to SQL Federations
- Various approaches to the Azure Service Bus
- Various options for mobile front ends
- Moving to Azure requires more compatibility
- Mono is useful for targeting cross platform
- easy to consume service bus from mobile
![Tech Ed 2008 [In Review] – Part 1](https://sanderstechnology.net/wp-content/themes/customizr/assets/front/img/thumb-standard-empty.png)
