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

IBM Champion が語る
IBM Dominoと
モダン・アーキテク
チャ
九州地区パートナー会
第1回技術発表会 in 鹿児島 2015
2015年5月15日
リコーITソリューションズ株式会社海老原賢次
2015/5/14 Version: [0.1.0] Classification: Internal Owner: [EBIHARA Kenji] 1

自己紹介
 海老原賢次
– リコーITソリューションズ株式会社鹿児島開発部
– システム開発主にWeb系
– 得意なもの
• Domino, XPages, C#, ASP.NET, JavaScript, HTML, CSS, jQuery・・・
– 不得意なもの
• Dojo(w)
– 嫌いなもの
• 冷やしトマト
2015/5/14 2

 プラットフォームを問わず、
昨今トレンドとなっているアーキテクチャを紹介します。
 3,4文字略語やバズワードっぽいものがたくさん出てきます。
 みんな大好きWikipediaからの引用多数でやや手抜き。
 概論ばっかりで具体的な実装例やコードはありません。
（訂正：ほんのちょっとあります）
NO
CODE
はじめに
<code>

資料をslideshareで公開しています
 文字多めのスライドとなっています。
Slideshareで公開していますので、後ほど振り返りでご利用ください。
 http://www.slideshare.net/kenjiebihara71
または
slideshare ebihara kenji 検索

注意！
 今回紹介したモダン・アーキテクチャは、システム設計をする
際の選択肢の1つであり、必ずこれらを採用しなければならな
い、ということではありません。
 Notes/Dominoが決して古いものではなく、最新のアーキ
テクチャに対応できる、ということを知っていただき、且つ開発
者もDominoが変わらない部分だけでなく、Domino外の
技術も取り入れる必要がある、というお話です。

本日のコンテンツ
アーキテクチャのトレンド1
Notes/Domino 25th
変わらないこと、変わってきたこと2
変わらなければならないのは・・・3
新しい時代のDominoアーキテクチャ4

アーキテクチャのトレンド
2015/5/14 7

IoT [Internet of Things]
 IoT [Internet of Things]
– モノのインターネット（Wikipediaより引用）
モノのインターネット（Internet of Things、IoT）は、一意に識別可能な「もの」がインターネット/クラ
ウドに接続され、情報交換することにより相互に制御する仕組みである。
「Internet of Everything」や「Smart Everything」、「サービスのモノ化」ともいう。
(中略)
ここでいう「もの」とは、スマートフォンのようにIPアドレスを持つものや、IPアドレスを持つセンサーから検知
可能なRFIDタグを付けた商品や、IPアドレスを持った機器に格納されたコンテンツのことである。
http://goo.gl/wuaro

IoT [Internet of Things]
 PC以外にも、インターネットに接続してデータを共有する時
代
– スマートフォン、ウェアラブルデバイス、自動車、テレビ、冷蔵庫、靴、荷物
（RFIDタグ）…などなど
– データへのアクセス手段の多様化
→ インターフェースの多様化
UIも様々、UIでないインターフェースも様々
http://goo.gl/wuaro

Github
 アクセス手段は・・・
– PCからWebサイト
– Windows, MacのGithubクライアントアプリ
– スマホ向けWebサイト
– Android, iOS の各Githubアプリ

 ビジネスロジックが、一元化されていること
 一元化されたビジネスロジックへのAPIが公開されていること
– システムがSOAに従って構築されている必要がある。
 クライアント（各デバイス）はUIの機能のみ有していること。
– ビジネスロジックの実行は、クライアントからSOAで構築されたシステムのAPIをコールする。

業務上の一処理に相当するソフトウェアの機能をサービスと見立て、そのサービスをネットワーク上で連携さ
せてシステムの全体を構築していくことを指す言葉である。
業務処理の変化をシステムの変更に素早く反映させたいという需要に応えうるものとして、2004年頃から
IT業界において注目を集めている。
2009年頃からクラウドコンピューティングの台頭とともに、その必要性が再認識されるようになってきている。
SOA（Service-Oriented Architecture）
 SOA（Service-Oriented Architecture）
– サービス指向アーキテクチャ（Wikipediaより引用）
http://goo.gl/wuaro

– 必要条件(1) （Wikipediaより引用）
業務上の一処理に相当する単位でソフトウェアが構成されていること。
SOAにおけるサービスとは、その構成単位のことである。
プログラム上の部品ではなく、たとえば「決済する」「在庫状況を照会する」などの単位で一つのサービスとす
ることが求められる。
どの程度の規模（粒度）を一つのサービスとするのが良いかについては様々な議論がある。
つまり、アプリケーションと言う単位では設計しない。
→今までの、NotesDBという単位で独立せずに、機能としてのインターフェースを独立させる。
http://goo.gl/wuaro

オープンで標準化されている技術仕様を用いてサービスのインタフェースが定義され、それに従った呼び出し、
応答が可能であること。
その技術的基盤として、Webサービスの使用が事実上必須となっている
つまり、RESTful API（後述）でデータにアクセスしたり操作したりする必要がある。
フォームやXPagesで実装したWeb画面からしかアクセスできないのではNG。
http://goo.gl/wuaro

サービスをネットワーク上で連携させてシステムの全体を素早く構築できること。
この段階にいたるまでには、先の二つの条件が必須となる。
さらに、サービスを単位として業務処理の流れを記述する技術や、その記述通りにシステム連携を実行す
る技術も必要となる。
連携に関しては、BPM/BPMN/BPMSなどがそれに当たる。BPMでは、業務を軸とし
て、必要な機能を各システムから呼び出すことが必要となる。
また素早い構築に関しては、柔軟性・拡張性を持ったデータベース→NoSQL の検討
などが必要となる。
http://goo.gl/wuaro

RESTful API
 RESTful API （Wikipediaより引用）
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つの原則がある。

REST APIの原則（１）
 ステートレスであること
–ページを開始して、終了するまでサーバー側でそのページの
情報を持っているのはステートフル。XPagesもこれ。
–リクエストからレスポンスが返るまでで完結。サーバー側で
ページの状態（ステート）を保持しないのがステートレス。
• とはいっても、実際にはログインユーザーの認証状態くらいは
Cookieを用いたセッションで管理するのが普通。

ステートフルとは
客: こんにちは
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ポテトで
店員: ドリンクは何になさいますか?
客: ジンジャーエールで
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: Mでいいです
店員: 以上でよろしいですか?
客: はい
店員: かしこまりました

ステートレスとは
客: こんにちは
店員: いらっしゃいませ。○○バーガーへようこそ
客: ハンバーガーセットをお願いします
店員: サイドメニューは何になさいますか?
客: ハンバーガーセットをポテトでお願いします
店員: ドリンクは何になさいますか?
客: ハンバーガーセットをポテトとジンジャーエールでお願いします
店員: +50円でドリンクをLサイズにできますがいかがですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします
店員: 以上でよろしいですか?
客: ハンバーガーセットをポテトとジンジャーエール(M)でお願いします。以上
店員: かしこまりました

ステートレスのほうがめんどうぢゃないか？
 当たり前ではあるが、人ならステートフルのほうが良い。
 しかし、ステートフルは一人で対応し無くてはならないが、ステートレスはそれぞ
れ店員が違っていても（引き継ぎもしないでも）対応できる。
 リクエストの対応がシンプルなため、サーバー側の負荷が少ないこと、また拡張
性に優れる。

RESTful APIの原則（２）
 CRUDがHTTPのメソッドで定義されている
– HTTPのメソッドには、GET/POST/PUT/DELETE などがある。
– 対象のデータは一意なIDでURLに定義され、操作はメソッドで表現される。
– 例えば、http://******/users/1234
というURLでユーザーID1234へのデータの操作を行うとして、
“GET”メソッドでリクエストすると、ユーザーの情報が返る
“PUT”メソッドでリクエストすると、ユーザー更新が行われる（リクエストに更新
データが必要）
“DELTE”メソッドでリクエストすると、ユーザーの削除が行われる
– http://******/users/ に対して “POST”メソッドでリクエストすると、ユーザーの
新規登録ができる

RESTful APIの原則（２）
– ただし、ブラウザがPUTやDELETEに対応していなかったり
GETでも検索文字列などリクエストで渡すデータが多い場合など、
POSTでリクエストを送ることも多い。
– そのため、メソッドはPOSTだけど、HTTPヘッダの“X-Http-Method-Override”で
本来の目的のメソッドを記述する方法が取られることが多い。
/resource/entities/resource1
Method:POST
Header:X-HTTP-Method-Override=DELETE

RESTful APIの原則（３）（４）
 リソースを一意に識別する「汎用的な構文」
– URIはある決まったリソースを指し示すこと。（例： /user/1234 1234というIDのユーザーを示す）
– なので、URIは動詞ではない。（悪い例： /user/save や /user/1234&action=save）
– URIで示したリソースに対する処理は、HTTPのメソッド（”GET”や”POST”）であること。
 アプリケーションの情報と状態遷移の両方を扱うことができる「ハイ
パーメディアの使用」
– レスポンスは、HTMLやXML、JSONなどの、その他のリソースへのリンクや、そのリソースの状態
を表す値があること。
– まあ、あまり気にしなくていいです。（笑

RESTfulの原則にとらわれすぎない
 ショッピングサイトで、カートに入れてから決済が終わるまでのウィザードのような
ものは、RESTでは難しい。
 RESTの原則を押さえておいて、例外は認めるべきと筆者は考える。

NoSQL
 NoSQL
– または Not only SQL （Wikipediaより引用）
NoSQL（一般に”Not only SQL”と解釈される）とは、リレーショナルデータベース管理システム
(RDBMS) 以外のデータベース管理システムを指すおおまかな分類語である。
リレーショナルデータベースをやみくもに使用してきた長い歴史を打破し、それ以外のデータベースの利用・
発展を促進させようとする運動の標語としての意味合いを持つ。
関係モデルではないデータストアの特徴として、固定されたスキーマに縛られないこと、関係モデルの結合
操作を利用しないこと（場合によっては単にそのような機能が欠落しているだけ）、水平スケーラビリティ
が確保しやすい事が多いこと、トランザクションを利用できないものが多いことなどが挙げられる。
http://goo.gl/jmEV9

NoSQL
 NoSQLの種類（ドキュメントストア形式のみ）（Wikipediaより引用）
http://goo.gl/jmEV9

 Responsive Web Design（RWD）
Webデザインのトレンド
• PC、スマートフォン、タブレットなど画面がサイ
ズが異る物事にページを用意のではなく
CSS, JavaScriptで、
画面サイズを自動的に判断し、
適切なレイアウトに変化させる

 とはいっても、自前で作成するのは非常に困難
 レスポンシブWebデザインに対応したWebデザイン・フレームワークを利用する
のが一般的
レスポンシブWebデザイン
Foundation
http://foundation.zurb.com/
Web Start Kit
https://developers.google.com
/web/starter-kit/
Bootstrap
http://getbootstrap.com/

その他のWebデザインのトレンド
 フラットデザイン
– ボタンなど、現実世界のものをリアルな質感を持つものではなく、平面な単純なデザイン
– 単純なデザインなので作成しやすく、デバイスの表示にコストが掛からない
 カード/タイルデザイン
– 情報の見やすさを優先
– 一覧に比べて、カードごとに情報の内容や量を調整できるなどメリットがある
 ゴーストボタン
– 透明なボタン
– 背景に溶けこんでページの一体感が保てる
 クライアントMV*
– クライアントサイドのMV*クライアント（*は”C”や”VM”などが入る）
– Googleの AnglerJS フレームワークが主流

Notes/Domino 25th 変わらないこと、変わってきたきこと
2015/5/14 30

おめでとう！！
 Notes/Domino25周年！！

変わらないということ
 25年前のDBが最新のDomino9でも動作する！
– 新しいものが正義という風習で過去のものが切り捨てられている事が普通
のこの業界において、これはすばらしいこと。
– そこまで下位互換性に優れたプラットフォームは他に無い
– それだけでも大変価値のあること

しかし・・・
 従来のDBは今の時代に合わないことも確か
 特に外部システムとの連携が困難
– アクセス手段がNotesクライアントが主で、APIとして実装が難しい
• SOAPによるWebサービスは実装できたが、SOAPが流行らなかった・・・
– データ、ビジネスロジック、UIが分離されず、ビジネスロジックの共通化が難しい
• LotusScriptで関数化することである程度できるが、多くのDBはフォームからアクセ
スすることを前提に作られているため、Webサービスから呼び出すことが困難
• 例えば、文書を保存するときのバリデーションがフォームに実装されているため、
Webサービスなど他の手段で文書を保存するときに同じことを書かなくてはならない
 最新のWebやモバイルなど新しいInterfaceにも、すぐに対応できない。

うむー・・・
 UIも変わってない・・・
– メールやカレンダーについては変わってきているが、オリジナルのDBはUIの機能はほぼ変わらず。
– 動的な繰り返しとか・・・動的な他のリソースの埋め込みとか・・・
– Notesクライアントに関してはフォーム、ビューということから離れられない。
– XPagesもそのまま作るだけでは、フォームがWebフォームに変わっただけで、データ、ビジネスロジック、UI
の分離はされない。
 ただし、何も変わってないわけではない

変わってきているということ
 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を提供

Dominoは古くない！
 DominoでIoTやRESTfulのアーキテクチャは実現できないのか
→できる！Dominoは進化している！
 XPagesでレスポンシブWebデザインや、Bootstrapは採用できない？
→できる！
XPagesはオープンソースが元になっているので、
柔軟性が高い！
RESTコントロールも提供されている！

変わらなければならないのは・・・
2015/5/14 37

開発者も変わらなければならない
 Dominoは、最新のトレンド技術を取り込む用意はできてい
る。
 Notes/Domino技術者は、トレンドの技術・アーキテクチャ
を学習し、Dominoに取り込むことで、Dominoの価値をよ
り高めることができる。

古くて新しいDominoにできること
 そうすることで、今まで蓄積したデータを移行することなく、最新のアーキテクチャ、
デバイスでも十分に活用できるようになる。
 新規のシステムにおいても、Notes/Dominoの優れた機能
 25年の実績のあるドキュメントストア型NoSQLデータベース、
ノーコーディングで実現できるコンテンツのアクセスコントロール、
クラスタ、レプリカによる拡張性、
カテゴライズのビュー表示、などなど・・・

を利用しつつ、最新のWeb UIやIoTに対応したシステムが実現できる！

新しい時代のDominoアーキテクチャ
2015/5/14 40

Domino/XPages モダン・アーキテクチャ・マップ
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

まだまだ他にもキーワードが・・・
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

XPagesを利用したモダン・アーキテクチャの例
 XPagesのRESTコントロールを使用した、データ、ビジネスロジック、UIの分離
[ビジネスロジック]
XPagesでREST APIを定義
文書は持たない
DMZ
[Data]
文書を管理するのみ
ロジックはない
[UI]静的なHTML
動的な処理はCS JavaScriptで行う
REST APIで”GET” or ”POST”
CSS
JS
HTML
スマホ専用
アプリ
他システム

Domino Data Service
 Domino 8.5.3 UP1 から使用可能。
 設定だけで、既存のビューや文書をRESTで公開できる。
 使用方法は、IBM Champion の御代さんのページが詳しいです。
 http://guylocke.blogspot.jp/2013/06/notesdomino-rest-
api.html

XPages REST コントロール DEMO
特徴
• 静的なXPages
• RESTコントロールでのデータの操作
• Bootstrapによるデザイオ
• jQueryライブラリでのカレンダー表示・操作
• 複数DBの操作

デモの作成動画を近日公開！
 多分ここで配信します。
 あとブログでも -> http://take-the-xpages.blogspot.jp/
「XPagesで行こう！」で検索！

XPages REST コントロール
GET メソッドの処理を記載
JSON（プレーンテキスト）を返す
任意に、戻りの形を返したり、処理を行ったりする場合は
XPagesの Extension Library の「RESTサービス」を利用

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

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

Recomendados

Recomendados

Mais conteúdo relacionado

Mais de 賢次海老原

Mais de 賢次海老原 (8)

Último

Último (7)