HTML5の時代となり、フロントエンドの重要性が増してきています。業務システムにおいても、HTML5を本格的に適用する事例が増えてきました。このような環境において、バックエンドを含めた次世代アーキテクチャのベストプラクティスを模索するというのが本記事の趣旨です。
本記事では、HTML5時代におけるアーキテクチャの概要を提示した上で、アーキテクチャ実装の具体例として、「OData＋UIフレームワーク」を採用した事例を紹介します。その上で、このアーキテクチャを採用した場合のメリットと、今後の課題について記述していきます。
HTML5時代における業務システムアーキテクチャのポイントとは
業務システムにおけるHTML5化の流れについては、「JavaからHTML5ヘ。業務システムの開発におけるWeb技術の変化と適応事例」にて、エキスパートの佐川夫美雄さんが語っているように、HTML5時代において「JavaScriptフレームワークを用いたWebアプリケーション」が主流となることは、私自身も間違いないと感じています。
佐川さんが記事の中で語っているように、従来はブラウザで表示するためのHTMLをバックエンドが作成していましたが、今後はデータのみを返して、フロントエンドでHTMLを組み立てる方法が、今後は主流となっていくことでしょう。
その上で、どのようなアーキテクチャになるのかを考えてみると、フロントエンドとバックエンドを切り離した俯瞰図を描けるかどうかが、大きなポイントとなります。
こちらにアーキテクチャ俯瞰図を記載します。
では、大きな3つの構成要素について見ていきましょう。
1.フロントエンド
フロントエンドはAjaxの普及以降、大規模・複雑化が進んでいます。最近では、「Backbone.js」「AngularJS」に代表される「クライアントMV*フレームワーク(※)」と呼ばれるライブラリをベースに構築されることがほとんどです。その場合、UIは「Bootstrap」など「CSSフレームワーク」と呼ばれるUIのみの特化したライブラリを組み合わせることが主流です。また、「Sencha」に代表される、UIコンポーネントと呼ばれるUI部分を含んだオールインワンタイプの「UIフレームワーク」を利用するケースもあります。
(※)クライアント側フレームワークはMVC、MVVM、MVWなど複数の考え方が存在しているため、それらをまとめて「MV*」と表現しています。
2.バックエンド
HTML5時代のバックエンドは機能特化型で進化してきました。フロントエンドに対してWeb APIを公開し、主に、永続化やトランザクション・認証管理・サーバーサイドキャッシュなどの用途で利用されます。また、セキュリティ上の理由でフロントエンドに配置できないビジネスロジックを配置します。そのため、従来のオンプレミス環境にとどまらず、クラウド上に構築されたり、BaaS、（モバイルに特化した）mBaaSなど、クラウドサービスを利用するケースもあります。
フロントエンドから見たバックエンドは、「JavaEE7（JAX-RS）」「Node.js」「Ruby on Rails」など、どんな言語やフレームワークで実装されているかは、あまり重要な違いではありません。重要なことはバックエンドがどのようなWeb APIを公開しているかということです。
3.通信
通信は主に軽量で、JavaScriptでの扱いが容易なJSONが主流となっています。ただし、システム間連携といったユースケースに代表されるような、厳密にデータ型を指定したい状況ではXMLの使用も一考に値します。
業務システムアーキテクチャのポイント
このように、HTML5時代における業務システムアーキテクチャのポイントとは、バックエンドとフロントエンドを切り離し、Web APIを経由してデータアクセスしていることです。そして、特に重要なことはWeb APIのインターフェースをどのように設計するかです。
バックエンドとフロントエンドを分割するアーキテクチャを採用した場合のメリットは、並行開発ができるということがあります。そして重要なことは、両者を紐づける制約がWeb APIのインターフェースであるため、インターフェースさえ守って入れば、片方に影響を与えることもなく、もう片方を作り替えることができるということです。例えば、オンプレミス上で構築してある古いバックエンドを、クラウド上に他の言語で再構築するようなことも可能です。
バックンドのWeb API化は、ビジネス変化の激しい今日において、業務システムが安全に変化し続けるための最重要要件だと考えています。
業務システムにおいてWebAPI設計を難しくする3つのポイント
HTML5時代の業務システムは、WebAPIを介した疎結合なアーキテクチャに移行していくのがトレンドであることは先ほど述べた通りです。フロントエンドとバックエンドの並行開発を成功させるためには、正しいWebAPIを早期に設計することが重要です。
WebAPI自体は、Web2.0時代にブームがあったように古い歴史のある技術であり、ノウハウが蓄積されている部分もありますが、ここでは業務システムにおいてWebAPI設計を難しくする3つのポイントについて提示した上で、WebAPI設計をどのようなスタンスで進めて行くべきか記述します。
1. データアクセス条件の多様性
売上データのWebAPIを例に説明すると、業務システムでは同じ売上データを取得する際に、様々な条件を与えます。これは、業務システムを利用するユーザーに多様性があるためです。例えば、拠点・店舗・地域・売上日・担当者・品目などの項目が挙げられます。さらに画面ごと、ユーザのロールごとに細かく条件が異なる場合も存在し、多様性を考慮した設計が必要です。これらの条件はWebAPIのURLパラメータとして定義される項目です。
URLパラメータを設計した後に並行開発していくのですが、当初から正しいURLパラメータを設計することは難しく、必ず後の工程に変更が入ります。
2. データアクセス時のエンティティ間の関連
データアクセス先が、複数のマスタデータ（エンティティ）を結合したデータを返すことも特徴です。これは、業務システムが扱うデータが、複数のエンティティに正規化された上で保持されているためです。売上データに対する店舗などのマスターデータをイメージしていただければ、分かりやすいかと思います。
こちらも実際に実装してみると過不足が多く見つかるポイントです。
3. トランザクション処理
WebAPIはステートレスの前提で作られているため、WebAPIをまたがるトランザクション処理は苦手です。特にロールバック処理を行いたい場合は、WebAPI単独で処理が完結してしまうため、以前の処理を打ち消すWebAPI呼び出しを行う必要があります。
そのためトランザクション処理を行う場合は、WebAPIとバックエンドの処理の間にトランザクション処理を担うレイアーを作成するような工夫が必要で、業務のトランザクションを考慮したWebAPI設計が必要です。
WebAPI設計にて取るべきスタンスとは
業務システムにおいてWebAPI設計を難しくするポイントについて説明しました。フロントエンドとバックエンドを繋ぐWebAPIは両者の影響を受けやすく、将来を見越して設計することが難しいこと、理解していただけたかと思います。そのため、WebAPIの設計は「最初に設計を固める」より「作りながら育てる」というスタンスで取り組むべきだと考えます。
次は、HTML5時代のアーキテクチャを実現する具体例として、「OData＋UIフレームワーク」の組み合わせを紹介します。
作りながら育てるWebAPI設計を実践するための1つの選択肢「OData」
WebAPI設計は「作りながら育てる」と提示しましたが、終わらないタスクほど嫌われるものはありません。実際の業務システムの開発においては、将来の変更も見越した網羅性のあるWebAPI設計を行って、後の変更の影響を最小限に止める方が現実的です。
最初に網羅性のある設計ができ、変更にも柔軟という、そんな都合の良いものが果たしてこの世の中に存在するのでしょうか？ そこで、注目したものがODataです。
ODataとは 「Webアプリケーションにおける、データアクセス方法を標準化したプロトコル」です。Microsoft、IBM、SAP、Citrix社など中心となりデータアクセスプロトコルの業界標準となるよう動いています。WebAPI版のODBCやO/Rマッパーのようなものと言えばイメージしやすいと思います。
ODataはHTTPをベースにしているため、一つ一つのデータアクセスは通常のHTTPでのWebAPIとなんら変わりませんが、次に代表されるようなデータアクセスに関する様々な指定をURLパラメータとして標準で定義しています。
- 順序指定：
$orderby - ページング：
$skip(開始位置）$top(取得件数) - フィルタ：
$filter - 部分取得：
$select - 関連エンティティ取得：
$expand
URLパラメータの詳細はこちらを参照ください。
このように、URLパラメータでデータアクセス方法を柔軟に変更できるため、従来は大掛かりな変更が必要であったWebAPIの変更が、URLパラメータで吸収できることが多くなります。従来のWebAPI設計が変化に弱い硬直的なものだとすると、ODataを利用したWebAPI設計は変化に強く柔軟なものです。
しかし、OData特有のURLパラメータを生成することが非常に面倒であるため、今日まであまり普及しなかったことも事実です。最近ではdata.js、Breeze.jsなどOData対応のJavascriptライブラリが登場し、UIフレームワークのOpenUI5と融合することで状況が変わったと考えています。
ODataとUIフレームワークの融合がもたらすメリットとは
ODataとUIフレームワークが融合することの最大のメリットは、データアクセスからUIへの結果反映まで、難易度が高く繊細な部分をUIフレームワークで隠蔽できることです。
UIコンポーネントに対してODataとのマッピングを施すことで、UIフレームワーク側でユーザの操作(ページングやフィルタ処理など)があった際、自動的にバックエンドへデータアクセスするためのURLを生成します。さらに、バックエンドから取得したデータはUIフレームワークが自動でUIコンポーネント側へ変更を反映します。
私が携わったシステムでは、UIフレームワークとODataを組み合わせることによって、データアクセスとUIへの結果反映の部分のコード量を、大幅に削減することができました。こちらが、ODataとUIフレームワークを適用した場合のアーキテクチャの概要図です。
（※）ODataを利用するためにはOData仕様に準拠しているWeb APIを実装しているバックエンドが必要です。これをODataServiceと呼んでいます。
ODataとOpenUI5を利用した実装例とチュートリアルについては、私が作成したOpenUI5とODataを使ってWebアプリケーションを作るに一通り記載したものがあります。参照していただければ雰囲気がつかめると思います。
上の紫の部分がODataとUIフレームワークを組み合わせることによって隠蔽される部分です。フロントエンドが得意なエンジニアが少ない、業務システム開発の現場にてこれだけ実装する範囲を隠蔽できるのであれば、現実味のある選択肢の1つではないでしょうか？
そんなに甘くないぞ！バックエンドのOData化。救うのは.NET系エンジニア
一見、幸せになれそうに見える「OData+UIフレームワーク」アーキテクチャですが、最大の課題はバックエンドのOData化です。私の携わったシステムでは「SAP Netweaver Gateway」というSAP社の製品を導入することでバックエンドのOData化を実現しています。
現在、もっとオープンかつ手軽な方法でOData化が実現出来ないか模索しています。中でもMicrosoftの「ASP.NET Web API 2.2」は少ないコード量でODataを生成することができ、今最も注目しているOData化の方法です。 今後は、「.NET」系のノウハウとコラボレーションしていき、より簡単にバックエンドのOData化が実現できるようしていきたいと考えています。
さいごに
今回は、いくつか有効性を検証しているアーキテクチャの中で、「OData＋UIフレームワーク」という、一般的にあまり知られていないアーキテクチャを紹介しました。今後、様々なUIフレームワークがODataを標準でサポートし、より選択肢が増えることになれば、一気に業務システムのHTML5化におけるデファクトになる可能性があると感じています。
また、業務システムを切り口にした場合、一般的なWeb開発では注目されないテクノロジーに注目することも、なかなか興味深いです。
HTML5時代の業務システムにおいて有効なアーキテクチャはいくつも存在すると思います。これを機に、このような議論が業界内で進むことを期待しています。そして、日本のエンタープライズITをより良いものにしましょう！