P1 このスライドではHyper Layering Architectureの再生、いわばHyper Layering Architecture 2.0の原動力となった、Layers as Web Appsについて、その深淵を探求しそこに隠された新たなコンピューティングのパラダイムを紐解いていきたいと思います。 P2 先のデモでご紹介したsvgmapjsフレームワークによる標準的な画面と、Layers as Web Appsの関係をこのスライドでは紹介します。 P2-1 地図の部分は言うまでもなく、たくさんのレイヤーが共有しているキャンバスであり、ここでレイヤリングされます。 まず画面左のリストボックスに、レイヤー群へのハイパーリンクが表示されています。 P2-2 このリストからユーザが見たいレイヤーを選択すると、そのレイヤーに対応するウェブアプリ、Layers as Web Appsが右のframeのボックスで起動します。 （余計かも：もしも別のレイヤーを選択したら、その別のレイヤーに対応するウェブアプリが起動され右に乗っかっていきます。レイヤリングされている数だけ複数のウェブアプリが同時に起動するわけです。表示されているレイヤーのリストには、ウェブアプリを再表示するためのボタンが付いています。） P2-3 このLayers as Web Appsは、そのサービス独自のデータをサーバから受信し、これをsvgmapjsフレームワークが表示できるDOMの形式に変換して共通キャンバスに表示します。 さて、ここでWebGISにはいくつかの標準形式たとえばWMS、WFS、ウェブメルカトルタイルなど、標準的なフォーマットやプロトコルがあることをご存じの方もいらっしゃるでしょう。しかしそれでもLayers as Web Appsは必要です。なぜなら、そのサービス独自のコンテキスト例えば天気分布予報サービスであれば、予報時刻や自動更新の設定などをエンドユーザと対話しながら設定したうえで、はじめてこれらの標準プロトコルで地図データを取得する必要があるからです。すなわちいくらこのようなGeo業界の標準があっても、独自のUIとアプリケーションロジックは、一般に不可欠であると宇うことでで。これを支えるのがLayers as Web Appsです。 P3 次にHyper Layering Architecture2.0、Layers as Web Appsと、Webサービスのモダンなデザインパターンとの対比をしてみましょう。 P4 Layers as Web Appsの振る舞いをおさらいしてみます。 クライアント上のフレームワークが、小さなウェブアプリを読み込み、プラグインして起動、ＵＩを発生させたり独自のロジックを動作させて、そのレイヤーのデータを対応するサーバから読み込みクライアント上に地図を表示させます。 他のレイヤーも同様に振る舞います。 P5 この動きは、ウェブアプリケーションのデザインパターンとしてよく知られている、マイクロサービスアーキテクチャにとても似ていることがわかります。 このデザインパターンは巨大なサービスを構築するとき、そのサービスをモジュール化して分散させることで、サービスの構築・運用を効率化するために編み出されたものです。 Hyper Layering Architectureでいうところの、レイヤーデータを配信するサーバ群はまさにマイクロサービスに相当するといえるでしょう。 P6 さらに、マイクロサービスを改善したマイクロフロントエンドというデザインパターンとも似ていることもよくわかります。 マイクロフロントエンドはマイクロサービスがバックエンドのサーバ・サービスをモジュール化して効率的な開発運用を実現しようとしたのことに対して取り残されてしまった、複雑なﾌﾛﾝﾄｴﾝﾄﾞの問題を同様にモジュール化によって解決しようとするものです。 Hyper Layering Architecture2.0の、Layers as Web Appsはまさにこのマイクロフロントエンドに相当するものと言えるでしょう。 P7 それではつぎに、相違点を見ていきます。Layers as Web Appsの振る舞いの絵に再度登場してもらいます。 2点の違いがあることにお気づきでしょうか？ 一点目は、マイクロサービスへのハイパーリンクを備えたまとめサイトの存在。 二点目は、マイクロフロントエンドが 個々のＵＩとロジックを備えているだけではなく、地図への出力を持つところ。これは地理座標によって串刺しされた共通の地図キャンパスへの出力がある点です。 この違いが、マイクサービスやマイクロフロントエンドに対して、情報システム哲学上の決定的な違いになっていくことを この後ご説明していきましょう。 P8 まずはマイクロフロントエンドで一般的に指摘されている課題をみてみましょう。 マイクロフロントエンドによりサービスを構築するとき、それぞれのフロントエンドが他に影響を与える処理があることは否定できません。その結果、フロントエンドの要素が多い高度なサービスになるほど、この図のように大量の結合をケアしなければならなくなります。 要素が増えてくると、新たな要素を追加するたびに、他のすべての要素への結合すなわち影響・サイドエフェクトを考慮しなければならなくなり、これが大規模システムにおけるマイクロフロントエンドのボトルネックになります。結果的に、マイクロフロントエンドデザインパターンは特定少数の要素に限定される、特定システム内のデザインパターンの域を超えません。 P9 一方、Layers as Web Appsを見ていきましょう。 同じ絵を使い、Layers as Web Appsの構成に書き換えたのがこの図です。 P10 まず、結合の数が激減し、ハブ・スポークの構造になっています。これは地図という共通コンテキスト設定し、このコンテキストに対してすべての要素が結合することにしたためです。 例えばここに要素を一個追加したとしても、わずか一個の結合が追加されるだけです。他の要素への影響も僅少です。 P11 そして、コンテキストがわずか一つ、そしてリンクもい１要素当たり１個というこの単純な結合によって可能になるのが、まとめページからのハイパーリンクによる連携です。 この単純な連携であれば、アドホックにリンクによって要素を追加することはたやすく、またユーザによってその結合を起動させることも簡単ですね。 これがまさに原初のWWW原則との整合であり、 P12 結果として （システム内のサブシステムの設計のデザインパターンの域を超え、） 各要素がお互いに関係を持たない異種のシステム間の、疎結合による相互運用のレベルにまで押し上げる理由なのです。 P13 ここまでのことをまとめましょう。 Hyper Layering Architectureのコアとなる、Layers as Web Appsは、 従来のマイクロサービス・マイクロフロントエンドといったバックエンドとUIの寄せ集めデザインパターンの域を超え、 疎結合によるWebの根源的な相互運用性（情報統合基盤）をフロントエンド側に取り戻す、情報システム哲学上の革新 であるといえると思います。 P14 さて、Layers as Web Appsの探求をさらに進めましょう。 それが、分散・エッジコンピューティングにおける新たなパラダイムとしてのハイパーレイヤリングアーキテクチャ2.0です。 P15 先のデモの最後で、こんな処理をご覧いただいたのをご記憶でしょう。 診療所のレイヤーを表示して、 そのつぎに震度分布のレイヤーを表示したあと、 これらのレイヤーの間で演算を行い、震度5強以上の揺れを被った診療所をリストアップする というものです。 診療所と震度情報がLayers as Web Appsとして構築されている ということはご承知かと思いますが、 実は、「レイヤーの間で演算を行うという処理」自体もLayers as Web Appsとして構築されていたのです。 レイヤーのリストボックスにこの処理が並んでいたのをご記憶の型もいらっしゃるかもしれませんが、つまりそういうことです。 P16 それでは、このLayers as Web Appsによる地理空間演算処理の振る舞いをみていきましょう。 P16-1 Javascriptを使えば、地理情報の演算処理、今回の例ではIntersection処理をコーディングすることは可能です。このLayers as Web Appsにはこれが組まれています。 P16-2 ただしそれだけではありません、演算対象の二つのレイヤーをユーザに選択してもらうユーザインターフェースと、選択したレイヤーを共通キャンバスから取り込む機能、 そして演算結果を出力する機能が備わっています。 P16-3 ここで、Layers as Web Appsは、これまでのように様々なデータを共通基盤上に導入したのではなく、 地理空間演算という「処理・コンピューティング自体」を基盤上に、エンドユーザからの指示によってアドホックに導入していることがわかります。 P17 このページで今回のスライドの最後です。 従来のバックエンド連携やマイクロフロントエンドでは、デー タ連携をみることはできました。 しかし高度なコンピューティングは以下のいずれかに限定 フロントエンドでは、アプリにハードコードされたモノリス処理、バックエンドで行う場合は分散化できず中央サーバーに依存してしまいます。 これに対し、ご覧いただいた通り、Layers as Web Appsはこの常識を覆し、 ユーザ中心のアドホックなコンピューティングによる コンピューティング自体の相互可用性を実現しています。 これは、単なるWebデザインパターンの改善ではありません。約80年の情報システムの歴史において、Hyper Layering Architecture、そしてLayers as Web Appsは、この四半世紀ほど続いてきたサーバー中心・クラウドコンピューティングからの、一つの大きな転換点となりうる、パラダイムの変化、いわば「Hyper Computing」といえるものにつながるものだと、私たちは確信しています。 以上で、本プレゼンテーションを終了します。ハイパーレイヤリングアーキテクチャ二・零のコアであるレイヤーズ・アズ・ウェブ・アップスについてご理解を深めていただけたなら幸いです。