企業システムでも使われるウィジェット技術
第1回 「IBM共通のウィジェット技術iWidget」

はじめに

　ウィジェット/ガジェット/ミニアプリ/ブログパーツ、こんな言葉を目にすることはないでしょうか？ 明確な定義はありませんが、これらは小さな画面を持つ（あるいは非常に限られた面積の画面しか持てないといった方が正確かもしれません）軽量なアプリケーションの総称として使われます。ウェブサイトであれ、パソコンのデスクトップであれ、あるいはモバイルデバイス上であれ、こうしたアプリケーションの数は増加の一途をたどっており、日常的に利用するちょっとした機能をこれらによって満たしている方も多いことと思います。

　本連載では、ウィジェット関連の技術動向についてご紹介していきます。第1回となる本稿ではユーザー・インターフェースにおいてウィジェットの果たす役割と価値を整理した上で、コードを交えてIBMが取り組むiWidget仕様に基づいたアプリケーションの仕組みを解説します。

　なお、一般にアプリケーション開発の世界では、こうした単体である程度の機能を提供するミニアプリという意味だけではなく、GUI（グラフィカルユーザー・インターフェース）を構成するボタンや入力フィールドといった粒度の小さな部品という意味でも"ウィジェット"という言葉が使われます。本稿ではことわりがない限り、"ウィジェット"といえば前者を総称する言葉として使うこととします。

ウィジェット技術浸透の背景

　そもそも、なぜウィジェットというものが必要なのでしょうか？ あるいはなぜこれだけの広がりを見せるまでに至ったのでしょうか？ 少し考えてみたいと思います。

ユーザー・インターフェースのコンポーネント化

　インターネット上のウェブサイトであっても、イントラネット内であっても、ユーザーがその時々に利用する画面、つまりユーザー・インターフェースは複雑になってきています。これは一時点に閲覧したい情報、あるいは使い分けなければならない画面が多岐にわたってきていることに起因します。SOAやWeb2.0といった流れによってこの傾向はますます強くなっており、今後も加速されると予想されます。SOA/Web2.0時代のユーザー・インターフェースに求められているのは、必要なバックエンドサービスを適切にまとめて操作できる使いやすい画面といえるでしょう。多数のサービスを境目なく1つの全画面アプリケーションで美しく表現することも考えられます。しかし、それよりは個別あるいは限られた数のサービスに対応した"コンポーネント化された"小さな画面部品を並べた方がいろいろな意味で現実的かもしれません。

図1：部品を組み立てる vs 1画面に紡ぎあげる

• 再利用性：言うまでもなく、同じ部品を様々なシーンで活用できることは多重開発を防ぐことになります。
図2：画面部品の再利用


　

• 細かいカスタムニーズへの対応：1つの画面が複数の部品から成り立つということは、場面や権限、業務といった様々な切り口で柔軟にその組み替えることで最適化できることを意味します。
• 変更に強い：たとえ呼び込みたいサービスの1つに仕様変更があったとしても、その影響を受けるコンポーネントさえ対応すれば済みます。コードの変更が最小限に抑えられることは、スピードや品質など様々な点で有利です。
図3：部品交換による変更への対応

　上記に挙げた点だけでも、ウィジェットがもたらすユーザー・インターフェースのコンポーネント化（部品化）のメリットが大きいことはご理解いただけたのではないでしょうか。

最大公約数的な技術が主要スキル

　従来から様々なアプリケーションのコンポーネント化技術・仕様は存在しています。しかしながら、多くの場合、それらはサーバー側のアプリケーション実行環境やフレームワーク、プログラミング言語、開発ツールとセットになっています。Java EEや.NETがその代表例です。一方、Webブラウザに出すとなると、ユーザー・インターフェース層のために生成される最終的なコードは決まってHTML/XML/JavaScript/CSSといったものです。これまでの開発とは、サーバー環境とWebブラウザ側の両方のスキルを身につけてはじめて開発することが可能であったわけです。これは言い換えると、HTML/XML/JavaScript/CSSは誰もが知っている最大公約数的なスキルセットということになります。Web技術の進化と浸透に伴い、Webブラウザ以外でもそれを再利用したくなるのが自然な流れといえるでしょう。最近はクラサバ・アプリケーションにおいても一部はWebブラウザ部品を使って実現されることが多くなりました。

　少し長くなりましたが、ウィジェットで利用される技術について、現在大きなトレンドとして次のことがあげられます。

• "最大公約数的"スキルさえあれば開発可能。
• 仕様で定めるのは、生成されるブラウザ内で動作するコードに対する決めごとが主であり、それを作り出すアプリケーションを動かすサーバー側プラットフォームは問わない。それを支えるものとして、プログラミング言語やプラットフォームに依存しないXMLやJSONといったデータ型、バックエンドにHTTPで簡単にアクセスできるREST APIの活用促進。
• クライアントアプリケーション型（非Webブラウザ）であっても、Webブラウザ部品を内包してWeb技術を最大限活用する傾向。

図4：ウィジェット開発に求められる主要スキル

　誰もが知っているスキルをベースとすることによって、ウィジェット開発の敷居は飛躍的に下がります。特定プラットフォームに特化した知識がなくても始められますし、得意なプラットフォーム、得意な開発ツール、既存の資産に合わせた実装方式を選択することにより、より高度なアプリケーションへと発展させることも容易です。数多くの開発者が参入し、世の中に何十万と言う数のウィジェットの存在が"最大公約数的スキル"に主軸を置くことの効果を示していると思いませんか？