windows azure mobile servicesによるアプリ構築
Post on 05-Jul-2015
955 Views
Preview:
DESCRIPTION
TRANSCRIPT
Windows Azure Mobile Serviceでのアプリ開発
＠第8回まどべんよっかいち2014/3/29青木 宣明(@kumar0001)
モバイルアプリの開発
• サーバ側システムの開発
• BaaSとは
モバイルアプリ開発の対象
端末側アプ
リ
• Model
• View（ネイティブ or
Web)
サーバ・ア
プリ間通信
•伝送方式
•データ表現
サーバ側シ
ステム
•データストア
•端末側アプリ向けI/F
•認証・アクセス権
•プッシュ通知
既存のサービスを使ったアプリはここだけでよいが
新しいサービスではこれらの設計・開発
も必要に
サーバ側システム開発の事情
端末側アプリ開発以外にリソースを避けない事情
• 開発予算が限られている
• サーバ側のスキルが不足している
• 端末側アプリをリリースできるよう開発に注力したい
• 実験的なサービスのサーバ側システムを素早く構築したい
個人的な背景
TODO管理アプリで自分に適したものが見つからない
• Win8/WP8端末で同期できることが条件
無ければ自分で作ってしまおうか？
•端末間の同期を考えるとサービスを提供するサーバがほしい
•モバイル端末だけでは複雑な処理ができないので、なおさら必要
でも、サーバ側を構築する余力がない
• Webサービス、データベースの経験が浅い
•モバイル端末側のAP開発で手がいっぱい
Baas サーバ側システム開発の省力化
モバイルアプリのサーバ側システムを構築するためのサービス
• Backend As A Serviceの略
• 主要機能を手軽に実装できるサービスを提供する
BaaSを使えばとりあえずサーバ側のプロトタイプを作成して、端末側アプリに注力できるのでは？
BaaSの主な提供機能
BaaS
認証
• SNSアカウント認証を
ベースとした認証
• Twitter・Facebookなど
ストレージ
•サーバ側にデータを格納
アクセス制御
•認証結果にょるストレー
ジアクセスの制御
プッシュ通知
•サーバから端末に通知
BaaSとXaaS
ユーザ準備範囲
ベンダー提供範囲
AP
ミドルウェア
OS
ハードウェア
SaaS PaaS
AP
ミドルウェア
OS
ハードウェア
IaaS
AP
ミドルウェア
OS
ハードウェア
BaaS
AP
ミドルウェア
OS
ハードウェア
モバイルアプリのプラットフォームとしてPaaSにあたる
役割を担う
BaaSのメリット
開発スピード
•データ管理、認証を出来合いの機能で実現できる
•サーバ構築の過程が不要
サーバサイド開発の省力化
•サーバ管理のコストを十分にさけなくてもよい
•サーバ構築のコストが不要
BaaSのデメリット
カスタマイズの限界
• BaaSの提供機能が、機能拡張に不十分な場合がある
ベンダーロックイン
• ベンダーの提供機能に制約されるため、自前サーバや他BaaS
への移行が困難
セキュリティ対策
• 認証などセキュリティ機能が基本的な機能に限定される
Windows Azure Mobile Service (WAMS)とは
• 概要
• 主要機能
Windows Azure Mobile Serviceとは
Windows Azureが提供するBaaS
• バックエンドの主要機能を手軽に構築
• Azureの各機能の利用
通知ハブ、ストレージ、メール送信など
• マルチプラットフォームに対応
WP8やWin8ストアアプリだけではない
2種類のバックエンド
2種類のバックエンド処理の定義方法
• Node.js版
node.jsライブラリを使ったバックエンド処理
言語はjavascript
• .NET版
ASP.NET Web APIを使ったバックエンド処理
言語はC#もしくはVB.NET
.NET版は2014/2にプレビュー提供
主要機能
1. 認証2. ストレージ・アクセス権3. カスタムAPI4. プッシュ通知
その他• Gitでの変更管理• スケジュール実行• ロギング• スケーリング• プロジェクトテンプレート
(1)認証
外部の認証プロバイダによる認証機能
• Microsoft Account
• Windows Azure Active Directory
管理ポータル画面に必要な情報を設定するだけでよい
認証の設定画面
認証画面の追加
(2)ストレージ・アクセス権
Node.js
• 管理ポータル画面 or Visual studioでテーブルを定義
• クライアントからテーブルのCRUD用APIでアクセス
• テーブルのCRUD操作ごとのアクセス権限を設定
.NET版
• ASP.NET Web APIとしてAPIを定義⇒モバイルサービスに配備
• Web APIから任意のストレージを利用
• クライアントからWeb APIにアクセス
テーブル定義 (Node.js版)管理ポータル画面から
テーブル定義 (Node.js版)
Visual Studioから
テーブル定義 (Node.js版)
• 作成後のテーブルは基本の列だけ
• id
• __createdAt
• __updatedAt
• __version
• Insert/UpdateしたときにJSONオブジェクトに応じて動的に列を作成
テーブル定義 (Node.js版)
列の動的作成
• モバイルサービスのDynamic Schema機能をオフにすることで抑止
APIアクセス (Node.js版)
IMobileServiceTable<T>インターフェースを使ってAPIにアクセス• OData形式のRESTサービスとしてアクセスする
問い合わせ系 検索系 追加・更新 削除
Read Select Insert Delete
Lookup Skip Update
Take
ThenBy
ThenByDescending
OrderBy
Where
アクセス権
権限 意味
すべてのユーザ URLにアクセスすれば誰でもアクセス可能
アプリケーションキーを持つすべてのユーザ
APごとのキーをHTTPヘッダ(*)に指定した通信について許可される。IMobileServiceTableによるアクセスで自動的に設定される。
(*) X-ZUMO-APPLICATION
認証済みユーザのみ 認証トークンをHTTPヘッダ(*)に指定した通信について許可される。
(*) X-ZUMO-AUTH
スクリプトと管理者のみ 内部のスクリプトからのアクセス、もしくは管理者としてのアクセス(*)の場合に許可される。(*) X-ZUMO-MASTERヘッダ
アクセス権(Node.js版)管理ポータル画面から
アクセス権(Node.js版)
Visual Studioから
.NET版では
テーブル定義カスタムAPI定義
Node.js版
.NET版
.NET版ではテーブル定義とカスタムAPI定義がない
ASP.NET Web API (.NET版)
Web APIプロジェクトを作成
コントローラクラスにCRUD操作に対応したHTTP verb毎にメソッドを定義
Web API
Windows Azure Mobile Service • POST• GET• PUT / PATCH• DELETE
Controllerクラス
Web APIのデプロイ
2通りの方法
• Visual Studioから配備
• GitでプロジェクトをPush
Visual Studioから配備
Visual Studioから配備
GitでプロジェクトをPush
ソリューションのフォルダで実施git initwget http://www.gitignore.io/api/visualstudiomv visualstudio .gitignoregit add .git commit –m “comment”git remote add origin https://madoben201403-net.scm.azure-mobile.net/madoben201403-net.gitgit push origin master
Git Pushでの更新例
APIアクセス (.NET版)
IMobileServiceTable<T>インターフェースを使ってAPIにアクセス• OData形式のRESTサービスとしてアクセスするのはnode.js版と同じ
問い合わせ系 検索系 追加・更新 削除
Read Select Insert Delete
Lookup Skip Update
Take
ThenBy
ThenByDescending
OrderBy
Where
アクセス権(.NET版)
メソッドごとに変更も可能
(3)カスタムAPI
Node.js版
•サーバスクリプト：テーブル操作をカスタマイズ
•カスタムAPI：独自のAPIを定義
•どちらもjavascriptで記述
.NET版
• Web APIを作成するため、処理内容は自由
サーバスクリプト (Node.js版)
CRUD操作に対応したスクリプト
• 各APIをカスタマイズして、各操作の処理内容を変更できる
データ検証など
API
Windows Azure Mobile Service • Insert• Read• Update• Delete
例• 端末からのデータの検証• 独自のアクセス制限
カスタムAPI (Node.js版)
新しくAPIを定義できる• テーブル操作に基づかないデータ操作• 複合的な処理をサーバ側で実装して、端末側APで複雑な処理を行わない
CRUD操作に対応したHTTP verb毎にスクリプトを定義
API
Windows Azure Mobile Service • POST• GET• PUT / PATCH• DELETE
端末側からはInvokeAPIAsyncメソッドで呼び出す
複数テーブルへの問い合わせ
IMobileServiceTable<T>インターフェースにはjoin系のメソッドがない
• 複数の表を結合する操作はサーバ側で実装して、カスタムAPIを通して端末側から利用させる
API
Windows Azure Mobile Service
• POST• GET• PUT / PATCH• DELETE
端末側はサーバ側の処理結果を利用するだけに留めるテーブルのJOINは
サーバ側で実施
(4)プッシュ通知
通知方法は2種類• 従来のプッシュ通知サービス(WNS/MPNSなど)を使う
Windows Push Notification Service (Win8) Microsoft Push Notification Service (WP8) Apple Push Notification Service (iOS)＋その他
• Windows AzureのNotification Hubを使う
API
Windows Azure Mobile Service
PNS ⑤プッシュ通知
①通知サービスのチャネル確立
④プッシュ通知を要求
②チャネルを通知
③通知イベント発生
従来のプッシュ通知のデメリット
WNS/MPNSを使う場合、APIからPNSへのプッシュ通知要求はプッシュ通知のプラットフォーム毎に行う必要がある
プッシュ通知のプラットフォームが増えるとAPI側のロジックを修正する必要がある
API
Windows Azure Mobile Service
⑤プッシュ通知
①通知サービスのチャネル確立
④プッシュ通知を要求
②チャネルを通知
③通知イベント発生
WNS⑤プッシュ通知
①通知サービスのチャネル確立
②チャネルを通知MPNS
Notification Hubのメリット
Notification Hubを使うと、APIからはHubに１回要求すればよい。
各プッシュ通知プラットフォームへの通知要求はNotification Hubが行う。• スケーリングにもハブ側で対応できる。
API
Windows Azure Mobile Service
⑥プッシュ通知
①通知サービスのチャネル確立
④プッシュ通知を要求
②チャネルを通知
③通知イベント発生
WNS⑥プッシュ通知
①通知サービスのチャネル確立
②チャネルを通知MPNS通知ハブ
⑤プッシュ通知を要求
WAMSのメリット
•管理ポータル画面からサービス側を定義するだけで構築可能
•プロジェクトテンプレートから端末側APのプロトタイプを作成可能開発スピード
•Azureでサーバ管理の面倒を見てくれる
•Node.jsもしくはWeb APIで開発できるので、参考情報が多い
•スケーリングにも対応しやすい
サーバサイド開発の省力化
•.NETバックエンドであればデプロイし直せば済むはず
•Node.jsバックエンドのデータベースはSQL Serverなので、データ移
行も容易
自前サーバへの移行が容易
まとめ
サーバ側システム(バックエンド)の開発を省力化するBaaS
• バックエンドを短期間で立ち上げられる
•限られた開発リソースを端末側のアプリ開発により多く充てられる
WAMSでAzureを活用したバックエンドの構築
• Azureのサービス、スケーラビリティを利用できる
•バックエンドはNode.js/ASP.NET Web APIで開発できるので、既存の
ノウハウを応用できる
WAMSその他機能
• プロジェクトテンプレート
• 料金
プロジェクトテンプレート
Node.js .NET
Windows Phone 8 ○ ○
Windows 8.x ストアアプリ ○ ○
iOS ○ ○
Android ○ ー
Web AP(HTML/JavaScript) ○ ー
Xamarin ○ ー
PhoneGap ○ ー
料金体系
最初の12か月間のみ1ジョブ1時間あたり1回
10ジョブ50,000回
10ジョブ500,000回
Mobile Service
料金体系
通知ハブ
top related