Intalio japan special cloud workshop

886 views

Published on

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Intalio japan special cloud workshop

  1. 1. Intalio Japan Special Cloud WorkshopVersion 1.0.0Last Changed on: 15.12.2010
  2. 2. IndexContents : – Object-genについて – Google App Engine For Javaについて
  3. 3. Workshopを始める前に本資料は、Intalioの製品以外の話に重点を置いており、かつ完全に技術的な話になります。 3
  4. 4. Object-genについて
  5. 5. Why?• 今回お話をする内容は、MKI様より以下のリクエストがPOC実施時にありました。 • Object Builderを利用し、テーブル定義がほぼ同一のアプリケーションを構築する場合、毎 回同じ属性を入力しなくともよい仕組み• 当時の実現方法としては、以下の通りでした。大規模のシステム構築では一般的です。• 現在のステータスは、開発側は1年間何も進展がない為、廃止されております。 1.設計書作成 ユーザー Excel SQL文 2.マクロ実行 3.手動でコピー Intalio Cloud 5
  6. 6. Weak Point• Object Builderに対する改善は、以下の通りになります。 • プレビュー画面がない • 設定する項目が多いと時間がかかる • Object Builder全体の機能が不明 • 不要な共通項目を毎回、削除せず、自ら定義したい • テンプレートとなる設計書が存在しない • 一度作成したObjectのコピーができない• 開発側に要望を出していますが、実現するか否か不明です。• 設計書→画面の自動作成の仕組みは、既に他社製品では実現済になります。• 開発側の対応が待つ=ビジネスに取り残される事になり、どのようにすればよいか? 6
  7. 7. Resolution• 開発者が開発時に何をするのか、という視点で、日本側がWeak Pointを解消するツール作成 • Cloud環境にデプロイする前に、プレビュー画面で確認 • システム開発は特定の人が全てを決定するのではなく、ユーザーが自らシステム開発に参 加が可能なツールを提供 • ユーザーが対応できない詳細なデータベース設計等はシステム開発者が対応 • 設計書→ソースコードの自動化を実現し、開発コストを削減 • 自社のテンプレートとなる仕組みの提供 • 将来、ソースコード→設計書の仕組みも考慮• プログラミング言語はVBA, ExtJS, Rubyというメジャーな言語を利用し、将来は誰もが改良できる 構成を考慮(英語版への対応はなし)しています。• ユーザーがシステム開発に参加する場合、以下の点のみ理解すればよい、と考えています。 • 表示したい項目は何か? • 画面に表示する項目の配置は? • 一覧画面に表示する項目は? 7
  8. 8. Overview 1.設計書作成 2.マクロ実行ユーザー ExtJS Excel プレビュー *シュミレーション 3.提供 同一ファイル Ruby Intalio Excel XSPファイル Cloud SI 4.マクロ実行 6.スクリプト 5.設計書追加 実行 8
  9. 9. Overview• 設計書の構成は、以下の通りです。 • 画面に表示する項目 • 画面に表示する項目の詳細 • オプションリスト等に定義する項目の設定 • リレーションシップの設定 • 画面に表示する項目の配置 • 高度検索・一括更新画面の作成と定義 • 一覧画面に表示する項目とルール • ボタンバーに表示する項目 • アコーディオンバーに表示する項目 • システム共通にて使用する項目・画面の設定変更• システム開発者はExcelのシートを再表示する事で上記の項目の参照が可能です。• ユーザーとのヒアリング時・ユーザーに提供して記述する等、どちらも対応が可能です。 9
  10. 10. Demonstration• ユーザーが画面に表示する項目を定義 10
  11. 11. Demonstration• システム管理者が設定する項目を定義 11
  12. 12. Demonstration• ユーザーが画面に表示したい位置を定義 12
  13. 13. Demonstration• ユーザーが一覧画面に表示したい項目を定義 13
  14. 14. Demonstration• プレビュー画面を表示 14
  15. 15. Demonstration• システム管理者が自社用にテンプレートを作成 15
  16. 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. 17. Google App Engine For Javaについて
  18. 18. Google App Engine• WebアプリケーションをGoogleのインフラ上に作成する事が可能• Googleがインフラの構築、維持、管理等を行い為、インフラの知識は不要• PythonとJavaが現在はサポート(JVMで稼働するJruby, Scala, Groovyも稼働)• Googleに登録した後、無料で利用する事が可能(一定の基準以内) SI ユーザー Google 18
  19. 19. Why?• これから説明しますアプリケーション「Idea Packet(アイディアパケット)」は、三重県へ出張中にコンセプト をまとめました。 • 単純なパターン化した仕事のシステム化 • 自分専用のコピーロボットを作成し、インターネット経由でアクセス• 業務フローを可視化する為に、マジカ!を利用し、記述し、当時、スターロジック(現在、マジカジャパン) を訪問した際、羽生様・可世木様にマジカ!の利用方法を確認しました。 • 全体のフローの問題点はなし• 当時、レンタルサーバーと契約しており、レンタルサーバー上での稼働を考慮したが、無料でアプリケー ションをデプロイが可能な環境(=Cloud)が存在する事を発見しました。 Personal 知らない言葉 メールで送信 Googleで検索 知らない単語 後で確認 Team, Group メールで送信 後で確認 19
  20. 20. What is Magica?• 実際に記述しましたマジカ!のシートを本日は持ってきております。• UMLでお客様と打合せをした結果を記述する事は可能ですが、お客様に渡す時、お客様側にUMLの知 識が求められます。BPMNについても、同様です。学習コストを最小限にし、お客様が理解できるツール、 現時点ではマジカ!が一番上記の条件を満たしていると考えております。• 最近はお客様がシステム開発に自ら参加したい、という傾向は強いです。しかし、お客様が参加できる場 所は現状では打合せのみ、設計書等のレビューのみ、というケースが多いと思います。お客様自身が参 加できる為のツール、Object-genについても同様のコンセプトで考えております。 • 楽ができる所は楽をする • 委譲できる所は委譲する • ヒアリングでの対応を減らす• 入力と記述、両方を比較した時、記述した方が印象が残っており、思い出しやすい、という事もあります。 20
  21. 21. Requirement• 自分の行動を考慮すると、以下のAPIが必要であると判断しました。 • Google • Yahoo • Amazon • 楽天 • Twitter (Public Timelineではなく、絞り込みが必須) • YouTube (未対応) ユーザー Application GoogleAPI メールで送信 YahooAPI メールで送信 Request 選択可能 AmazonAPI メールで送信 楽天API メールで送信 21
  22. 22. Comparison• 以下の図は、当時調査した各Cloudの調査結果です。• サポートは一切使用せず、無料で構築するという観点から判断しています。• 結論として、Google App Engineが調査時点では一番良く、かつTwitterを利用する事で有志の方々に質 問も可能である点も考慮しました(実際は、自力で解決)。 Stax.net Force.com Google App Engine 参考文献(書籍は全てなし) ×(Wiki) ○ ○ メーリングリスト/ブログでの状況 × △ ○ アプリケーション構築への知識 DB △ ○ ×(BigTable) アプリケーション構築への知識 アプリ ○ ×(Apex) ○ 管理コンソール関連 △ △ ○ 開発ツールの提供 ×(コマンド) ○ ○ Cloud環境への申請時間 ×(遅い) ○ △(面倒) Cloud環境へのデプロイ △(コマンド) ○(Eclipse) ○(Eclipse) 22
  23. 23. Public Cloud Development Strong Point• Cloudでアプリケーションを開発する場合、開発に向いているアプリケーション・向 かないアプリケーションが存在する事は理解していますか?• 向いているアプリケーション • 開発者が5人以下のシステム(1人でも可能) • 簡単, コスト安, 短期間で作成するシステム(→将来は大きく育てる) • ユーザーの意向<開発の意向、であるアプリケーション(レスポンスタイム等の制約)• 向いていないアプリケーション • レガシーシステム • バッチプログラム(ネットワークへの負荷) • RDBで作成したアプリケーションのリプレース(Key-Value型) • 開発者が5人以上になるシステム • 集計・フィルター等がSQL文で簡単に実行できない為、リアルタイムで集計処理が多いシステム(開 発工数は、通常のアプリケーション以上にコストがかかる) 23
  24. 24. New Development Style Service• 初期費用0円、月々15万円というプランでサービスを構築する会社が存在し、注目されています。• 対象範囲は、ExcelやAccessで利用しているシステムの置換えを焦点にしております。 24
  25. 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. 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. 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. 28. Progress• 実際、構築しましたアプリケーションの話を進めていきます。• 開発実施期間 • 7月下旬~9月下旬まで • 週末にコーディング、平日の移動時間にアーキテクチャーの確認・技術調査• フロント・バック • フロントは未対応(来年、jQuery等のJavaScriptのフレームワークを利用し作成) • バックはChannel APIに対応予定(来年に実装予定)• ソースコード提供・共同開発も視野に入れております。 28
  29. 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. 30. Demonstration• 実行結果 30
  31. 31. Demonstration• 実行結果 31
  32. 32. Framework• Slim3 • Seaser2 チーフコミッターである比嘉さんが作成し、コミッターが増加中 • Google App Engine用のMVCフレームワーク • 特に、BigTableに対しての処理をラッピングしている点が他にない • Antを実行し、スケルトン+Unitテストのコードを自動生成 • 学習コストも非常に低く、使いやすい• 理由: • SAStruts, S2JDBCを利用した開発経験あり • BigTableについて詳細に調査する時間がなく、フレームワークを利用する事でデータベース関係を フレームワークに依存• 参考書籍: 32
  33. 33. Architecture Front Back• 一般的なフロー UI Controller Service Model• Google App Engine上でのフロー Meta UI Controller Service Model TaskQueue Memcache Cron 33
  34. 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. 35. Notes• 30秒ルール回避方法 ① Request Service BigTableデータ ②登録 Memcache ② ③ ④ TaskQueue Service API外部 ⑤データ ① API取得 Cron 2minites Memcache ② ③ ④ TaskQueue Service Send mailメール ① ⑤送信 BigTable Cron 1minites 35
  36. 36. Notes• インスタンス数/キュー • 現象: ユーザーからのリクエスト後、リクエスト→Queue→Instanceの割当が実施 大量にリクエストすると、1秒以上処理がかかり、インスタンスの上限を超える現象発生 Queueに大量のデータが格納されると、Instanceに割り当てる事ができず、トランザクションの 処理前にタイムアウトが発生 • 解決策: TaskQueueを利用し、一連の処理を短い時間で処理が可能なアーキテクチャーを考慮 処理を細かく定義し、1秒以上かからない仕組み 1秒以上 Google Request Queue Instance Transaction 制限 制限 30秒タイムアウト(サーブレットが起動してから) 10秒タイムアウト 30秒タイムアウト 36
  37. 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. 38. Notes• スレッド不可 • シングルスレッドのみ CPUリソース等リソースオーバーを懸念• ファイル書込不可 • ファイル読込は可能 スケールアウトした場合のファイルの保存先が不明• ファイルアップロード数と量の制限 • 10M以内/3000ファイルまで• リクエスト・レスポンスのサイズ制限 • 10M以内• Javaクラスの制限 • SwingやClassLoader等、JRE標準でサポート(稼働)しない処理が存在 38
  39. 39. Strong Point• バージョン管理 • デプロイした結果が表示され、バージョンを戻す事が可能 39
  40. 40. Strong Point• Cron • メール処理 • リクエスト作事処理 • ユーザーからのリクエスト処理(API呼出)• TaskQueue • 各処理結果を格納 40
  41. 41. Strong Point• Query実行結果の確認 • Model=Entityとなり、レコードの削除等が可能• API提供(以下を利用) • Users API(Gmail認証) • Mail API • Memcache • Task Queue 41
  42. 42. Strong Point• ログ確認 • System.out.printlnを出力する事が可能 42
  43. 43. Strong Point• 料金・使用量の確認 • ダッシュボードに現在の使用量が表示 43
  44. 44. Roadmap• フロント • jQuery取込 • jQueryは実案件では利用した事がない為、かつ情報も多い為、利用予定 • jQTouch(スマートフォン・モバイル向け) • HTML5取込 • スマートフォンでの利用を考慮• バック • ChannelAPI実装 • サーバープッシュ型の機能(Jettyに存在するCometdと同様) • 新規API追加 • Idea Packetのフロントからのリクエストを処理ができるAPIがあれば、取込予定 44
  45. 45. 最後に• Force.comはチュートリアルは実施しましたが、Apexを新しくマスターする為に、学習コストがかか る為、詳細な調査は行っておりません。VMForce利用後に再度、調査する予定です。• Window Azureについては、来年調査する予定です。既に構築するアプリケーションの構想は存在 し、かつWindows7環境に開発環境は、用意できております。参考文献等にて、詳細を確認後、実 施します。是非、参考になるURL等がございましたら、情報交換ができれば、と考えています。• Cloud環境では、対象ユーザー、要件、期間、コスト等、制約事項が存在する為、今まで以上に ユーザーから正確に要件の詳細をヒアリングする必要があります。• つまり、Cloud環境、Cloud以外の環境等、実行環境を含めた要件定義書を作成する事が必須に なります。• Twitterからのデータ取得、というConsumer向けのアプリケーションをGoogle App Engine上で開発 した事例は勉強会に参加した時に聞きました。アクセス量が増加した時、料金を支払う事でス ケールアウトができる点に注目をしている技術者が多いです。 45
  46. 46. 本日は、 ありがとうございましたご質問・リクエストがありましたら、Intalio Cloud Expertにご連絡をお願いしますmailto: sawada@intalio.commailto: sugai@intalio.com 46

×