Your SlideShare is downloading. ×
IBM Dominoとモダンアーキテクチャ
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

IBM Dominoとモダンアーキテクチャ

105

Published on

IT・システムのトレンドは常に変化していっています。特に最近はではIoTに代表されるように、場所・モノを問わず …

IT・システムのトレンドは常に変化していっています。特に最近はではIoTに代表されるように、場所・モノを問わず
   システムにアクセスできる事が多く求められます。そうしたトレンドにおいて、Domino・XPagesでどのように対応するべきか、
   技術者として何を目指すべきなのか、といったことなどをお話します。

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total Views
105
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
4
Comments
0
Likes
1
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. IBM Champion が語る IBM Dominoと モダン・アーキテク チャ 九州地区パートナー会 第1回技術発表会 in 鹿児島 2015 2015年5月15日 リコーITソリューションズ株式会社 海老原 賢次 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 1
  • 2. 自己紹介  海老原 賢次 – リコーITソリューションズ株式会社 鹿児島開発部 – システム開発 主にWeb系 – 得意なもの • Domino, XPages, C#, ASP.NET, JavaScript, HTML, CSS, jQuery・・・ – 不得意なもの • Dojo(w) – 嫌いなもの • 冷やしトマト 2015/5/14 2
  • 3.  プラットフォームを問わず、 昨今トレンドとなっているアーキテクチャを紹介します。  3,4文字略語やバズワードっぽいものがたくさん出てきます。  みんな大好きWikipediaからの引用多数でやや手抜き。  概論ばっかりで具体的な実装例やコードはありません。 (訂正:ほんのちょっとあります) NO CODE はじめに 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 3 <code>
  • 4. 資料をslideshareで公開しています  文字多めのスライドとなっています。 Slideshareで公開していますので、後ほど振り返りでご利用ください。  http://www.slideshare.net/kenjiebihara71 または 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 4 slideshare ebihara kenji 検索
  • 5. 注意!  今回紹介したモダン・アーキテクチャは、システム設計をする 際の選択肢の1つであり、必ずこれらを採用しなければならな い、ということではありません。  Notes/Dominoが決して古いものではなく、最新のアーキ テクチャに対応できる、ということを知っていただき、且つ開発 者もDominoが変わらない部分だけでなく、Domino外の 技術も取り入れる必要がある、というお話です。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 5
  • 6. 本日のコンテンツ 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 6 アーキテクチャのトレンド1 Notes/Domino 25th 変わらないこと、変わってきたこと2 変わらなければならないのは・・・3 新しい時代のDominoアーキテクチャ4
  • 7. アーキテクチャのトレンド 2015/5/14 7
  • 8. IoT [Internet of Things]  IoT [Internet of Things] – モノのインターネット(Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 8 モノのインターネット(Internet of Things、IoT)は、一意に識別可能な「もの」がインターネット/クラ ウドに接続され、情報交換することにより相互に制御する仕組みである。 「Internet of Everything」や「Smart Everything」、「サービスのモノ化」ともいう。 (中略) ここでいう「もの」とは、スマートフォンのようにIPアドレスを持つものや、IPアドレスを持つセンサーから検知 可能なRFIDタグを付けた商品や、IPアドレスを持った機器に格納されたコンテンツのことである。 http://goo.gl/wuaro
  • 9. IoT [Internet of Things]  PC以外にも、インターネットに接続してデータを共有する時 代 – スマートフォン、ウェアラブルデバイス、自動車、テレビ、冷蔵庫、靴、荷物 (RFIDタグ)…などなど – データへのアクセス手段の多様化 → インターフェースの多様化 UIも様々、UIでないインターフェースも様々 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 9 http://goo.gl/wuaro
  • 10. Github  アクセス手段は・・・ – PCからWebサイト – Windows, MacのGithubクライアントアプリ – スマホ向けWebサイト – Android, iOS の各Githubアプリ 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 10
  • 11.  ビジネスロジックが、一元化されていること  一元化されたビジネスロジックへのAPIが公開されていること – システムがSOAに従って構築されている必要がある。  クライアント(各デバイス)はUIの機能のみ有していること。 – ビジネスロジックの実行は、クライアントからSOAで構築されたシステムのAPIをコールする。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 11
  • 12. 業務上の一処理に相当するソフトウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携さ せてシステムの全体を構築していくことを指す言葉である。 業務処理の変化をシステムの変更に素早く反映させたいという需要に応えうるものとして、2004年頃から IT業界において注目を集めている。 2009年頃からクラウドコンピューティングの台頭とともに、その必要性が再認識されるようになってきている。 SOA(Service-Oriented Architecture)  SOA(Service-Oriented Architecture) – サービス指向アーキテクチャ (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 12 http://goo.gl/wuaro
  • 13. SOA(Service-Oriented Architecture)  SOA(Service-Oriented Architecture) – 必要条件(1) (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 13 業務上の一処理に相当する単位でソフトウェアが構成されていること。 SOAにおけるサービスとは、その構成単位のことである。 プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会する」などの単位で一つのサービスとす ることが求められる。 どの程度の規模(粒度)を一つのサービスとするのが良いかについては様々な議論がある。 つまり、アプリケーションと言う単位では設計しない。 →今までの、NotesDBという単位で独立せずに、機能としてのインターフェースを独立させる。 http://goo.gl/wuaro
  • 14. SOA(Service-Oriented Architecture)  SOA(Service-Oriented Architecture) – 必要条件(2) (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 14 オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従った呼び出し、 応答が可能であること。 その技術的基盤として、Webサービスの使用が事実上必須となっている つまり、RESTful API(後述)でデータにアクセスしたり操作したりする必要がある。 フォームやXPagesで実装したWeb画面からしかアクセスできないのではNG。 http://goo.gl/wuaro
  • 15. SOA(Service-Oriented Architecture)  SOA(Service-Oriented Architecture) – 必要条件(3) (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 15 サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。 この段階にいたるまでには、先の二つの条件が必須となる。 さらに、サービスを単位として業務処理の流れを記述する技術や、その記述通りにシステム連携を実行す る技術も必要となる。 連携に関しては、BPM/BPMN/BPMSなどがそれに当たる。BPMでは、業務を軸とし て、必要な機能を各システムから呼び出すことが必要となる。 また素早い構築に関しては、柔軟性・拡張性を持ったデータベース→NoSQL の検討 などが必要となる。 http://goo.gl/wuaro
  • 16. RESTful API  RESTful API (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 16 RESTは、初めはアーキテクチャの原則と制約の集まり(後述)を指していたが、次第に、XMLやHTTPを 使った簡易なウェブベースのインターフェイスのうち、WebサービスのSOAPプロトコルのような MEP (Message Exchange Pattern; SOAPノード相互のメッセージ交換のパターンを確立するための雛 型)ベースの特別な抽象化をしないもののことを、大まかに意味する用語として使われるようになった。 RESTは次に述べるように2つのやや異なる意味で使われている。 • FieldingのRESTアーキテクチャスタイルの原則に合わせたWebサービスシステム。 • RPCスタイルに合わせた簡易な XML+HTTP インターフェイスを採用したシステム(SOAPは使わな い) 。 http://goo.gl/TPLc9 要約:SOAPに比べて軽量な(決まり事が少ない)Webサービス。シンプル命。 RESTには4つの原則がある。
  • 17. REST APIの原則(1)  ステートレスであること –ページを開始して、終了するまでサーバー側でそのページの 情報を持っているのはステートフル。XPagesもこれ。 –リクエストからレスポンスが返るまでで完結。サーバー側で ページの状態(ステート)を保持しないのがステートレス。 • とはいっても、実際にはログインユーザーの認証状態くらいは Cookieを用いたセッションで管理するのが普通。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 17
  • 18. ステートフルとは 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ポテトで 店員: ドリンクは何になさいますか? 客: ジンジャーエールで 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: Mでいいです 店員: 以上でよろしいですか? 客: はい 店員: かしこまりました 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 18
  • 19. ステートレスとは 客: こんにちは 店員: いらっしゃいませ。○○バーガーへようこそ 客: ハンバーガーセットをお願いします 店員: サイドメニューは何になさいますか? 客: ハンバーガーセットをポテトでお願いします 店員: ドリンクは何になさいますか? 客: ハンバーガーセットをポテトとジンジャーエールでお願いします 店員: +50円でドリンクをLサイズにできますがいかがですか? 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします 店員: 以上でよろしいですか? 客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上 店員: かしこまりました 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 19
  • 20. ステートレスのほうがめんどうぢゃないか?  当たり前ではあるが、人ならステートフルのほうが良い。  しかし、ステートフルは一人で対応し無くてはならないが、ステートレスはそれぞ れ店員が違っていても(引き継ぎもしないでも)対応できる。  リクエストの対応がシンプルなため、サーバー側の負荷が少ないこと、また拡張 性に優れる。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 20
  • 21. RESTful APIの原則(2)  CRUDがHTTPのメソッドで定義されている – HTTPのメソッドには、GET/POST/PUT/DELETE などがある。 – 対象のデータは一意なIDでURLに定義され、操作はメソッドで表現される。 – 例えば、http://******/users/1234 というURLでユーザーID1234へのデータの操作を行うとして、 “GET”メソッドでリクエストすると、ユーザーの情報が返る “PUT”メソッドでリクエストすると、ユーザー更新が行われる(リクエストに更新 データが必要) “DELTE”メソッドでリクエストすると、ユーザーの削除が行われる – http://******/users/ に対して “POST”メソッドでリクエストすると、ユーザーの 新規登録ができる 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 21
  • 22. RESTful APIの原則(2) – ただし、ブラウザがPUTやDELETEに対応していなかったり GETでも検索文字列などリクエストで渡すデータが多い場合など、 POSTでリクエストを送ることも多い。 – そのため、メソッドはPOSTだけど、HTTPヘッダの“X-Http-Method-Override”で 本来の目的のメソッドを記述する方法が取られることが多い。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 22 /resource/entities/resource1 Method:POST Header:X-HTTP-Method-Override=DELETE
  • 23. RESTful APIの原則(3)(4)  リソースを一意に識別する「汎用的な構文」 – URIはある決まったリソースを指し示すこと。(例: /user/1234 1234というIDのユーザーを示す) – なので、URIは動詞ではない。(悪い例: /user/save や /user/1234&action=save) – URIで示したリソースに対する処理は、HTTPのメソッド(”GET”や”POST”)であること。  アプリケーションの情報と状態遷移の両方を扱うことができる「ハイ パーメディアの使用」 – レスポンスは、HTMLやXML、JSONなどの、その他のリソースへのリンクや、そのリソースの状態 を表す値があること。 – まあ、あまり気にしなくていいです。(笑 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 23
  • 24. RESTfulの原則にとらわれすぎない  ショッピングサイトで、カートに入れてから決済が終わるまでのウィザードのような ものは、RESTでは難しい。  RESTの原則を押さえておいて、例外は認めるべきと筆者は考える。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 24
  • 25. NoSQL  NoSQL – または Not only SQL (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 25 NoSQL(一般に”Not only SQL”と解釈される)とは、リレーショナルデータベース管理システム (RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。 リレーショナルデータベースをやみくもに使用してきた長い歴史を打破し、それ以外のデータベースの利用・ 発展を促進させようとする運動の標語としての意味合いを持つ。 関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合 操作を利用しないこと(場合によっては単にそのような機能が欠落しているだけ)、水平スケーラビリティ が確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。 http://goo.gl/jmEV9
  • 26. NoSQL  NoSQLの種類(ドキュメントストア形式のみ) (Wikipediaより引用) 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 26 http://goo.gl/jmEV9
  • 27.  Responsive Web Design(RWD) Webデザインのトレンド 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 27 • PC、スマートフォン、タブレットなど画面がサイ ズが異る物事にページを用意のではなく CSS, JavaScriptで、 画面サイズを自動的に判断し、 適切なレイアウトに変化させる
  • 28.  とはいっても、自前で作成するのは非常に困難  レスポンシブWebデザインに対応したWebデザイン・フレームワークを利用する のが一般的 レスポンシブWebデザイン 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 28 Foundation http://foundation.zurb.com/ Web Start Kit https://developers.google.com /web/starter-kit/ Bootstrap http://getbootstrap.com/
  • 29. その他のWebデザインのトレンド  フラットデザイン – ボタンなど、現実世界のものをリアルな質感を持つものではなく、平面な単純なデザイン – 単純なデザインなので作成しやすく、デバイスの表示にコストが掛からない  カード/タイルデザイン – 情報の見やすさを優先 – 一覧に比べて、カードごとに情報の内容や量を調整できるなどメリットがある  ゴーストボタン – 透明なボタン – 背景に溶けこんでページの一体感が保てる  クライアントMV* – クライアントサイドのMV*クライアント(*は”C”や”VM”などが入る ) – Googleの AnglerJS フレームワークが主流 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 29
  • 30. Notes/Domino 25th 変わらないこと、変わってきたきこと 2015/5/14 30
  • 31. おめでとう!!  Notes/Domino25周年!! 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 31
  • 32. 変わらないということ  25年前のDBが最新のDomino9でも動作する! – 新しいものが正義という風習で過去のものが切り捨てられている事が普通 のこの業界において、これはすばらしいこと。 – そこまで下位互換性に優れたプラットフォームは他に無い – それだけでも大変価値のあること 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 32
  • 33. しかし・・・  従来のDBは今の時代に合わないことも確か  特に外部システムとの連携が困難 – アクセス手段がNotesクライアントが主で、APIとして実装が難しい • SOAPによるWebサービスは実装できたが、SOAPが流行らなかった・・・ – データ、ビジネスロジック、UIが分離されず、ビジネスロジックの共通化が難しい • LotusScriptで関数化することである程度できるが、多くのDBはフォームからアクセ スすることを前提に作られているため、Webサービスから呼び出すことが困難 • 例えば、文書を保存するときのバリデーションがフォームに実装されているため、 Webサービスなど他の手段で文書を保存するときに同じことを書かなくてはならない  最新のWebやモバイルなど新しいInterfaceにも、すぐに対応できない。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 33
  • 34. うむー・・・  UIも変わってない・・・ – メールやカレンダーについては変わってきているが、オリジナルのDBはUIの機能はほぼ変わらず。 – 動的な繰り返しとか・・・動的な他のリソースの埋め込みとか・・・ – Notesクライアントに関してはフォーム、ビューということから離れられない。 – XPagesもそのまま作るだけでは、フォームがWebフォームに変わっただけで、データ、ビジネスロジック、UI の分離はされない。  ただし、何も変わってないわけではない 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 34
  • 35. 変わってきているということ  Dominoは、常にトレンドを取り込んできた。 – 1989年 Lotus Notes 初版リリース – 1996年 4.5: Lotus Domino リリース Java、Web標準プロトコルの採用 – 2002年 6.0: iNotes Web Access がリリース LDAP採用 – 2005年 7.0: Domino Server 拡充 WebSphere連携、分散、クラスタ機能が大幅に向上 – 2009年 8.5: XPages登場! – 2013年 9.0: ソーシャル連携機能追加 Extension Library 標準搭載 Domino Access ServicesによるREST APIを提供 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 35
  • 36. Dominoは古くない!  DominoでIoTやRESTfulのアーキテクチャは実現できないのか →できる!Dominoは進化している!  XPagesでレスポンシブWebデザインや、Bootstrapは採用できない? →できる! XPagesはオープンソースが元になっているので、 柔軟性が高い! RESTコントロールも提供されている! 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 36
  • 37. 変わらなければならないのは・・・ 2015/5/14 37
  • 38. 開発者も変わらなければならない  Dominoは、最新のトレンド技術を取り込む用意はできてい る。  Notes/Domino技術者は、トレンドの技術・アーキテクチャ を学習し、Dominoに取り込むことで、Dominoの価値をよ り高めることができる。 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 38
  • 39. 古くて新しいDominoにできること  そうすることで、今まで蓄積したデータを移行することなく、最新のアーキテクチャ、 デバイスでも十分に活用できるようになる。  新規のシステムにおいても、Notes/Dominoの優れた機能  25年の実績のあるドキュメントストア型NoSQLデータベース、 ノーコーディングで実現できるコンテンツのアクセスコントロール、 クラスタ、レプリカによる拡張性、 カテゴライズのビュー表示、などなど・・・  を利用しつつ、最新のWeb UIやIoTに対応したシステムが実現できる! 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 39
  • 40. 新しい時代のDominoアーキテクチャ 2015/5/14 40
  • 41. Domino/XPages モダン・アーキテクチャ・マップ 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 41 IBM Domino Form View XPages JavaScript framework Dojo jQuery AngularJS Backbone.js HTTP RESTful API JavaScript HTML5CSS3 基礎技術 OSS framework Web Design framework Bootstrap Foundation Web Starter Kit Kendo UI
  • 42. まだまだ他にもキーワードが・・・ 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 42 IBM Domino Form View XPages JavaScript framework Dojo jQuery AngularJS Backbone.js HTTP RESTful API JavaScript HTML5CSS3 基礎技術 OSS framework Web Design framework Bootstrap Foundation Web Starter Kit Kendo UI
  • 43. XPagesを利用したモダン・アーキテクチャの例  XPagesのRESTコントロールを使用した、データ、ビジネスロジック、UIの分離 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 43 [ビジネスロジック] XPagesでREST APIを定義 文書は持たない DMZ [Data] 文書を管理するのみ ロジックはない [UI]静的なHTML 動的な処理はCS JavaScriptで行う REST APIで”GET” or ”POST” CSS JS HTML スマホ専用 アプリ 他システム
  • 44. Domino Data Service  Domino 8.5.3 UP1 から使用可能。  設定だけで、既存のビューや文書をRESTで公開できる。  使用方法は、IBM Champion の御代さんのページが詳しいです。  http://guylocke.blogspot.jp/2013/06/notesdomino-rest- api.html 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 44
  • 45. XPages REST コントロール DEMO 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 45 特徴 • 静的なXPages • RESTコントロールでのデータの操作 • Bootstrapによるデザイオ • jQueryライブラリでのカレンダー表示・操作 • 複数DBの操作
  • 46. デモの作成動画を近日公開!  多分ここで配信します。  あとブログでも -> http://take-the-xpages.blogspot.jp/ 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 46 「XPagesで行こう!」で検索!
  • 47. XPages REST コントロール 2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 47 GET メソッドの処理を記載 JSON(プレーンテキスト)を返す 任意に、戻りの形を返したり、処理を行ったりする場合は XPagesの Extension Library の「RESTサービス」を利用

×