1. Intalio Japan Special Cloud Workshop
Version 1.0.0
Last Changed on: 15.12.2010

2. Index
Contents :
– Object-genについて
– Google App Engine For Javaについて

3. Workshopを始める前に
本資料は、Intalioの製品以外
の話に重点を置いており、かつ
完全に技術的な話になります。
3

4. Object-genについて

5. Why?
• 今回お話をする内容は、MKI様より以下のリクエストがPOC実施時にありました。
• Object Builderを利用し、テーブル定義がほぼ同一のアプリケーションを構築する場合、毎
回同じ属性を入力しなくともよい仕組み
• 当時の実現方法としては、以下の通りでした。大規模のシステム構築では一般的です。
• 現在のステータスは、開発側は1年間何も進展がない為、廃止されております。
1.設計書作成
ユーザー Excel
SQL文
2.マクロ実行 3.手動でコピー
Intalio Cloud
5

6. Weak Point
• Object Builderに対する改善は、以下の通りになります。
• プレビュー画面がない
• 設定する項目が多いと時間がかかる
• Object Builder全体の機能が不明
• 不要な共通項目を毎回、削除せず、自ら定義したい
• テンプレートとなる設計書が存在しない
• 一度作成したObjectのコピーができない
• 開発側に要望を出していますが、実現するか否か不明です。
• 設計書→画面の自動作成の仕組みは、既に他社製品では実現済になります。
• 開発側の対応が待つ=ビジネスに取り残される事になり、どのようにすればよいか？
6

7. Resolution
• 開発者が開発時に何をするのか、という視点で、日本側がWeak Pointを解消するツール作成
• Cloud環境にデプロイする前に、プレビュー画面で確認
• システム開発は特定の人が全てを決定するのではなく、ユーザーが自らシステム開発に参
加が可能なツールを提供
• ユーザーが対応できない詳細なデータベース設計等はシステム開発者が対応
• 設計書→ソースコードの自動化を実現し、開発コストを削減
• 自社のテンプレートとなる仕組みの提供
• 将来、ソースコード→設計書の仕組みも考慮
• プログラミング言語はVBA, ExtJS, Rubyというメジャーな言語を利用し、将来は誰もが改良できる
構成を考慮（英語版への対応はなし）しています。
• ユーザーがシステム開発に参加する場合、以下の点のみ理解すればよい、と考えています。
• 表示したい項目は何か？
• 画面に表示する項目の配置は？
• 一覧画面に表示する項目は？
7

8. Overview
1.設計書作成 2.マクロ実行
ユーザー
ExtJS
Excel プレビュー
*シュミレーション
3.提供 同一ファイル
Ruby Intalio
Excel XSPファイル
Cloud
SI
4.マクロ実行 6.スクリプト
5.設計書追加 実行
8

9. Overview
• 設計書の構成は、以下の通りです。
• 画面に表示する項目
• 画面に表示する項目の詳細
• オプションリスト等に定義する項目の設定
• リレーションシップの設定
• 画面に表示する項目の配置
• 高度検索・一括更新画面の作成と定義
• 一覧画面に表示する項目とルール
• ボタンバーに表示する項目
• アコーディオンバーに表示する項目
• システム共通にて使用する項目・画面の設定変更
• システム開発者はExcelのシートを再表示する事で上記の項目の参照が可能です。
• ユーザーとのヒアリング時・ユーザーに提供して記述する等、どちらも対応が可能です。
9

10. Demonstration
• ユーザーが画面に表示する項目を定義
10

11. Demonstration
• システム管理者が設定する項目を定義
11

12. Demonstration
• ユーザーが画面に表示したい位置を定義
12

13. Demonstration
• ユーザーが一覧画面に表示したい項目を定義
13

14. Demonstration
• プレビュー画面を表示
14

15. Demonstration
• システム管理者が自社用にテンプレートを作成
15

16. Roadmap
1.設計書作成 2.マクロ実行
ユーザー
ExtJS
Excel プレビュー
*シュミレーション
2011年1月より開発着手予定
3.提供 同一ファイル 2011年5月より開発着手予定
Intalio Developers
Ruby Intalio
Excel XSPファイル
Cloud
SI
4.マクロ実行 6.スクリプト
5.設計書追加 実行
ExtJSがNode.js（サーバーサイドJ
avaScript）より呼出
16

17. Google App Engine For Javaについて

18. Google App Engine
• WebアプリケーションをGoogleのインフラ上に作成する事が可能
• Googleがインフラの構築、維持、管理等を行い為、インフラの知識は不要
• PythonとJavaが現在はサポート（JVMで稼働するJruby, Scala, Groovyも稼働）
• Googleに登録した後、無料で利用する事が可能(一定の基準以内）
SI ユーザー
Google
18

19. Why?
• これから説明しますアプリケーション「Idea Packet(アイディアパケット)」は、三重県へ出張中にコンセプト
をまとめました。
• 単純なパターン化した仕事のシステム化
• 自分専用のコピーロボットを作成し、インターネット経由でアクセス
• 業務フローを可視化する為に、マジカ！を利用し、記述し、当時、スターロジック（現在、マジカジャパン）
を訪問した際、羽生様・可世木様にマジカ！の利用方法を確認しました。
• 全体のフローの問題点はなし
• 当時、レンタルサーバーと契約しており、レンタルサーバー上での稼働を考慮したが、無料でアプリケー
ションをデプロイが可能な環境(=Cloud)が存在する事を発見しました。
Personal
知らない言葉 メールで送信
Googleで検索
知らない単語 後で確認
Team, Group
メールで送信
後で確認
19

20. What is Magica?
• 実際に記述しましたマジカ！のシートを本日は持ってきております。
• UMLでお客様と打合せをした結果を記述する事は可能ですが、お客様に渡す時、お客様側にUMLの知
識が求められます。BPMNについても、同様です。学習コストを最小限にし、お客様が理解できるツール、
現時点ではマジカ！が一番上記の条件を満たしていると考えております。
• 最近はお客様がシステム開発に自ら参加したい、という傾向は強いです。しかし、お客様が参加できる場
所は現状では打合せのみ、設計書等のレビューのみ、というケースが多いと思います。お客様自身が参
加できる為のツール、Object-genについても同様のコンセプトで考えております。
• 楽ができる所は楽をする
• 委譲できる所は委譲する
• ヒアリングでの対応を減らす
• 入力と記述、両方を比較した時、記述した方が印象が残っており、思い出しやすい、という事もあります。
20

21. Requirement
• 自分の行動を考慮すると、以下のAPIが必要であると判断しました。
• Google
• Yahoo
• Amazon
• 楽天
• Twitter （Public Timelineではなく、絞り込みが必須）
• YouTube （未対応）
ユーザー Application
GoogleAPI メールで送信
YahooAPI メールで送信
Request
選択可能
AmazonAPI メールで送信
楽天API メールで送信
21

22. Comparison
• 以下の図は、当時調査した各Cloudの調査結果です。
• サポートは一切使用せず、無料で構築するという観点から判断しています。
• 結論として、Google App Engineが調査時点では一番良く、かつTwitterを利用する事で有志の方々に質
問も可能である点も考慮しました（実際は、自力で解決）。
Stax.net Force.com Google App Engine
参考文献（書籍は全てなし） ×（Wiki） ○ ○
メーリングリスト/ブログでの状況 × △ ○
アプリケーション構築への知識 DB △ ○ ×（BigTable）
アプリケーション構築への知識 アプリ ○ ×（Apex） ○
管理コンソール関連 △ △ ○
開発ツールの提供 ×（コマンド） ○ ○
Cloud環境への申請時間 ×（遅い） ○ △（面倒）
Cloud環境へのデプロイ △（コマンド） ○（Eclipse） ○（Eclipse）
22

23. Public Cloud Development Strong Point
• Cloudでアプリケーションを開発する場合、開発に向いているアプリケーション・向
かないアプリケーションが存在する事は理解していますか?
• 向いているアプリケーション
• 開発者が5人以下のシステム（1人でも可能）
• 簡単, コスト安, 短期間で作成するシステム（→将来は大きく育てる）
• ユーザーの意向＜開発の意向、であるアプリケーション（レスポンスタイム等の制約）
• 向いていないアプリケーション
• レガシーシステム
• バッチプログラム(ネットワークへの負荷)
• RDBで作成したアプリケーションのリプレース（Key-Value型）
• 開発者が5人以上になるシステム
• 集計・フィルター等がSQL文で簡単に実行できない為、リアルタイムで集計処理が多いシステム（開
発工数は、通常のアプリケーション以上にコストがかかる）
23

24. New Development Style Service
• 初期費用0円、月々15万円というプランでサービスを構築する会社が存在し、注目されています。
• 対象範囲は、ExcelやAccessで利用しているシステムの置換えを焦点にしております。
24

25. Java Developer Survival
• 景気状況が良くなく、特にJavaの開発者が余剰である会社が多いです。
• Javaの開発者、特にレガシーシステムのみ経験した開発者は、現在の知識のみでは、プラットフォーム・
基盤開発を担当しない限り、今後明るい未来はありません。
• Google App EngineやMicrosoft Azureはギグーな人だけが対応可能なプラットフォームではありません。
• Google App Engineは2009年4月に公開され、2年間も経ていなく、HTML5等の技術を組み合わせる事で、
新たな可能性を秘めております。
• Google App Engine/Microsoft Azure, 共にデータベースはKey Value型（KVS）である為、新たにマスターし
なければならない事がありますが、勉強した分が成果となって現れてくる可能性が高いです。
Java Developer
Key value 型（KVS）
開発時の様々な制約回避
Google App Engine Microsoft Azure
25

26. Intalio Cloud and Google App Engine
• Global IP addressで接続が可能なIntalio CloudとGoogle App Engineとの接続は可能です（×VPN）。
• Intalio Cloud, Force.com共通のweak point はUIで、UIを自由度が高いGoogle App Engineを利用し、作成
します。
• Google App Engine側にあるBig Tableは検索スピードが速い為、Cache的な役割として考え、外部に公開し
ないデータはIntalio Cloud等のプライベートクラウド側に保存します。
1.簡単に作成
2.公開/非公開データ判別
3.非公開データ移行
Google App Engine Intalio Cloud
From GAE to Intalio Cloud
•Remote API/published Mashup
From Intalio Cloud to GAE
•?
26

27. Intalio Cloud and Google App Engine
• Intalio Cloudからのデータを直接取込む場合、Intalio側の変更により、影響を受ける可能性が高い為、ラ
ッパーを用意する事を推奨します。
• ラッパー内ではIntalio Cloud特有の処理を記述し、Google App Engineの開発者にはIntalio Cloudの構成
等を隠蔽し、詳細を理解しなくとも、実行可能な仕組みを構築する必要があります。
Google App Engine Intalio Cloud
Wrapper programming
1.公開済のMashup
前提条件： 実行時： 2.IN：Mashupのパラメーター
1.UIを用意 1.登録したMashup呼出 3.OUT：Mashupの実行結果
2.Mashup登録 2.実行結果取得
3.同時に、関連情報登録 3.パーサーを利用
4.Entityへ格納
（Reflection未使用）
27

28. Progress
• 実際、構築しましたアプリケーションの話を進めていきます。
• 開発実施期間
• 7月下旬～9月下旬まで
• 週末にコーディング、平日の移動時間にアーキテクチャーの確認・技術調査
• フロント・バック
• フロントは未対応（来年、jQuery等のJavaScriptのフレームワークを利用し作成）
• バックはChannel APIに対応予定（来年に実装予定）
• ソースコード提供・共同開発も視野に入れております。
28

29. Development
• 環境 ローカル
• フレームワーク：Slim3 （http://sites.google.com/site/slim3appengine/）
• OS：Windows7
• IDE：Eclipse 3.5
• Plug-in：Google plug-in
• JDK：1.6
• 環境 Google
• デプロイ先のアプリケーション設定
29

30. Demonstration
• 実行結果
30

31. Demonstration
• 実行結果
31

32. Framework
• Slim3
• Seaser2 チーフコミッターである比嘉さんが作成し、コミッターが増加中
• Google App Engine用のMVCフレームワーク
• 特に、BigTableに対しての処理をラッピングしている点が他にない
• Antを実行し、スケルトン+Unitテストのコードを自動生成
• 学習コストも非常に低く、使いやすい
• 理由：
• SAStruts, S2JDBCを利用した開発経験あり
• BigTableについて詳細に調査する時間がなく、フレームワークを利用する事でデータベース関係を
フレームワークに依存
• 参考書籍：
32

33. Architecture
Front Back
• 一般的なフロー
UI Controller Service Model
• Google App Engine上でのフロー
Meta
UI Controller Service Model
TaskQueue Memcache
Cron
33

34. Notes
• 30秒ルール
• 現象：
Google App Engine上では30秒以内にトランザクションを完了しない場合、タイムアウトが発生
外部のAPIを呼出、ループにて複数の検索を実行する為、30秒以内でトランザクションが
完了しないケースが発生(Google App Engineではスレッド処理は不可)
• 解決策：
上記を解決する方法として、Cacheに実行結果を一時的に格納
格納した結果をTaskQueueより取得し、メール処理を実行
• メール送信数制約
• 現象：
Google App Engine上ではメールを送信する時、1分間に20通のみメールを送信する事が可能
検索結果を1通に1検索結果にした場合、制限オーバーが発生
• 解決策：
メールを送信する際、TaskQueueを利用すると同時に、メールを送信する件数、スリープ時間を
設定し、3秒間に1通のメールが送信できるように制御
34

35. Notes
• 30秒ルール回避方法
①
Request Service BigTable
データ ②
登録
Memcache
②
③ ④
TaskQueue Service API
外部 ⑤
データ ① API
取得
Cron 2minites Memcache
②
③ ④
TaskQueue Service Send mail
メール ① ⑤
送信 BigTable
Cron 1minites
35

36. Notes
• インスタンス数/キュー
• 現象：
ユーザーからのリクエスト後、リクエスト→Queue→Instanceの割当が実施
大量にリクエストすると、1秒以上処理がかかり、インスタンスの上限を超える現象発生
Queueに大量のデータが格納されると、Instanceに割り当てる事ができず、トランザクションの
処理前にタイムアウトが発生
• 解決策：
TaskQueueを利用し、一連の処理を短い時間で処理が可能なアーキテクチャーを考慮
処理を細かく定義し、1秒以上かからない仕組み
1秒以上
Google
Request Queue Instance Transaction
制限 制限
30秒タイムアウト（サーブレットが起動してから）
10秒タイムアウト 30秒タイムアウト
36

37. Notes
• ログ・メールの実行結果
• 現象：
ローカルの環境では、メール送信のテストが不可
System.out.printlnがUnitテスト以外（アプリケーション実行中）では出力されない
• 解決策：
Google App Engine上にデプロイし、テストを実行する必要が発生
Google App Engine上にはテスト・開発用のアプリケーションを作成し、運用しなければ
ならない為、開発者がデプロイする時、気を付けなければならない
• BigTable
• 現象：
Google App Engine上ではRDBではなく、BigTableを利用している為、今までのRDBの知識では
太刀打ちできない
• 解決策：
ISID社が提供するSlim3（=フレームワーク）を利用
BigTableについては英語圏のサイトを参照する事で理解する事が可能
リトルソフト社が提供するBigTableをRDBでラッピングする仕組みを利用
37

38. Notes
• スレッド不可
• シングルスレッドのみ CPUリソース等リソースオーバーを懸念
• ファイル書込不可
• ファイル読込は可能 スケールアウトした場合のファイルの保存先が不明
• ファイルアップロード数と量の制限
• 10M以内/3000ファイルまで
• リクエスト・レスポンスのサイズ制限
• 10M以内
• Javaクラスの制限
• SwingやClassLoader等、JRE標準でサポート（稼働）しない処理が存在
38

39. Strong Point
• バージョン管理
• デプロイした結果が表示され、バージョンを戻す事が可能
39

40. Strong Point
• Cron
• メール処理
• リクエスト作事処理
• ユーザーからのリクエスト処理（API呼出）
• TaskQueue
• 各処理結果を格納
40

41. Strong Point
• Query実行結果の確認
• Model=Entityとなり、レコードの削除等が可能
• API提供(以下を利用)
• Users API（Gmail認証）
• Mail API
• Memcache
• Task Queue
41

42. Strong Point
• ログ確認
• System.out.printlnを出力する事が可能
42

43. Strong Point
• 料金・使用量の確認
• ダッシュボードに現在の使用量が表示
43

44. Roadmap
• フロント
• jQuery取込
• jQueryは実案件では利用した事がない為、かつ情報も多い為、利用予定
• jQTouch（スマートフォン・モバイル向け）
• HTML5取込
• スマートフォンでの利用を考慮
• バック
• ChannelAPI実装
• サーバープッシュ型の機能（Jettyに存在するCometdと同様）
• 新規API追加
• Idea Packetのフロントからのリクエストを処理ができるAPIがあれば、取込予定
44

45. 最後に
• Force.comはチュートリアルは実施しましたが、Apexを新しくマスターする為に、学習コストがかか
る為、詳細な調査は行っておりません。VMForce利用後に再度、調査する予定です。
• Window Azureについては、来年調査する予定です。既に構築するアプリケーションの構想は存在
し、かつWindows7環境に開発環境は、用意できております。参考文献等にて、詳細を確認後、実
施します。是非、参考になるURL等がございましたら、情報交換ができれば、と考えています。
• Cloud環境では、対象ユーザー、要件、期間、コスト等、制約事項が存在する為、今まで以上に
ユーザーから正確に要件の詳細をヒアリングする必要があります。
• つまり、Cloud環境、Cloud以外の環境等、実行環境を含めた要件定義書を作成する事が必須に
なります。
• Twitterからのデータ取得、というConsumer向けのアプリケーションをGoogle App Engine上で開発
した事例は勉強会に参加した時に聞きました。アクセス量が増加した時、料金を支払う事でス
ケールアウトができる点に注目をしている技術者が多いです。
45

46. 本日は、
ありがとうございました
ご質問・リクエストがありましたら、
Intalio Cloud Expertにご連絡をお願いします
mailto: sawada@intalio.com
mailto: sugai@intalio.com
46