Contenu connexe Similaire à DSL駆動によるクラウド・アプリケーション開発 Similaire à DSL駆動によるクラウド・アプリケーション開発 (20) Plus de Tomoharu ASAMI (20) DSL駆動によるクラウド・アプリケーション開発2. 浅海のプロフィール
¡ 1985年-2001年:富士通
l UNIX OSをビジネス向けに改造する仕事
¡ ファイル管理、分散ファイルシステム、Webサーバなど
¡ 信頼性、運用管理、COBOL向けの改造
l 1993年頃からオブジェクト・モデリングの調査を始める
l 1995年からJavaの利用を始める
l 1998年からJava&XMLのフリーソフトを開発・公開(個人活動)
¡ SmartDoc(XML文書処理系)、Relaxer(プログラム自動生成)
¡ 2001年-現在:浅海智晴事務所代表
l モデリング、XML、Javaのコンサルティング、教育活動
¡ 2002、2003年度:IPA未踏に採用
l Relaxer (DSLによるプログラムの自動生成)
¡ 2005年度-2007年度:稚内北星学園大学東京サテライト校教授
¡ 2007年度-現在:日本Javaユーザグループ副会長
¡ 2009年2月-現在:edge2.cc主宰
¡ 2009年5月-現在:匠Labフェロー
3. 開発プログラム
¡ SmartDoc (1998年)[Java]
l XML文書処理系
l 専用XML文書からHTML、LaTeX、プレインテキストを生成
¡ Relaxer (2000年)[Java]
l XMLスキーマ言語RELAXをDSLとして用いたスキーマ・コンパイラ
l RELAXからJavaプログラム、W3C XML Schemaなどを生成
¡ SmartCase (2004年、試作)[Java]
l 専用XML文書でユースケース・モデルを記述
l 仕様書を生成
¡ JavaDSL (2007年、試作)[Java]
l JavaをDSLのメタ言語としてオブジェクト・モデルを記述
l Javaプログラムと仕様書を生成
¡ SimpleModler (2008年∼)[Scala]
l ScalaをDSLのメタ言語としてオブジェクト・モデルを記述
l Javaプログラムと仕様書を生成
5. 戦略には価値がなく、戦略と実現の融合に価値
が生まれる
戦略
オペレーション
ビジネス
ビジネス戦略 オペレーション
表(価値)
What How 裏(実現)
What 表(価値)
裏(実現)
How
表(価値)
What How 裏(実現)
システム要求
システム設計
参考: 日経 Itpro 萩本・匠style研究所 「論理的美の虚像」
第7回 http://itpro.nikkeibp.co.jp/article/COLUMN/20090619/332251/
第8回 http://itpro.nikkeibp.co.jp/article/COLUMN/20090717/334022/
第9回 http://itpro.nikkeibp.co.jp/article/COLUMN/20090825/335978/
8. 関連雑誌記事
¡ 『Cloud Modeling:クラウド時代のモデリング技
術』
l UNIXマガジン 2009年春号
¡ 『マルチパラダイム言語Scala』
l ITアーキテクト誌 Vol.24 (7月25日発売)
¡ 『クラウド時代のWebアプリ開発作法』
l ITアーキテクト誌 Vol.25 (9月25日発売)
¡ 『実証研究プロジェクト「edge2.cc」の挑戦 : アプ
リ開発者の目線で探るクラウドの可能性と実装手
段』
l DBマガジン誌 11月号(9月25日発売)
11. クラウドとは
クラウド
システム・プラットフォーム
仮想化
としてのクラウド
ホスティング
Amazon EC2 統合プラットフォーム
としてのクラウド
PaaS
Googlle
ソフトウェア・プラットフォーム App Engine
Web
としてのクラウド
SaaS
Amazon A2S
SaaS: Software as a Service
PaaS: Platform as a Service
13. マーケットの変化
勘定系システム
基幹系システム
Web
情報系システム
クラウド
集合知 勘定系システム
情報系システム
モバイル・デバイス 基幹系システム
14. クラウド・コンピューティングの意義
¡ 「チープ革命」(Web 2.0)の実現
l ソフトウェア開発・運用のコスト構造が激変
¡ クラウド時代にはさらに…
l DSL駆動開発
¡ プログラムの自動生成
l オフショア開発
¡ 単純開発は国内に残らない
l CBD (Component-Based Development)
¡ Webプラットフォーム上でのサービス・コンポーネントの
再利用
¡ マッシュアップ
15. クラウド時代のソフトウェア開発
業務
業務
アーキテクチャ
方式 開発
クラウドに飲み込まれてしまう!
製造 コンポーネント開発
プラットフォームの共用
コンポーネント・サービスの再利用
オフショア開発
プログラム自動生成
システム保守・運用 システム保守・運用
ハードウェア保守・運用 ハードウェア保守・運用
16. DSL駆動開発&コンポーネント
分析 設計 実装
DSL 自動生成 コンポーネント
OO分析
OO設計 OO実装 コンポーネント
DSL 自動生成 コンポーネント
DSL 自動生成 コンポーネント
OO分析
OO設計 OO実装 コンポーネント
18. SimpleModelingの方針
¡ 教育向け、小規模開発向けのモデリング手法
l できるだけ小さく vs. 簡略化しすぎない
l 具体的なプロファイル
¡ 教科書『上流工程UMLモデリング』
¡ モデグラミング
l モデル駆動開発が可能なモデル体系
l テキストDSLで表現可能なモデル体系
¡ アジャイル開発
l モデグラミングによってモデリングをアジャイル開発に注入
¡ クラウド向けにチューニング
l 問題空間重視
¡ What > How
l コラボレーション重視
¡ 分散環境、ユースケース技術、状態機械
l CBD (Component-Based Development)
l WOA (Web-Oriented Architecture)
l クラウド・データベースとRDBMS
19. SimpleModeling技術
¡ SimpleModeling
l 企業アプリケーション向けモデリング手法
l 業務モデリング、ドメイン・モデリング、要求モデ
リング、システム・モデリング
¡ MindmapModeling
l SimpleModelingのモデル抽出手法
l ドメイン・モデリング(+業務モデリング)
¡ SimpleModeler
l SimpleModeling用モデル・コンパイラ
21. オブジェクト・モデルの構成
状態機械モデル
ステートマシーン図
ユースケースを現実化したものがコミュニケーショ
ン図/シーケンス図、 コミュニケーション図/シーケン
オブジェクト図/クラス
ス図を利用者の視点によるシステムの利用事例と
図、 コミュニケーション
して抽象化したものがユースケース
図/シーケンス図に登
場するオブジェクトの
状態遷移を記述
ユースケース図 コミュニケーション図 オブジェクト図
ユースケース
(利用事例)
クラス図をインスタンス
化(実体化)したものが
オブジェクト図
コミュニケーション図を時間
軸の側面から記述したもの シーケンス図 クラス図
オブジェクト図上でコラ
がシーケンス図
ボレーション(メッセー
ジの送受信の集まり)
を記述したものがコミュ
ニケーション図
協調モデル 静的構造モデル
23. ドメイン・モデルをハブとした連携
要求モデル
拡張
業務モデル システム・モデル
抽出
問題空間 追加
解決空間
プラットフォーム独立
解決空間
プラットフォーム固有 追加 設計モデル
ドメイン・モデル
24. モデル変換の流れ
業務モデリング 要求モデリング システム・モデリング 設計 実装
アプリケーション・モデル
システム
業務モデル 抽出 要求モデル 変換 具体化 設計モデル 実現 実装
モデル
調整
調整
参照
抽出
拡張
解決空間 解決空間
問題空間 プラットフォーム プラットフォーム 実現 実装
非依存 固有
ドメイン・モデル
25. モデル変換/アーキテクチャの側面から
業務モデル ドメイン・モデル 要求モデル システム・モデル 設計モデル 実装
静的構造 エンティティ ドメイン層 ドメイン層
抽出
具体化 格納
現実世界
データベース
ドメイン・モデル
抽出
コントロール アプリケーション層 アプリケーション層
ボキャブラリ 詳細化 実現
動的モデル
具体化
文脈
ユースケース
具体化
利用事例 バウンダリ プレゼンテーション層 プレゼンテーション層
操作
やりたいこと
エンド・ユーザ
アプリケーション・モデル
26. UMLの長所と短所
¡ 長所
l 唯一の標準オブジェクト・モデル記法である。
l メタ・モデルが厳密に定義されている。
l グラフィカル言語であり、概要情報の伝達にすぐれている。
¡ 短所
l オブジェクト・モデル以外の記述には必ずしも適していな
い。
l オブジェクト・モデルも完全に記述できるわけではない。
l 作成効率が必ずしも高くない。
l モデル・リポジトリの操作性がよくない。
l 大規模開発に必ずしも適していない。
l 自然言語情報の取り扱いが不十分。
27. Modegramming (モデグラミング)
¡ Modeling + Programming
l モデリングとプログラミングの融合
¡ テキストDSL+モデルコンパイラによるモデル駆動開
発
l DSL (Domain Specific Language)
¡ Scala DSL
¡ Mindmap DSL (MindmapModeling)
¡ Excel DSL, XML DSL, JRuby DSLなど必要に応じて
l メタ・モデル(モデル体系)
¡ SimpleModeling
l モデルコンパイラ
¡ SimpleModeler
30. Scalaについて
¡ 純粋オブジェクト指向言語+本格関数型言語
l 関数型言語とクラウドは相性がよいはず
¡ 静的型付
¡ Java VM上で動作
¡ 言語仕様が複雑
l その代わり浅海の体感ではJavaの3倍ぐらいの生産性
がある
¡ DSLのホスト言語として充実した機能を持っている
¡ モデル・コンパイラの実装言語として充実した機能
を持っている
31. SimpleModelerの動作
Web仕様書
project クラス図
html
ステート
CSV import マシーン図
java
SimpleModelリポジトリ
(Maven project) Javaプログラム
convert
grails
Scala DSL
Grailsプログラム
import
gae
Mindmap
(Xmind)
Google App Engine/Python
プログラム
gaej
verify testset
import
Google App Engine/Java
gaeo プログラム
Excel
検証結果 テストセット Google App Engine Oil
プログラム
企画中
32. SimpleModeler
CSVで記述できること
yorozu.csv
#actor,base,parts,attrs,powers,states,roles
顧客,,,住所
個人顧客,顧客,,,性別(男性;女性)
法人顧客,顧客
従業員,,,,,,店員
#role
店員
#resource
商品,,製品+,,,商品状態(入荷待;在庫中;配送中;販売完)
製品
#event
顧客取引,,顧客;店員
顧客購入,顧客取引,商品+
34. SimpleModeler
Scala DSL
package com.yorozu
import org.simplemodeling.dsl._
import org.simplemodeling.dsl.datatype._
import org.simplemodeling.dsl.domain._
import org.simplemodeling.dsl.domain.values._
case class DER製品 extends DomainResource {
term = "製品"
caption = "製品"
brief = <t></t>
description = <text></text>
id("製品Id", DVI製品Id())
attribute("製品Name", DVN製品Name())
}
case class DVI製品Id extends DomainValueId {
term = "製品Id"
caption = "製品Id"
brief = <t></t>
description = <text></text>
attribute("value", XString)
}
case class DVN製品Name extends DomainValueName {
term = "製品Name"
caption = "製品Name"
brief = <t></t>
description = <text></text>
attribute("value", XString)
}
37. SimpleModeler
Scala DSL→ステートマシーン図
package com.yorozu
case class DMS入荷待 extends DomainState {
import org.simplemodeling.dsl._ term = "入荷待"
import org.simplemodeling.dsl.datatype._ caption = "入荷待"
import org.simplemodeling.dsl.domain._ brief = <t></t>
import org.simplemodeling.dsl.domain.values._ description = <text></text>
case class DER商品 extends DomainResource { transition(DEE商品入荷(), DMS在庫中())
term = "商品" }
caption = "商品"
brief = <t></t> case class DMS在庫中 extends DomainState {
description = <text></text> term = "在庫中"
caption = "在庫中"
id("商品Id", DVI商品Id()) brief = <t></t>
attribute("商品Name", DVN商品Name()) description = <text></text>
association("製品", DER製品(), OneMore)
statemachine(DM商品状態()) transition(DEE顧客購入(), DMS配送中())
} transition(DEE顧客購入(), DMS販売完())
}
・・・中略・・・
case class DM商品状態 extends DomainStateMachine { case class DMS配送中 extends DomainState {
term = "商品状態" term = "配送中"
caption = "商品状態" caption = "配送中"
brief = <t></t> brief = <t></t>
description = <text></text> description = <text></text>
state(DMS入荷待()) transition(DEE商品配送(), DMS販売完())
state(DMS在庫中()) }
state(DMS配送中())
state(DMS販売完()) case class DMS販売完 extends DomainState {
} term = "販売完"
caption = "販売完"
brief = <t></t>
description = <text></text>
}
41. Google App Engine/Java
アプリケーション構成
document
HTML Form
JSP DDCustomer
index.jsp
Servlet
Dojoウィジェット
index.jsp
index.jsp DEACustomerController DSYorozuDomainService
index.jsp
entity
DEACustomer
JDO
index.html
GWTCustomerEdit GwtYorozuDomainService
or
GWT-RPC
DataStore
GwtCustomer
43. edge2.cc
¡ Edge to Cloud Computing
¡ http://www.edge2.cc
¡ モデル駆動開発×クラウドコンピューティングの実
証プロジェクト
¡ アプリケーション開発者の立場から、クラウド・アプ
リケーションの開発技法を確立する
l 要素技術、アーキテクチャ、モデリング、モデル駆動開発
l モデル駆動開発の技術として
SimpleModeling&SimpleModelerを採用
44. TwitterRecommender
¡ Twitterを使用した集合知アプリケーション
l Twitterから収集したフレンド、フォロワーのリンクから
ソーシャルグラフを生成して、フォロワーの推奨を行う
l 収集した情報をPC, iPhone, Androidで表示
¡ 目的
l Google App Engine/Python, Javaの味見
l 集合知アプリケーションの味見
l SimpleModelerの活用(DSL駆動開発)
l モバイル技術
¡ Google Developer Day Japan 2009の
Sandboxに出展
45. TwitterRecommender
iPhone
iTwitter
Recommender
XML Sync+
Offline
Google App Engine Java
Twitter XML iPhone
Google App Engine Python
Safari
TwitterRecommender HTML5 HTML5
Engine AtomPubサービス Tiwtter Recommender Offline
JSON on SmertWeb
Android
SmertWeb Framework
自動生成
Chrome
データストア Gears on Gears
アクセス処理 HTML4 Offline
SimpleModeler
JDO PC (JavaSE)
TwitterRecommender
Servlet
AtomPub Twitter Popper
モデル データストア
PC
HTML4 Webブラウザ
46. edgeSNS
¡ 簡易版SNS
l SNS日記機能の実現
l クラウド・アプリケーションの構築技術を追求するのを目
的に、アプリケーションは平凡なものを選択
¡ 目的
l メッセージングの活用
l 非同期入出力の活用
l メッセージング、非同期入出力の実現に対する
SimpleModelerの活用
l メッセージングを基盤にしたコンポーネント・ベース開発
47. edgeSNS
クライアントとサーバ間の通信にはREST
を用いる。
Web UIはHTML5を用いて、 クライアント・
サーバ型のGUIとして構築する。
I/Oエラーなどのエラー発生時はエラーの Bad Message
発生したメッセージをメッセージ・キュー
「 Bad Message」 に送信する。
Web UI
REST 日記の書き込み
(HTML5)
日記の書き込み KVS
日記形式の正規化
Twitterメッセージの 日記形式
Twitter REST
取り込み
Publish/Subscribe
Twitter形式
Peer-to-Peer
フレンド日記一覧の更新 KVS
Blog形式
Blog REST Blogの取り込み
SNS日記形式
通知メールの送信
メール
SNS REST SNS日記の取り込み
Context Based Routerの手法で、 メッセ
ージ形式ごとにデータ変換を行う。
個々 のメッセージ変換機はコンポーネン
トなので、 容易に機能追加が可能。 コンポーネントを追加することで、 機
能拡張を容易に行うことができる
外部データの取り込みもコンポーネント
化されて、 容易に機能拡張が可能。
49. クラウド時代のモデリング
¡ CIM (Computer Independent Model)
l 概念モデル
l 変化なし
¡ PIM (Platform Independent Model)
l 論理モデル
l 少し変化:非同期、並列、分散への対応
¡ PSM (Platform Specific Model)
l 物理モデル
l 大きく変化:クラウド・プラットフォーム
50. アプリケーション統合の障壁
¡ Networks are unreliable.
¡ Networks are slow.
¡ Any two applications are different.
¡ Change is inevitable.
『Enterprise Integration Patterns』より
51. クラウド・アプリケーションの作法
¡ エラーの発生を前提とする。
l Networks is are unreliable.
¡ 入出力は非同期処理を前提とする。
l Networks are slow.
¡ Webプラットフォームを前提とする。
l Any two applications are different.
¡ アジャイル開発を前提とする。
l Chenge is inevitable.
52. クラウド・アプリケーション
¡ Webアプリケーション
l MVC2からMVCへ
l クライアント/サーバ時代のGUIをWebで実現
l HTML5
¡ スケーラビリティ
l 非同期処理、並行処理、分散処理
l ACIDからBASEへ
¡ Key/Valueストレージ
¡ 分散アプリケーション
l 故障と遅延への対応
l 逐次処理から並行処理へ
53. クラウド・アプリケーションの三つの技術
¡ UI
l Web GUI
l クライアント/サーバ時代のGUIをWebで
l HTML5
¡ データベース
l KVS (Key/Valueストレージ)
¡ 通信方式
l メッセージング
l メッセージ・キューを用いた非同期通信
54. スケールアップとスケールアウト
プレゼンテーション アプリケーション データベース
汎用機 スケールアップ
(1段モデル)
サーバー
スケールアウト スケールアップ
クライアント・サーバー クライアント サーバー
(2段モデル)
スケールアウト スケールアップ
クライアント サーバー
Web スケールアウト スケールアップ
(3段モデル)
クライアント サーバー
スケール
クラウド スケールアウト
アップ
(分散モデル?)
クライアント サーバー
55. 負荷分散
クライアント
クライアント Webサーバ
アプリケーション
クライアント Webサーバ
サーバ
アプリケーション データベース
クライアント Webサーバ
サーバ サーバ
アプリケーション
クライアント Webサーバ
サーバ
クライアント Webサーバ
クライアント
クライアント
56. 非同期処理
基本処理1
基本処理2 非同期処理A
基本処理3
基本処理4 非同期処理B
基本処理5
57. 分散処理
部分問題A
部分問題B
問題 部分問題C 解
部分問題D
部分問題E
58. イベント駆動処理
外部事象A
イベント処理A
外部事象B
イベント処理B リソース 常駐処理
イベント処理C
外部事象C
59. クラウド・アプリケーションのアーキテク
チャ
サーバ側では、 GUIが使用する
サービスを提供する。
クライアントはWebブラウザ上で
動作するHTML5で本格的なGUI
プレゼンテーション層
を構築する。
クラウド・アプリケーション
クライアント側 サーバ側 アプリケーションの論理的な構成は
従来のものと変わらない
プレゼンテーション層
HTML5 サービス
ビジネス層
ドメイン層
プレゼンテーション層はWeb指 統合層 アクセス方式1: RDBMS
向のMVC2ではなく、 クライアント ACID特性を要求されるデータはRDBMSに
アクセス方式4: 手続き呼出し
/サーバ時代のGUIに回帰する。 格納する。
性能特性、 障害特性がローカル
の手続き呼び出しよりも脆弱。
アクセス方式5: メッセージング 統合層
分散環境での連携に適応する特性をもつ。 RDBMS
メッセージ・キュー
アクセス方式2: KVS
KVS 一般のデータはKVSに格納するのが望ましい。
サービス REST
サービス
アクセス方式3:REST
Webページを手繰って情報を取得する サービス
60. クラウド・アプリケーションのアーキテク
チャ例
マスターデータなど更新頻度が低いデータは
KVSで配布して直接参照する。
結果を直接知りたい場合には、 手続き呼
KVS び出しで同期型の連携を行う。
この形式の連携を行うとスケーラビリティが
低くなる。
プレゼンテーションの段階でできることをや
っておくと、 スケールアウトの効果によって クラウド・アプリケーション
スケーラビリティが高まる。
外部サービスからRESTを用いて情報を取
得するのが典型的な利用方法。 サービス利用の主力はメッセージである。
プレゼンテーション サービス サービス
この形式の連携を行うとスケールアウトに
よってスケーラビリティを確保できる。
サービス バックエンドのサービス群もメッセージによ
メッセージ・キュー
REST って連携。
サービス メッセージ・キュー
同期通信
サービス
メッセージ送信
メッセージ配信
KVS RDBMS
データベースをアクセスするスコープは
サービスに閉じておくのがよい。
KVSとRDBMSを適材適所で使い分ける。
可能であればKVSを使うのが望ましい。
61. クラウド・アプリケーションへの移行パス
第一段階 第二段階 第三段階
導入 過渡期 本格適用
HTML5 HTML5 HTML5
UI
RDBMS KVS KVS
KVS RDBMS RDBMS
データベース
負荷分散 負荷分散
負荷分散
(非同期)
非同期
スケーラビリティ 分散処理
イベント駆動
サービス利用 REST REST REST
AtomPub AtomPub
メッセージング メッセージング
インテグレーション・
フレームワーク フレームワーク
62. クラウド・アプリケーションの設計技法
¡ 概念モデル(要求モデル)は今までどおり
l ドメイン・モデル
l ユースケース・モデル
¡ 論理モデル(PIM, Platform Independent Model)
l 非同期、並列、分散を本格的に取り込む
l メッセージングによる分散コンポーネントの非同期通信
¡ 物理モデル(PSM, Platform Specific Model)
l データ・モデルのKVS化
¡ 非正規化(データ集約)、データ分割
l Web技術に対応
¡ HTML5, AtomPub
l 分散技術に対応
¡ メッセージング
l メッセージングを軸とした統合フレームワークの導入
63. PIM/PSM/実装
CIM : Computer Independent Model
DSL PIM : Platform Independent Model
CIM
PIM PSM : Platform Specific Model
DSL: Domain Specific Language
DSL
PSM
非機能要求 実装 プラットフォーム
(Java、 XML、 )
64. SimpleModelerによるDSL駆動アプローチ
¡ ドメイン・モデル(概念モデル、論理モデル)からクラ
ウド向けの物理モデルの自動生成
l クラウド・アプリケーション開発で難易度が高く、煩雑なプ
ログラムを自動生成
¡ ユースケース・モデル
l ドメイン・モデルの正当性を検証
l サービス・モデルを抽出
¡ サービス・モデル
l RESTやAtomPubなどのサービスのAPIとエントリポイン
トを自動生成
¡ edgeSNSの開発を通じて実用化していく
66. 付録
¡ Google
App Engine JavaのDataStore
のモデリングに関するメモ(SDK 1.2.4レベ
ル)
67. データストアの考慮点(1)
¡ JOINが使えない
¡ 集約関数が使えない
l SUM, AVR, MAX, MIN, COUNT
¡ クラス名に日本語が使えないみたい。
¡ 更新処理が遅い
¡ 利用できるデータ型に制約がある。
l java.lang.String
l com.google.appengine.api.datastore.ShortBlob
l boolean, java.lang.Boolean
l short, java.lang.Short, int, java.lang.Integer, long, java.lang.Long
l float, java.lang.Float, double, java.lang.Double
l java.util.Date
l com.google.appengine.api.users.User
l com.google.appengine.api.datastore.Text
l com.google.appengine.api.datastore.Blob
l com.google.appengine.api.datastore.Key
l com.google.appengine.api.datastore.Link
68. データストアの考慮点(2)
¡ アプリケーション・データ以外のデータの格納
l メタデータの格納
l 作成日付、更新日付
l 検索用の計算済みデータ
¡ メタ・エンティティ
l シーケンス番号の採番
l 総件数、最大値、最小値
¡ 日付のロケール
l UTC(GMT)にすると日本時間とずれる
¡ Serializableオブジェクトの格納
l Pythonなどとの相互運用は?
l バージョン間の相互運用は?
l 回避する場合には、アプリケーションでMarshallingしなければならない
¡ Listプロパティ
l Serializeして格納?
l Pythonなどとの相互運用は?
l バージョン間の相互運用は多分大丈夫
¡ 基本データ型をそのまま使うと、カラムがnullの場合NullPointerExceptionになる
¡ List型のカラムにデータがない場合には、要素数0のListではなく、nullが格納される。
69. データ型
¡ 論理モデルのデータ型
l SimpleModelではXMLデータ型を使用
¡ アプリケーションのデータ型
l アプリケーションが使用するデータ型
¡ JDOのデータ型
l JDOが格納できるデータ型
¡ アプリケーションが使用するデータ型とJDOが格納
できるデータ型は異なる
¡ マッピングと変換処理が必要
l 論理モデル→アプリケーション⇔JDO
71. 1エンティティの操作
¡ 1エンティティのcreate, update, deleteはアト
ミックに行われる。ただし…
l 1エンティティに対する多数の競合がある場合はエラー
l クオータ制限を超えている場合はエラー
l データベースの内部エラー
¡ 「1エンティティに対する多数の競合がある場合は
エラー」は今までのデータベースよりも簡単に発生
すると思われる
l リトライ処理が重要
72. エンティティ・グループ
¡ 指定方法
l Key作成時に明示
l owned property
¡ トランザクション使用時に複数エンティティのアトミッ
ク処理を保障
¡ 楽観ロック
l 競合時には簡単にエラーとなる
¡ トランザクション使用時場合は、データストア操作は
エンティティ・グループの範囲で行う必要がある
l 複数のrootエンティティ(つまりエンティティ・グループを指
定しないエンティティ)の更新もダメ
74. 問合わせ1000件問題
¡ クエリが扱える物理件数は1000件まで
l 検索結果が1000件以上になっても最初の1000件しか
扱えない
l 当然全件検索も同様
¡ 検索結果を1000件以下に絞り込む必要がある
l エンティティ・グループの利用
l 全件検索が必要な場合にはシーケンシャル番号の採番
などの対策が必要
l ユースケースで不用意な全件検索がないか確認
75. 非正規化
¡ 実装方法
l リスト
l embedded entity
l serializable object
l アプリケーションでXMLなどにシリアライズ
¡ RDBMSの都合でエンティティ分割を行っていた場合
l 多重度2以上のデータ型、Wholeエンティティに従属するPart
エンティティ
¡ 論理的に複数のエンティティで構成されている場合でも、動
作性能、トランザクションに対する最適化のための非正規化
が有効
l 検索対象でないエンティティは問題なく非正規化できる
l 検索対象の場合も、検索用のカラムを用意して非正規化すると
いう選択もある
76. モデリング
¡ DataStoreの細かな機能を直接操作するのは難易度が高く、
しかも煩雑
l エンティティ・グループ
l インデックス
l 非正規化
l 継承のマッピング
l トランザクション
l 検索用メタ・エンティティ、プロパティの定義と操作
¡ 用途ごとに使い方のパターンがあるはず
l モデリングが有効に使えるのではないか
¡ SimpleModelerのScala DSLでPIM(Platform
Independent Model)を定義すると、モデルの意味・意図
から自動的にGAE/Jに適した実装が生成されるのが目標
77. ユースケース・モデル
¡ 問合わせパターンを明確にする
l エンティティ設計
l インデックス設計
l エンティティ・グループ設計
l 埋め込みエンティティ設計
¡ 責務の抽出
l コンポーネントの抽出につなげる
¡ 外部イベント、非同期、並行、分散の抽出
l メッセージングを用いたアーキテクチャの抽出につなげる
79. 関連/集約/合成
¡ 関連(association)、集約(aggregation)、合成
(composition)の違いを、実装に活かす。
¡ 対象項目
l エンティティ・グループ
¡ owned entity
l エンティティの埋め込み
¡ embedded entity
¡ serializable object
¡ アプリケーションでシリアライズ(XMLなど)
¡ 案
l 集約はエンティティ・グループ、合成はエンティティの埋め
込み