コラム

項目メタフレームワークは、業務アプリケーションを構成する画面、サーバ側で処理される業務ロジック、データベースのテーブル定義それぞれで扱うデータ項目とその属性を「メタ情報」として部品化して一元管理し、複数のアプリケーションでも利用できるように共通化する仕組みです。MCFrame XAが扱う「メタ情報」とは、アプリケーションやDBテーブルで扱うデータの型、桁数、表示フォーマットなどのまとまりを言います。

なぜこのような仕組みが必要になったのか、品目マスタの品目コードの桁数を２０桁から３０桁に増やす場合を例に挙げてご説明したいと思います。一般的には品目コードの桁数変更を行う前に、画面側のプログラム、サーバ側のプログラム、データベース定義などから、品目コードを利用している全ての箇所を探しだして、桁数変更時の影響範囲、問題有無などを検討する必要があります。そして、特定された箇所について、それら全てが３０桁で利用可能となるよう、個々のプログラムやデータベース定義の記述を必要に応じて書き換えることになります。

品目コードのように多くの箇所で使われる項目であれば、調査・変更作業には手間がかかります。変更作業は人手で行いますので、変更漏れが生じたり、誤ってしまったりすることもあります。システムの開発規模が大きくなれば分業体制となり、画面プログラム、サーバ側プログラムをそれぞれ別々の担当者で開発・保守することもあるので、品質管理が徹底できていないと、変更の実施にバラツキが生じてしまうこともあります。実際のシステム開発プロジェクトでは、この例のように、品目コードの桁数が頻繁に変更されることは少ないと思いますが、影響範囲の大きい他のデータ項目の属性変更がシステム開発のピーク時に発生したとしたら（実際、よくあると思いますが）、面倒な作業が増えるだけでなく、開発者のモチベーションにも悪影響を与えてしまうものです。

このように、ユーザから見れば小さな変更であっても、システム開発者として見れば決して小さいとは言えない手間のかかる作業を必要最小限の作業量にとどめ、効率化を追求した仕組みが必要となっていました。それを実現するのが「項目メタフレームワーク」なのです。

図中の赤枠橙色の四角がクライアントPC、アプリケーションサーバそれぞれに配置されるJavaプログラム群のイメージです。これら画面側とサーバ側のプログラムが扱う複数のデータ項目を、MCFrame XA独自の詳細設計書である「項目メタ実装仕様書」に、業務単位で集約して定義することで一元管理が可能になる仕組みになっています。「項目メタ」の仕組みを使えば、項目メタ実装仕様書に基づいて自動生成された「項目メタJavaクラス」が各アプリケーションの関連箇所で参照するように実装されるため、eclipseの参照をたどる機能を使うと、関連する実装箇所を容易に把握することができます。

メタ情報を変更する場合には、「項目メタ実装仕様書」のみを修正して、XA FrameManager Developerの自動生成ツール（MetaBuilder）を実行すれば、関連するプログラムに対して一括して変更が反映されますので、個々のプログラムを修正する必要は一切不要です。このように、項目メタフレームワークを利用すると、データ項目を変更する場合の影響範囲が容易に把握でき、また修正箇所を最小限に抑えられるため、開発・保守の効率を高め、開発コストを大幅に低減できるというわけです。

Webサービスフレームワーク

現在提唱されているSOA（Service-Oriented Architecture）が前提とする技術的基盤は、ほとんどの場合Webサービスです。Webサービスは、HTTPやXMLなどのインターネット標準技術を基盤にしており、SOAの実現に必要な事柄を技術的に支える役割となっています。将来的には、複数のWebサービス同士をつなぎ合わせて、アプリケーションを構築するというスタイルが次世代のソフトウェア環境の主流になると予測されおり、Webサービス利用環境が普及すれば、SOAのサービスを利用するユーザは、現在のWeb技術を拡張したクライアントソフトウェアを通じて、グローバル環境ですべてのソフトウェアが操作できるようになると期待されています。

XA FrameManager Platformでは、Webサービスを実現する仕組みとして「Webサービスフレーワーク」を標準で用意しています。これは、MCFrame XAの業務アプリケーションとして作成された全ての業務ロジック（Javaプログラム）を、簡単な操作でWebサービスとして外部に公開することを可能にする仕組み（Webサービス・サーバ機能）です。MCFrame XAは通常、クライアントPCとアプリケーションサーバの間で「電文」と呼ぶMCFrame特有のテキストファイルのデータを使った通信を行いますが、この部分が「SOAPメッセージ」に置き換わっても通信できる機能を用意しています。これは、所定の手順に従って、アプリケーションサーバ上に「SOAPコンバータ」と呼ぶ電文変換用のJavaプログラムを配置すると、SOAPメッセージとMCFrameの電文の変換が可能になるというものです。

SOAPコンバータは、XA FrameManager DeveloperのWebServiceBuilderを使って自動生成することができますので、既存の業務ロジック（「オペレーション」と呼ぶJavaプログラム）への追加・変更や新規のプログラミングは一切不要です。つまり、「Webサービスフレームワーク」を使えば、作成された業務ロジックが手間をかけずにWebサービスとして公開できるようになるわけです。なお、実際に業務ロジックをWebサービスとして公開する場合には、オープンソースやサードパーティ製のWebサービスライブラリが別途必要になります。また、公開されたWebサービスを利用するクライアントは、SOAPに対応している必要があります。

Webサービス利用時の大まかな処理の流れは次のようになります。

1. 外部から来るWebサービスへのリクエストを、Webサービスミドルウェア（Webサーバ）が受け付ける。
2. 受け付けられたリクエストはWebServiceBuilderが生成したSOAPコンバータによりMCFrameの電文形式に変換されてアプリケーションサーバ上に配備されている業務ロジック（オペレーション）を実行する。
3. 業務ロジックの実行結果の電文が、MCFrameの電文形式からSOAPコンバータによってSOAPメッセージ形式に変換され、Webサービスミドルウェア（Webサーバ）が外部のリクエスト元に返信する。

このように、XA FrameManager PlatformがSOAPによる電文通信を可能にする仕組みを標準実装したことと、SOAPコンバータを自動生成できるようにしたことで、業務アプリケーションのWebサービス化が容易になっています。ここまでの説明は、MCFrame XAが持つ機能を外部に公開する「Webサービス・サーバ機能」になりますが、その逆の形態として、外部企業が公開するWebサービスをMCFrame XAから利用する「Webサービス・クライアント機能」についても実現可能です。こちらについても、オープンソースやサードパーティ製のWebサービスライブラリを使用する必要があり、また、外部企業が公開するWebサービスの仕様に合わせて、Webサービス・クライアントを実装する必要がありますが、最近のWebサービスライブラリは充実してきているため、多くの手間はかからなくなっています。

前回と今回のコラムでは代表的な「開発フレームワーク」をいくつかご紹介しました。XA FrameManager Platformには様々な開発フレームワークがあり、アプリケーション基盤としての機能が充実していることがお分かりいただけたでしょうか。

次回は「XA FrameManager Platformの開発テンプレート」について、ご説明したいと思います。

第6回コラム 『XA FrameManager Platformの開発テンプレート』 に続く