• Save
Intalio japan special cloud workshop
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Intalio japan special cloud workshop

on

  • 757 views

 

Statistics

Views

Total Views
757
Views on SlideShare
638
Embed Views
119

Actions

Likes
0
Downloads
0
Comments
0

3 Embeds 119

http://www.johnnydaisuke.info 107
http://www55.jimdo.com 7
http://www13.jimdo.com 5

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Intalio japan special cloud workshop Presentation Transcript

  • 1. Intalio Japan Special Cloud WorkshopVersion 1.0.0Last Changed on: 15.12.2010
  • 2. IndexContents : – 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.commailto: sugai@intalio.com 46