.NET Mobile Application Development

Distributed Application Design

Introduction

In previous lectures we have examined> Characteristics of mobile and distributed applications> Contemporary mobile and distributed computing technologies

In this session we give an overview of > Distributed application design > Common distributed application software architectures

Technology Limitations

Design must take account of practicalities of existing distributed technologies

> failure to do so may produce elegant but unworkable solutions

Current distributed technologies offer a compromise between networking technology and object-oriented design

Distributed components are not full partners in an OO design and should

> not be perceived as abstractions of real-world entities> be considered as service providers which aggregate operations

Remote Objects Are Not Objects

Local and remote code are used (transparently) in the same way but should be designed differently

Local objects provide> an abstraction of a real-world entity> methods/properties that abstract real-world behaviour and may be used in

conjunction with each other

Remote objects> involve network communication and delays

orders of magnitude slower than local interaction> should be designed as collection of utility functions

reduces network traffic and latencies and increases overall system performance

Example: Transferring Funds

// Server code// Server codepublic class Account {public class Account { private int _accountID;private int _accountID; private decimal _balance;private decimal _balance;

public int AccountID {public int AccountID { get {return _accountID;} set {_accountID = value;}get {return _accountID;} set {_accountID = value;} }}

public decimal Balance {public decimal Balance { get {return _balance;} set {_balance = value;}get {return _balance;} set {_balance = value;} }}

public void Update() {public void Update() { // Update account record in database }// Update account record in database }

public void Insert() {public void Insert() { // Inserts new record into database }// Inserts new record into database }

public void Delete() {public void Delete() { // Deletes record corresponding to this class }// Deletes record corresponding to this class }

public void Fill() {public void Fill() { // Gets database record which matches this class }// Gets database record which matches this class }}}

// Client code// Client codevoid TransferFunds(decimal amount) {void TransferFunds(decimal amount) { Account accA = new Account();Account accA = new Account(); Account accB = new Account;();Account accB = new Account;();

// Retreive account balances// Retreive account balances accA.AccountID = 100;accA.AccountID = 100; accA.Fill();accA.Fill(); accB.AccountID = 201;accB.AccountID = 201; accB.Fill();accB.Fill();

accA.Balance -= amount;accA.Balance -= amount; accB.Balance += amount;accB.Balance += amount;

accA.Update();accA.Update(); accB.Update();accB.Update();}}

A Service-Provider Solution

// Server codepublic class AccountUtility {

public void UpdateAccount(int accountID, decimal balance) {// Update account record in database

}

public void InsertAccount( int accountID, decimal balance) {// Inserts new account record into database

}

public void Delete(int accountID) {// Deletes corresponding database record

}

public void TransferFunds( int accountFromID, int accountToID, decimal balance) {

// Uses database transaction to modify the two accounts}

}

Remote Objects and State

Remote objects may be> Stateless – retain no information between calls> Stateful - store state information in memory between calls

Stateful objects> use memory in storing state; this works well with small number of clients

but memory load increases drastically with large number of clients> are effectively bound to a single machine, making it hard to use load

balancing for good distributed performance

Stateless objects are best design choice XML Web Services are completely stateless

> State can be maintained using session tracking but this is inefficient and not recommended

Design Guidelines for Distributed and Mobile Applications

Design components with distributed architecture in mind

> deploy them to separate computers only when required

Distributed architecture is needed> to support unmodifiable legacy apps or multi-platform 3rd party apps> if scalability issues are more important than small-scale

performance> to support interaction from a mobile device

mobile devices have resource limitations (e.g. memory capacity, processing power) and it may be necessary to shift computation / data storage to another device in the network

Design Principles

The following principles are useful in designing distributed applications

Aim to reduce communication frequency> a few ‘chunky’ interactions are better than many ‘chatty’ interactions

Follow the principle of locality> interacting objects should be close together

Remote objects should be> be stateless wherever possible and designed as service providers

Successful distributed applications> guide clients towards proper usage> restrict performance limiting options

Layered Design

Layered design is sound software engineering

> can be difficult to avoid!

3-tier designs have> Presentation layer

user interface logic typically the only role of a

mobile client> Business logic layer

business-specific rules> Data logic layer

management of back-end data store

Presentation Layer

User Interface Object

User Interface Object

Business Logic Layer

Business Rules

Data Logic Layer

Database Binary Files XML Data Store

Business Rules

Strict 3-tier design requires business rules to be placed in the middle layer

> This is not always practical; early designs used stateful objects to achieve this and performance was dreadful

Some business rules belong in the user interface> e.g. validating user input should not require interaction with remote objects

Other business rules have to be in the data logic layer> e.g. verifying referential integrity requires access to other data already in the

database

Performance gains can result from implementing business rules as stored database procedures

> For maximum performance, aim for one stored procedure which performs all required operations on a single business object

In this session we have discussed> Design principles for distributed applications

> Performance and scalability

> Layered designs

In the next session we conclude our study of mobile devices in distributed applications by considering device and application security

Summary

Reading and Resources

Reading Matthew MacDonald, Microsoft .NET Distributed Applications: Integrating XML Web

services and .NET Remoting, Microsoft Press, 2003Chapter 10, pp 329 - 358

Resources Microsoft Patterns and Practices

> Enterprise Solution Patterns using Microsoft .NET, http://msdn.microsoft.com/architecture/patterns/default.aspx?pull=/library/en-us/dnpatterns/html/Esp.asp

> Application Architecture for .NET: Designing Applications and Services, http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/distapp.asp

Yukon Basics, http://msdn.microsoft.com/msdnmag/issues/04/02/YukonBasics/default.aspx