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

1,875 views

Published on

0 Comments
2 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,875
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
20
Comments
0
Likes
2
Embeds 0
No embeds

No notes for slide

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

  1. 1. DSL駆動によるクラウド・アプリケーション開発SimpleModeling / SimpleModelerによるアプローチ浅海智晴匠Lab/edge2.cc/Javaユーザグループ2009年9月18日
  2. 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. 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プログラムと仕様書を生成
  4. 4. 匠グループ全体コンセプト http://www.takumi-method.biz/
  5. 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/
  6. 6. システム開発技術のスマイルカーブ 要求開発 クラウド・コンピューティング モデル駆動開発業務改革業務創造 先端技術 製造
  7. 7. 本セッションの目的 ¡  DSL駆動開発によるクラウド・アプリケーショ ン開発を概観する l  クラウド・アプリケーション l  モデリング l  DSLコンパイラ¡  edge2.ccの取り組みを紹介
  8. 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日発売)
  9. 9. 目次 ¡  クラウド時代を確認¡  SimpleModeling¡  SimpleModeler¡  edge2.cc¡  クラウド時代のモデリング
  10. 10. 目次 ¡  クラウド時代を確認¡  SimpleModeling¡  SimpleModeler¡  edge2.cc¡  クラウド時代のモデリング
  11. 11. クラウドとは クラウド システム・プラットフォーム仮想化 としてのクラウド ホスティング Amazon EC2 統合プラットフォーム としてのクラウド PaaS Googlle ソフトウェア・プラットフォーム App EngineWeb としてのクラウド SaaS Amazon A2S SaaS: Software as a Service PaaS: Platform as a Service
  12. 12. Webがプラットフォームになる アプリケーション アプリケーション Web アプリケーション Java Java OS OS OS
  13. 13. マーケットの変化 勘定系システム 基幹系システム Web 情報系システム クラウド 集合知 勘定系システム 情報系システム モバイル・デバイス 基幹系システム
  14. 14. クラウド・コンピューティングの意義 ¡  「チープ革命」(Web 2.0)の実現 l  ソフトウェア開発・運用のコスト構造が激変¡  クラウド時代にはさらに… l  DSL駆動開発 ¡  プログラムの自動生成 l  オフショア開発 ¡  単純開発は国内に残らない l  CBD (Component-Based Development) ¡  Webプラットフォーム上でのサービス・コンポーネントの 再利用 ¡  マッシュアップ
  15. 15. クラウド時代のソフトウェア開発 業務 業務 アーキテクチャ 方式 開発 クラウドに飲み込まれてしまう! 製造 コンポーネント開発 プラットフォームの共用 コンポーネント・サービスの再利用 オフショア開発 プログラム自動生成 システム保守・運用 システム保守・運用ハードウェア保守・運用 ハードウェア保守・運用
  16. 16. DSL駆動開発&コンポーネント 分析 設計 実装 DSL 自動生成 コンポーネント OO分析 OO設計 OO実装 コンポーネント DSL 自動生成 コンポーネント DSL 自動生成 コンポーネント OO分析 OO設計 OO実装 コンポーネント
  17. 17. 目次 ¡  クラウド時代を確認¡  SimpleModeling¡  SimpleModeler¡  edge2.cc¡  クラウド時代のモデリング
  18. 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. 19. SimpleModeling技術 ¡  SimpleModeling l  企業アプリケーション向けモデリング手法 l  業務モデリング、ドメイン・モデリング、要求モデ リング、システム・モデリング¡  MindmapModeling l  SimpleModelingのモデル抽出手法 l  ドメイン・モデリング(+業務モデリング)¡  SimpleModeler l  SimpleModeling用モデル・コンパイラ
  20. 20. SimpleModelingの本
  21. 21. オブジェクト・モデルの構成 状態機械モデル ステートマシーン図 ユースケースを現実化したものがコミュニケーション図/シーケンス図、 コミュニケーション図/シーケン オブジェクト図/クラスス図を利用者の視点によるシステムの利用事例と 図、 コミュニケーション して抽象化したものがユースケース 図/シーケンス図に登 場するオブジェクトの 状態遷移を記述 ユースケース図 コミュニケーション図 オブジェクト図 ユースケース (利用事例) クラス図をインスタンス 化(実体化)したものが オブジェクト図 コミュニケーション図を時間 軸の側面から記述したもの シーケンス図 クラス図 オブジェクト図上でコラ がシーケンス図 ボレーション(メッセー ジの送受信の集まり) を記述したものがコミュ ニケーション図 協調モデル 静的構造モデル
  22. 22. モデリング技術の本格適用 汎用機、 C/S時代 クラウド時代 協調モデル 協調モデル 状態機械モデル 状態機械モデル 静的構造モデル 静的構造モデル
  23. 23. ドメイン・モデルをハブとした連携 要求モデル 拡張 業務モデル システム・モデル 抽出 問題空間 追加 解決空間 プラットフォーム独立 解決空間 プラットフォーム固有 追加 設計モデル ドメイン・モデル
  24. 24. モデル変換の流れ 業務モデリング 要求モデリング システム・モデリング 設計 実装 アプリケーション・モデル システム 業務モデル 抽出 要求モデル 変換 具体化 設計モデル 実現 実装 モデル 調整 調整 参照 抽出 拡張 解決空間 解決空間 問題空間 プラットフォーム プラットフォーム 実現 実装 非依存 固有 ドメイン・モデル
  25. 25. モデル変換/アーキテクチャの側面から 業務モデル ドメイン・モデル 要求モデル システム・モデル 設計モデル 実装 静的構造 エンティティ ドメイン層 ドメイン層 抽出 具体化 格納 現実世界 データベース ドメイン・モデル 抽出 コントロール アプリケーション層 アプリケーション層 ボキャブラリ 詳細化 実現 動的モデル 具体化 文脈 ユースケース 具体化 利用事例 バウンダリ プレゼンテーション層 プレゼンテーション層 操作 やりたいこと エンド・ユーザ アプリケーション・モデル
  26. 26. UMLの長所と短所 ¡  長所 l  唯一の標準オブジェクト・モデル記法である。 l  メタ・モデルが厳密に定義されている。 l  グラフィカル言語であり、概要情報の伝達にすぐれている。¡  短所 l  オブジェクト・モデル以外の記述には必ずしも適していな い。 l  オブジェクト・モデルも完全に記述できるわけではない。 l  作成効率が必ずしも高くない。 l  モデル・リポジトリの操作性がよくない。 l  大規模開発に必ずしも適していない。 l  自然言語情報の取り扱いが不十分。
  27. 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
  28. 28. 目次 ¡  クラウド時代を確認¡  SimpleModeling¡  SimpleModeler¡  edge2.cc¡  クラウド時代のモデリング
  29. 29. SimpleModeler¡  SimpleModel用モデル・コンパイラ¡  テキストDSL l  Scala DSL l  Scala DSL&mavenによるモデル・リポジトリ¡  Web仕様書、Java、Grails、Google App Engine Python/Javaを生成
  30. 30. Scalaについて ¡  純粋オブジェクト指向言語+本格関数型言語 l  関数型言語とクラウドは相性がよいはず¡  静的型付¡  Java VM上で動作¡  言語仕様が複雑 l  その代わり浅海の体感ではJavaの3倍ぐらいの生産性 がある¡  DSLのホスト言語として充実した機能を持っている¡  モデル・コンパイラの実装言語として充実した機能 を持っている
  31. 31. SimpleModelerの動作 Web仕様書 project クラス図 html ステート CSV import マシーン図 java SimpleModelリポジトリ (Maven project) Javaプログラムconvert grails Scala DSL Grailsプログラム import gaeMindmap(Xmind) Google App Engine/Python プログラム gaej verify testset import Google App Engine/Java gaeo プログラム Excel 検証結果 テストセット Google App Engine Oil プログラム 企画中
  32. 32. SimpleModelerCSVで記述できること yorozu.csv#actor,base,parts,attrs,powers,states,roles顧客,,,住所個人顧客,顧客,,,性別(男性;女性)法人顧客,顧客従業員,,,,,,店員#role店員#resource商品,,製品+,,,商品状態(入荷待;在庫中;配送中;販売完)製品#event顧客取引,,顧客;店員顧客購入,顧客取引,商品+
  33. 33. SimpleModelerマインドマップ(XMind)
  34. 34. SimpleModelerScala DSLpackage com.yorozuimport 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)}
  35. 35. SimpleModelerWeb仕様書
  36. 36. SimpleModelerクラス図
  37. 37. SimpleModelerScala 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> }
  38. 38. SimpleModelerステートマシーン図と状態遷移表
  39. 39. SimpleModelerGoogle App Engine/Java Servlet/JSP/Dojo Toolkit
  40. 40. SimpleModelerGoogle App Engine/JavaGoogle Web Toolkit
  41. 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
  42. 42. 目次 ¡  クラウド時代を確認¡  SimpleModeling¡  SimpleModeler¡  edge2.cc¡  クラウド時代のモデリング
  43. 43. edge2.cc¡  Edge to Cloud Computing¡  http://www.edge2.cc¡  モデル駆動開発×クラウドコンピューティングの実 証プロジェクト¡  アプリケーション開発者の立場から、クラウド・アプ リケーションの開発技法を確立する l  要素技術、アーキテクチャ、モデリング、モデル駆動開発 l  モデル駆動開発の技術として SimpleModeling&SimpleModelerを採用
  44. 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. 45. TwitterRecommender iPhone iTwitter Recommender XML Sync+ Offline Google App Engine JavaTwitter 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. 46. edgeSNS¡  簡易版SNS l  SNS日記機能の実現 l  クラウド・アプリケーションの構築技術を追求するのを目 的に、アプリケーションは平凡なものを選択¡  目的 l  メッセージングの活用 l  非同期入出力の活用 l  メッセージング、非同期入出力の実現に対する SimpleModelerの活用 l  メッセージングを基盤にしたコンポーネント・ベース開発
  47. 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の手法で、 メッセ ージ形式ごとにデータ変換を行う。 個々 のメッセージ変換機はコンポーネン トなので、 容易に機能追加が可能。 コンポーネントを追加することで、 機 能拡張を容易に行うことができる 外部データの取り込みもコンポーネント 化されて、 容易に機能拡張が可能。
  48. 48. 目次 ¡  クラウド時代を確認¡  SimpleModeling¡  SimpleModeler¡  edge2.cc¡  クラウド時代のモデリング
  49. 49. クラウド時代のモデリング ¡  CIM (Computer Independent Model) l  概念モデル l  変化なし¡  PIM (Platform Independent Model) l  論理モデル l  少し変化:非同期、並列、分散への対応¡  PSM (Platform Specific Model) l  物理モデル l  大きく変化:クラウド・プラットフォーム
  50. 50. アプリケーション統合の障壁 ¡  Networks are unreliable.¡  Networks are slow.¡  Any two applications are different.¡  Change is inevitable. 『Enterprise Integration Patterns』より
  51. 51. クラウド・アプリケーションの作法 ¡  エラーの発生を前提とする。 l  Networks is are unreliable.¡  入出力は非同期処理を前提とする。 l  Networks are slow.¡  Webプラットフォームを前提とする。 l  Any two applications are different.¡  アジャイル開発を前提とする。 l  Chenge is inevitable.
  52. 52. クラウド・アプリケーション ¡  Webアプリケーション l  MVC2からMVCへ l  クライアント/サーバ時代のGUIをWebで実現 l  HTML5¡  スケーラビリティ l  非同期処理、並行処理、分散処理 l  ACIDからBASEへ ¡  Key/Valueストレージ¡  分散アプリケーション l  故障と遅延への対応 l  逐次処理から並行処理へ
  53. 53. クラウド・アプリケーションの三つの技術 ¡  UI l  Web GUI l  クライアント/サーバ時代のGUIをWebで l  HTML5¡  データベース l  KVS (Key/Valueストレージ)¡  通信方式 l  メッセージング l  メッセージ・キューを用いた非同期通信
  54. 54. スケールアップとスケールアウト プレゼンテーション アプリケーション データベース 汎用機 スケールアップ (1段モデル) サーバー スケールアウト スケールアップ クライアント・サーバー クライアント サーバー (2段モデル) スケールアウト スケールアップ クライアント サーバー Web スケールアウト スケールアップ (3段モデル) クライアント サーバー スケール クラウド スケールアウト アップ (分散モデル?) クライアント サーバー
  55. 55. 負荷分散 クライアントクライアント Webサーバ アプリケーションクライアント Webサーバ サーバ アプリケーション データベースクライアント Webサーバ サーバ サーバ アプリケーションクライアント Webサーバ サーバクライアント Webサーバクライアントクライアント
  56. 56. 非同期処理 基本処理1 基本処理2 非同期処理A 基本処理3 基本処理4 非同期処理B 基本処理5
  57. 57. 分散処理 部分問題A 部分問題B 問題 部分問題C 解 部分問題D 部分問題E
  58. 58. イベント駆動処理 外部事象A イベント処理A 外部事象B イベント処理B リソース 常駐処理 イベント処理C 外部事象C
  59. 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. 60. クラウド・アプリケーションのアーキテクチャ例 マスターデータなど更新頻度が低いデータは KVSで配布して直接参照する。 結果を直接知りたい場合には、 手続き呼 KVS び出しで同期型の連携を行う。 この形式の連携を行うとスケーラビリティが 低くなる。プレゼンテーションの段階でできることをやっておくと、 スケールアウトの効果によって クラウド・アプリケーション スケーラビリティが高まる。外部サービスからRESTを用いて情報を取 得するのが典型的な利用方法。 サービス利用の主力はメッセージである。 プレゼンテーション サービス サービス この形式の連携を行うとスケールアウトに よってスケーラビリティを確保できる。 サービス バックエンドのサービス群もメッセージによ メッセージ・キュー REST って連携。 サービス メッセージ・キュー 同期通信 サービス メッセージ送信 メッセージ配信 KVS RDBMS データベースをアクセスするスコープは サービスに閉じておくのがよい。 KVSとRDBMSを適材適所で使い分ける。 可能であればKVSを使うのが望ましい。
  61. 61. クラウド・アプリケーションへの移行パス 第一段階 第二段階 第三段階 導入 過渡期 本格適用 HTML5 HTML5 HTML5 UI RDBMS KVS KVS KVS RDBMS RDBMS データベース 負荷分散 負荷分散 負荷分散 (非同期) 非同期スケーラビリティ 分散処理 イベント駆動 サービス利用 REST REST REST AtomPub AtomPub メッセージング メッセージング インテグレーション・フレームワーク フレームワーク
  62. 62. クラウド・アプリケーションの設計技法 ¡  概念モデル(要求モデル)は今までどおり l  ドメイン・モデル l  ユースケース・モデル¡  論理モデル(PIM, Platform Independent Model) l  非同期、並列、分散を本格的に取り込む l  メッセージングによる分散コンポーネントの非同期通信¡  物理モデル(PSM, Platform Specific Model) l  データ・モデルのKVS化 ¡  非正規化(データ集約)、データ分割 l  Web技術に対応 ¡  HTML5, AtomPub l  分散技術に対応 ¡  メッセージング l  メッセージングを軸とした統合フレームワークの導入
  63. 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. 64. SimpleModelerによるDSL駆動アプローチ ¡  ドメイン・モデル(概念モデル、論理モデル)からクラ ウド向けの物理モデルの自動生成 l  クラウド・アプリケーション開発で難易度が高く、煩雑なプ ログラムを自動生成¡  ユースケース・モデル l  ドメイン・モデルの正当性を検証 l  サービス・モデルを抽出¡  サービス・モデル l  RESTやAtomPubなどのサービスのAPIとエントリポイン トを自動生成¡  edgeSNSの開発を通じて実用化していく
  65. 65. まとめ ¡  クラウド時代にはアプリケーション開発のア プローチが大きく変わる l  スケーラビリティ、遅延、故障¡  DSL駆動開発によるクラウド・アプリケーショ ン開発の有効性は?¡  edge2.ccでSimpleModelerを使用したク ラウド・アプリケーションのDSL駆動開発を 実証実験中
  66. 66. 付録 ¡  Google App Engine JavaのDataStore のモデリングに関するメモ(SDK 1.2.4レベ ル)
  67. 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. 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. 69. データ型 ¡  論理モデルのデータ型 l  SimpleModelではXMLデータ型を使用¡  アプリケーションのデータ型 l  アプリケーションが使用するデータ型¡  JDOのデータ型 l  JDOが格納できるデータ型¡  アプリケーションが使用するデータ型とJDOが格納 できるデータ型は異なる¡  マッピングと変換処理が必要 l  論理モデル→アプリケーション⇔JDO
  70. 70. インデックス ¡  インデックスがない項目は検索対象になら ない¡  インデックスはカラムごとではなく、問合わせ パターンごとに必要¡  問合わせのパターンによってはインデックス のデータ量が爆発する¡  インデックスの項目が増えると更新処理に 時間がかかる
  71. 71. 1エンティティの操作 ¡  1エンティティのcreate, update, deleteはアト ミックに行われる。ただし… l  1エンティティに対する多数の競合がある場合はエラー l  クオータ制限を超えている場合はエラー l  データベースの内部エラー¡  「1エンティティに対する多数の競合がある場合は エラー」は今までのデータベースよりも簡単に発生 すると思われる l  リトライ処理が重要
  72. 72. エンティティ・グループ ¡  指定方法 l  Key作成時に明示 l  owned property¡  トランザクション使用時に複数エンティティのアトミッ ク処理を保障¡  楽観ロック l  競合時には簡単にエラーとなる¡  トランザクション使用時場合は、データストア操作は エンティティ・グループの範囲で行う必要がある l  複数のrootエンティティ(つまりエンティティ・グループを指 定しないエンティティ)の更新もダメ
  73. 73. トランザクション ¡  同一エンティティ・グループに所属する複数 のオブジェクトの同時操作に対して有効 l  複数のエンティティ・グループに対する操作はで きない¡  楽観的ロックなのでエラーになる可能性が ある l  リトライが必要 l  リトライでも救えない場合の対処も必要
  74. 74. 問合わせ1000件問題 ¡  クエリが扱える物理件数は1000件まで l  検索結果が1000件以上になっても最初の1000件しか 扱えない l  当然全件検索も同様¡  検索結果を1000件以下に絞り込む必要がある l  エンティティ・グループの利用 l  全件検索が必要な場合にはシーケンシャル番号の採番 などの対策が必要 l  ユースケースで不用意な全件検索がないか確認
  75. 75. 非正規化 ¡  実装方法 l  リスト l  embedded entity l  serializable object l  アプリケーションでXMLなどにシリアライズ¡  RDBMSの都合でエンティティ分割を行っていた場合 l  多重度2以上のデータ型、Wholeエンティティに従属するPart エンティティ¡  論理的に複数のエンティティで構成されている場合でも、動 作性能、トランザクションに対する最適化のための非正規化 が有効 l  検索対象でないエンティティは問題なく非正規化できる l  検索対象の場合も、検索用のカラムを用意して非正規化すると いう選択もある
  76. 76. モデリング ¡  DataStoreの細かな機能を直接操作するのは難易度が高く、 しかも煩雑 l  エンティティ・グループ l  インデックス l  非正規化 l  継承のマッピング l  トランザクション l  検索用メタ・エンティティ、プロパティの定義と操作¡  用途ごとに使い方のパターンがあるはず l  モデリングが有効に使えるのではないか¡  SimpleModelerのScala DSLでPIM(Platform Independent Model)を定義すると、モデルの意味・意図 から自動的にGAE/Jに適した実装が生成されるのが目標
  77. 77. ユースケース・モデル ¡  問合わせパターンを明確にする l  エンティティ設計 l  インデックス設計 l  エンティティ・グループ設計 l  埋め込みエンティティ設計¡  責務の抽出 l  コンポーネントの抽出につなげる¡  外部イベント、非同期、並行、分散の抽出 l  メッセージングを用いたアーキテクチャの抽出につなげる
  78. 78. ドメイン・モデル ¡  関連/集約/合成、Aggregateパターン¡  エンティティ構造が内包する特性を活用 l  エンティティ ¡  owned entity ¡  embedded entity ¡  serializable object ¡  アプリケーションでシリアライズ l  インデックス l  エンティティ・グループ
  79. 79. 関連/集約/合成 ¡  関連(association)、集約(aggregation)、合成 (composition)の違いを、実装に活かす。¡  対象項目 l  エンティティ・グループ ¡  owned entity l  エンティティの埋め込み ¡  embedded entity ¡  serializable object ¡  アプリケーションでシリアライズ(XMLなど)¡  案 l  集約はエンティティ・グループ、合成はエンティティの埋め 込み
  80. 80. Aggregateパターン ¡  関連/集約/合成に加えて、Aggregateパ ターンをオブジェクトのクラスタを特定する目 的で使用する¡  対象項目 l  エンティティ・グループ l  エンティティの埋め込み¡  案 l  Aggregateパターンはエンティティ・グループ l  Aggregateパターンはエンティティの埋め込み

×