DSL駆動によるクラウド・アプリケーション開発

DSL駆動によるクラウド・アプリケーション開発
SimpleModeling / SimpleModelerによるアプローチ

浅海智晴
匠Lab/edge2.cc/Javaユーザグループ
2009年9月18日

浅海のプロフィール
¡  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フェロー

開発プログラム
¡  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プログラムと仕様書を生成

匠グループ全体コンセプト

http://www.takumi-method.biz/

戦略には価値がなく、戦略と実現の融合に価値
が生まれる
戦略
オペレーション

ビジネス
ビジネス戦略オペレーション

表（価値）
What How 裏（実現）

What 表（価値）

裏（実現）
How

表（価値）
What How 裏（実現）

システム要求
システム設計

参考：日経 Itpro 萩本・匠style研究所「論理的美の虚像」

第７回 http://itpro.nikkeibp.co.jp/article/COLUMN/20090619/332251/
第８回 http://itpro.nikkeibp.co.jp/article/COLUMN/20090717/334022/
第９回 http://itpro.nikkeibp.co.jp/article/COLUMN/20090825/335978/

システム開発技術のスマイルカーブ

要求開発クラウド・コンピューティング

モデル駆動開発
業務改革
業務創造先端技術

製造

本セッションの目的

¡  DSL駆動開発によるクラウド・アプリケーショ
ン開発を概観する
l  クラウド・アプリケーション
l  モデリング

l  DSLコンパイラ

¡  edge2.ccの取り組みを紹介

関連雑誌記事
¡  『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日発売)

目次

¡  クラウド時代を確認

¡  SimpleModeling

¡  SimpleModeler

¡  edge2.cc

¡  クラウド時代のモデリング

クラウドとは
クラウド

システム・プラットフォーム
仮想化
としてのクラウド
ホスティング

Amazon EC2 統合プラットフォーム
PaaS
Googlle
ソフトウェア・プラットフォーム App Engine
Web
SaaS

Amazon A2S

SaaS: Software as a Service
PaaS: Platform as a Service

Webがプラットフォームになる

アプリケーション


Web

Java Java

OS OS OS

マーケットの変化

勘定系システム

基幹系システム
Web

情報系システム

クラウド
集合知勘定系システム
情報系システム
モバイル・デバイス基幹系システム

クラウド・コンピューティングの意義

¡  「チープ革命」(Web 2.0)の実現
l  ソフトウェア開発・運用のコスト構造が激変
¡  クラウド時代にはさらに…
l  DSL駆動開発
¡  プログラムの自動生成

l  オフショア開発
¡  単純開発は国内に残らない

l  CBD (Component-Based Development)
¡  Webプラットフォーム上でのサービス・コンポーネントの
再利用
¡  マッシュアップ

クラウド時代のソフトウェア開発

業務
業務

アーキテクチャ
方式開発

クラウドに飲み込まれてしまう!
製造コンポーネント開発
プラットフォームの共用
コンポーネント・サービスの再利用
オフショア開発
プログラム自動生成
システム保守・運用システム保守・運用
ハードウェア保守・運用ハードウェア保守・運用

DSL駆動開発＆コンポーネント
分析設計実装

DSL 自動生成コンポーネント

OO分析

OO設計 OO実装コンポーネント



OO分析

OO設計 OO実装コンポーネント

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

SimpleModeling技術
l  企業アプリケーション向けモデリング手法
l  業務モデリング、ドメイン・モデリング、要求モデ
リング、システム・モデリング
¡  MindmapModeling
l  SimpleModelingのモデル抽出手法
l  ドメイン・モデリング(+業務モデリング)

l  SimpleModeling用モデル・コンパイラ

オブジェクト・モデルの構成
状態機械モデル

ステートマシーン図

ユースケースを現実化したものがコミュニケーショ
ン図/シーケンス図、コミュニケーション図/シーケン
オブジェクト図/クラス
ス図を利用者の視点によるシステムの利用事例と
図、コミュニケーション
して抽象化したものがユースケース
図/シーケンス図に登
場するオブジェクトの
状態遷移を記述

ユースケース図コミュニケーション図オブジェクト図

ユースケース
(利用事例)

クラス図をインスタンス
化(実体化)したものが
オブジェクト図

コミュニケーション図を時間
軸の側面から記述したものシーケンス図クラス図
オブジェクト図上でコラ
がシーケンス図
ボレーション(メッセー
ジの送受信の集まり)
を記述したものがコミュ
ニケーション図

協調モデル静的構造モデル

モデリング技術の本格適用

汎用機、 C/S時代クラウド時代

協調モデル協調モデル

状態機械モデル状態機械モデル

静的構造モデル静的構造モデル

ドメイン･モデルをハブとした連携

要求モデル

拡張
業務モデルシステム・モデル
抽出

問題空間追加

解決空間
プラットフォーム独立

解決空間
プラットフォーム固有追加設計モデル

ドメイン・モデル

モデル変換の流れ

業務モデリング要求モデリングシステム・モデリング設計実装
アプリケーション・モデル

システム
業務モデル抽出要求モデル変換具体化設計モデル実現実装
モデル

調整

調整

参照
抽出

拡張

解決空間解決空間
問題空間プラットフォームプラットフォーム実現実装
非依存固有


モデル変換/アーキテクチャの側面から
業務モデルドメイン・モデル要求モデルシステム・モデル設計モデル実装

静的構造エンティティドメイン層ドメイン層

抽出
具体化格納
現実世界
データベース


抽出
コントロールアプリケーション層アプリケーション層
ボキャブラリ詳細化実現

動的モデル
具体化

文脈

ユースケース

具体化
利用事例バウンダリプレゼンテーション層プレゼンテーション層

操作

やりたいこと

エンド・ユーザ

アプリケーション・モデル

UMLの長所と短所
¡  長所
l  唯一の標準オブジェクト・モデル記法である。
l  メタ・モデルが厳密に定義されている。
l  グラフィカル言語であり、概要情報の伝達にすぐれている。
¡  短所
l  オブジェクト・モデル以外の記述には必ずしも適していな
い。
l  オブジェクト・モデルも完全に記述できるわけではない。
l  作成効率が必ずしも高くない。
l  モデル・リポジトリの操作性がよくない。
l  大規模開発に必ずしも適していない。
l  自然言語情報の取り扱いが不十分。

Modegramming (モデグラミング)

¡  Modeling + Programming
l  モデリングとプログラミングの融合
¡  テキストDSL+モデルコンパイラによるモデル駆動開
発
l  DSL (Domain Specific Language)
¡  Scala DSL

¡  Mindmap DSL (MindmapModeling)

¡  Excel DSL, XML DSL, JRuby DSLなど必要に応じて

l  メタ・モデル(モデル体系)
l  モデルコンパイラ

SimpleModeler

¡  SimpleModel用モデル・コンパイラ

¡  テキストDSL
l  Scala DSL
l  Scala DSL＆mavenによるモデル・リポジトリ

¡  Web仕様書、Java、Grails、Google App
Engine Python/Javaを生成

Scalaについて
¡  純粋オブジェクト指向言語+本格関数型言語
l  関数型言語とクラウドは相性がよいはず
¡  静的型付
¡  Java VM上で動作
¡  言語仕様が複雑
l  その代わり浅海の体感ではJavaの3倍ぐらいの生産性
がある
¡  DSLのホスト言語として充実した機能を持っている
¡  モデル・コンパイラの実装言語として充実した機能
を持っている

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
プログラム
企画中

SimpleModeler
CSVで記述できること
yorozu.csv

#actor,base,parts,attrs,powers,states,roles
顧客,,,住所
個人顧客,顧客,,,性別(男性;女性)
法人顧客,顧客
従業員,,,,,,店員
#role
店員
#resource
商品,,製品+,,,商品状態(入荷待;在庫中;配送中;販売完)
製品
#event
顧客取引,,顧客;店員
顧客購入,顧客取引,商品+

SimpleModeler
マインドマップ(XMind)

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>

attribute("value", XString)
}

case class DVN製品Name extends DomainValueName {
term = "製品Name"
caption = "製品Name"
brief = <t></t>

attribute("value", XString)
}

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>

}

SimpleModeler
ステートマシーン図と状態遷移表

SimpleModeler
Google App Engine/Java Servlet/JSP/
Dojo Toolkit

SimpleModeler
Google Web Toolkit

アプリケーション構成
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

edge2.cc
¡  Edge to Cloud Computing
¡  http://www.edge2.cc
¡  モデル駆動開発×クラウドコンピューティングの実
証プロジェクト
¡  アプリケーション開発者の立場から、クラウド・アプ
リケーションの開発技法を確立する
l  要素技術、アーキテクチャ、モデリング、モデル駆動開発
l  モデル駆動開発の技術として
SimpleModeling&SimpleModelerを採用

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に出展

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ブラウザ

edgeSNS
¡  簡易版SNS
l  SNS日記機能の実現
l  クラウド・アプリケーションの構築技術を追求するのを目
的に、アプリケーションは平凡なものを選択
¡  目的
l  メッセージングの活用
l  非同期入出力の活用
l  メッセージング、非同期入出力の実現に対する
SimpleModelerの活用
l  メッセージングを基盤にしたコンポーネント・ベース開発

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の手法で、メッセ
ージ形式ごとにデータ変換を行う。
個々のメッセージ変換機はコンポーネン
トなので、容易に機能追加が可能。コンポーネントを追加することで、機
能拡張を容易に行うことができる
外部データの取り込みもコンポーネント
化されて、容易に機能拡張が可能。

クラウド時代のモデリング
¡  CIM (Computer Independent Model)
l  概念モデル
l  変化なし

¡  PIM (Platform Independent Model)
l  論理モデル
l  少し変化：非同期、並列、分散への対応

¡  PSM (Platform Specific Model)
l  物理モデル
l  大きく変化：クラウド・プラットフォーム

アプリケーション統合の障壁

¡  Networks are unreliable.
¡  Networks are slow.

¡  Any two applications are different.

¡  Change is inevitable.
『Enterprise Integration Patterns』より

クラウド・アプリケーションの作法

¡  エラーの発生を前提とする。
l  Networks is are unreliable.
¡  入出力は非同期処理を前提とする。
l  Networks are slow.
¡  Webプラットフォームを前提とする。
l  Any two applications are different.
¡  アジャイル開発を前提とする。
l  Chenge is inevitable.

クラウド・アプリケーション

¡  Webアプリケーション
l  MVC2からMVCへ
l  クライアント/サーバ時代のGUIをWebで実現
l  HTML5
¡  スケーラビリティ
l  非同期処理、並行処理、分散処理
l  ACIDからBASEへ
¡  Key/Valueストレージ

¡  分散アプリケーション
l  故障と遅延への対応
l  逐次処理から並行処理へ

クラウド・アプリケーションの三つの技術

¡  UI
l  Web GUI
l  クライアント/サーバ時代のGUIをWebで

l  HTML5

¡  データベース
l  KVS (Key/Valueストレージ)
¡  通信方式
l  メッセージング
l  メッセージ・キューを用いた非同期通信

スケールアップとスケールアウト

プレゼンテーションアプリケーションデータベース

汎用機スケールアップ
(1段モデル)
サーバー

スケールアウトスケールアップ

クライアント・サーバークライアントサーバー
(2段モデル)
スケールアウトスケールアップ

クライアントサーバー

Web スケールアウトスケールアップ
(3段モデル)

スケール
クラウドスケールアウト
アップ
(分散モデル?)

負荷分散
クライアント

クライアント Webサーバ

サーバ

アプリケーションデータベース
サーバサーバ

サーバ


クライアント

クライアント

非同期処理

基本処理1

基本処理2 非同期処理A

基本処理3

基本処理4 非同期処理B

基本処理5

分散処理
部分問題A

部分問題B

問題部分問題C 解

部分問題D

部分問題E

イベント駆動処理

外部事象A

イベント処理A

外部事象B
イベント処理B リソース常駐処理

イベント処理C

外部事象C

クラウド・アプリケーションのアーキテク
チャ

サーバ側では、 GUIが使用する
サービスを提供する。

クライアントはWebブラウザ上で
動作するHTML5で本格的なGUI
プレゼンテーション層
を構築する。
クラウド・アプリケーション
クライアント側サーバ側アプリケーションの論理的な構成は
従来のものと変わらない
プレゼンテーション層
HTML5 サービス

ビジネス層

ドメイン層

プレゼンテーション層はWeb指統合層アクセス方式1: RDBMS
向のMVC2ではなく、クライアント ACID特性を要求されるデータはRDBMSに
アクセス方式4：手続き呼出し
/サーバ時代のGUIに回帰する。格納する。
性能特性、障害特性がローカル
の手続き呼び出しよりも脆弱。

アクセス方式5：メッセージング統合層
分散環境での連携に適応する特性をもつ。 RDBMS

メッセージ・キュー

アクセス方式2： KVS
KVS 一般のデータはKVSに格納するのが望ましい。
サービス REST

サービス

アクセス方式3:REST
Webページを手繰って情報を取得するサービス

クラウド・アプリケーションのアーキテク
チャ例

マスターデータなど更新頻度が低いデータは
KVSで配布して直接参照する。
結果を直接知りたい場合には、手続き呼
KVS び出しで同期型の連携を行う。
この形式の連携を行うとスケーラビリティが
低くなる。

プレゼンテーションの段階でできることをや
っておくと、スケールアウトの効果によってクラウド・アプリケーション
スケーラビリティが高まる。
外部サービスからRESTを用いて情報を取
得するのが典型的な利用方法。サービス利用の主力はメッセージである。
プレゼンテーションサービスサービス
この形式の連携を行うとスケールアウトに
よってスケーラビリティを確保できる。

サービスバックエンドのサービス群もメッセージによ
メッセージ・キュー
REST って連携。

サービスメッセージ・キュー

同期通信
サービス

メッセージ送信

メッセージ配信

KVS RDBMS
データベースをアクセスするスコープは
サービスに閉じておくのがよい。

KVSとRDBMSを適材適所で使い分ける。
可能であればKVSを使うのが望ましい。

クラウド・アプリケーションへの移行パス
第一段階第二段階第三段階
導入過渡期本格適用

HTML5 HTML5 HTML5
UI

RDBMS KVS KVS
KVS RDBMS RDBMS

データベース

負荷分散負荷分散
負荷分散
(非同期)
非同期
スケーラビリティ分散処理
イベント駆動

サービス利用 REST REST REST
AtomPub AtomPub
メッセージングメッセージング

インテグレーション・
フレームワークフレームワーク

クラウド・アプリケーションの設計技法
¡  概念モデル(要求モデル)は今までどおり
l  ドメイン・モデル
l  ユースケース・モデル
¡  論理モデル(PIM, Platform Independent Model)
l  非同期、並列、分散を本格的に取り込む
l  メッセージングによる分散コンポーネントの非同期通信
¡  物理モデル(PSM, Platform Specific Model)
l  データ・モデルのKVS化
¡  非正規化(データ集約)、データ分割
l  Web技術に対応
¡  HTML5, AtomPub
l  分散技術に対応
¡  メッセージング
l  メッセージングを軸とした統合フレームワークの導入

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、 )

SimpleModelerによるDSL駆動アプローチ

¡  ドメイン・モデル(概念モデル、論理モデル)からクラ
ウド向けの物理モデルの自動生成
l  クラウド・アプリケーション開発で難易度が高く、煩雑なプ
ログラムを自動生成
¡  ユースケース・モデル
l  ドメイン・モデルの正当性を検証
l  サービス・モデルを抽出
¡  サービス・モデル
l  RESTやAtomPubなどのサービスのAPIとエントリポイン
トを自動生成
¡  edgeSNSの開発を通じて実用化していく

まとめ

¡  クラウド時代にはアプリケーション開発のア
プローチが大きく変わる
l  スケーラビリティ、遅延、故障
¡  DSL駆動開発によるクラウド・アプリケーショ
ン開発の有効性は？
¡  edge2.ccでSimpleModelerを使用したク
ラウド・アプリケーションのDSL駆動開発を
実証実験中

付録

¡  Google
App Engine JavaのDataStore
のモデリングに関するメモ(SDK 1.2.4レベ
ル)

データストアの考慮点(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

データストアの考慮点(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が格納される。

データ型
¡  論理モデルのデータ型
l  SimpleModelではXMLデータ型を使用
¡  アプリケーションのデータ型
l  アプリケーションが使用するデータ型
¡  JDOのデータ型
l  JDOが格納できるデータ型
¡  アプリケーションが使用するデータ型とJDOが格納
できるデータ型は異なる
¡  マッピングと変換処理が必要
l  論理モデル→アプリケーション⇔JDO

インデックス

¡  インデックスがない項目は検索対象になら
ない
¡  インデックスはカラムごとではなく、問合わせ
パターンごとに必要
¡  問合わせのパターンによってはインデックス
のデータ量が爆発する
¡  インデックスの項目が増えると更新処理に
時間がかかる

1エンティティの操作
¡  1エンティティのcreate, update, deleteはアト
ミックに行われる。ただし…
l  1エンティティに対する多数の競合がある場合はエラー
l  クオータ制限を超えている場合はエラー
l  データベースの内部エラー
¡  「1エンティティに対する多数の競合がある場合は
エラー」は今までのデータベースよりも簡単に発生
すると思われる
l  リトライ処理が重要

エンティティ・グループ
¡  指定方法
l  Key作成時に明示
l  owned property
¡  トランザクション使用時に複数エンティティのアトミッ
ク処理を保障
¡  楽観ロック
l  競合時には簡単にエラーとなる
¡  トランザクション使用時場合は、データストア操作は
エンティティ・グループの範囲で行う必要がある
l  複数のrootエンティティ(つまりエンティティ・グループを指
定しないエンティティ)の更新もダメ

トランザクション

¡  同一エンティティ・グループに所属する複数
のオブジェクトの同時操作に対して有効
l  複数のエンティティ・グループに対する操作はで
きない
¡  楽観的ロックなのでエラーになる可能性が
ある
l  リトライが必要
l  リトライでも救えない場合の対処も必要

問合わせ1000件問題
¡  クエリが扱える物理件数は1000件まで
l  検索結果が1000件以上になっても最初の1000件しか
扱えない
l  当然全件検索も同様
¡  検索結果を１０００件以下に絞り込む必要がある
l  エンティティ・グループの利用
l  全件検索が必要な場合にはシーケンシャル番号の採番
などの対策が必要
l  ユースケースで不用意な全件検索がないか確認

非正規化
¡  実装方法
l  リスト
l  embedded entity
l  serializable object
l  アプリケーションでXMLなどにシリアライズ
¡  RDBMSの都合でエンティティ分割を行っていた場合
l  多重度2以上のデータ型、Wholeエンティティに従属するPart
エンティティ
¡  論理的に複数のエンティティで構成されている場合でも、動
作性能、トランザクションに対する最適化のための非正規化
が有効
l  検索対象でないエンティティは問題なく非正規化できる
l  検索対象の場合も、検索用のカラムを用意して非正規化すると
いう選択もある

モデリング
¡  DataStoreの細かな機能を直接操作するのは難易度が高く、
しかも煩雑
l  エンティティ・グループ
l  インデックス
l  非正規化
l  継承のマッピング
l  トランザクション
l  検索用メタ・エンティティ、プロパティの定義と操作
¡  用途ごとに使い方のパターンがあるはず
l  モデリングが有効に使えるのではないか
¡  SimpleModelerのScala DSLでPIM(Platform
Independent Model)を定義すると、モデルの意味・意図
から自動的にGAE/Jに適した実装が生成されるのが目標

ユースケース・モデル
¡  問合わせパターンを明確にする
l  エンティティ設計
l  インデックス設計
l  エンティティ・グループ設計
l  埋め込みエンティティ設計
¡  責務の抽出
l  コンポーネントの抽出につなげる
¡  外部イベント、非同期、並行、分散の抽出
l  メッセージングを用いたアーキテクチャの抽出につなげる


¡  関連/集約/合成、Aggregateパターン

¡  エンティティ構造が内包する特性を活用
l  エンティティ
¡  owned entity
¡  embedded entity

¡  serializable object

¡  アプリケーションでシリアライズ

l  インデックス

関連/集約/合成
¡  関連(association)、集約(aggregation)、合成
(composition)の違いを、実装に活かす。
¡  対象項目
¡  owned entity
l  エンティティの埋め込み
¡  embedded entity
¡  serializable object
¡  アプリケーションでシリアライズ(XMLなど)

¡  案
l  集約はエンティティ・グループ、合成はエンティティの埋め
込み

Aggregateパターン
¡  関連/集約/合成に加えて、Aggregateパ
ターンをオブジェクトのクラスタを特定する目
的で使用する
¡  対象項目
l  エンティティの埋め込み

¡  案
l  Aggregateパターンはエンティティ・グループ
l  Aggregateパターンはエンティティの埋め込み

DSL駆動によるクラウド・アプリケーション開発

Recomendados

Recomendados

Mais conteúdo relacionado

Destaque

Destaque (20)

Semelhante a DSL駆動によるクラウド・アプリケーション開発

Semelhante a DSL駆動によるクラウド・アプリケーション開発 (20)

Mais de Tomoharu ASAMI

Mais de Tomoharu ASAMI (20)

DSL駆動によるクラウド・アプリケーション開発