第1回
Relaxerで実現するJava開発の新プロセス

浅海智晴
2003/5/27

1.はじめに

　「RelaxerStudioプロジェクト」とは、浅海智晴、五嶋剛、山中崇文、永山葉子の4名が情報処理振興事業協会が主催する「未踏ソフトウェア創造事業」において萩谷昌己Project Manager（東京大学大学院教授）のもとで推進したソフトウェア開発プロジェクトのことである。開発期間は、2002年7月から2003年2月までの8カ月間。本連載は、RelaxerStudioプロジェクトの成果であるRelaxerプロセスのサンプルアプリケーション「図書館システム」を通して、Relaxerプロセスの詳細を読者に伝える目的で執筆する。

　Relaxerプロセスの目的は、ビジネスアプリケーション開発を効率的に行うためのノウハウを定型化することである。後述するようにスキーマコンパイラ／コンポーネントコンパイラであるRelaxerを用いることで、膨大な量のJavaプログラムを自動生成することができる。

　もちろん、XMLを利用する時に自然にRelaxerを利用するという方法も十分有用である。しかし、Relaxerの持つJavaプログラム生成能力を徹底的に活用することで、より大量のJavaプログラムを自動生成させることができる。その結果、ビジネスアプリケーション開発の期間を短縮しながら信頼性を高めることができる。

　Relaxerの持つ能力を徹底活用するためには、オブジェクト指向開発プロセスの中でのRelaxerの活用方法を明らかにすることが必要である。その上で、Relaxerの活用を前提にオブジェクト指向開発プロセスをチューニングするとさらに効果的である。
　
　この2つの目的で、開発された開発プロセスがRelaxerプロセスなのだ。
　
　プロジェクトの全容を詳細に記すことはスペースの都合上、難しいため、要所要所を抜き出しながら詳述し、全体像を浮き彫りにするという構成を採用する。とはいえ、いきなり各論を展開しても読者の混乱を招くことになるため、第1回、第2回では、Relaxerプロセスの概観について簡単に説明し、大まかな全体像をつかんでもらう。第3回以降からは開発工程に沿いながら、Relaxerプロセスの具体的な内容について解説を行っていく。

今回の内容

1 はじめに 2 Relaxerとは 　2.1 スキーマコンパイラ 　2.2 コンポーネントコンパイラ 3 アプリケーション・スタイル 　3.1 伝票指向アーキテクチャ 　3.2 伝票指向アーキテクチャの理由 　　3.2.1 ビジネスアプリケーションとの相性 　　3.2.2 XML技術との相性 　　3.2.3 コンポーネント技術との相性 　3.3 コンプレックス・レコード 　3.4 J2EE

2.Relaxerとは

　Relaxerプロセスの話に入る前に、RelaxerおよびRelaxerプロセスが想定するアプリケーション・スタイルについて簡単に説明する。 まず、Relaxerについて見ていこう。RelaxerはRELAXベースのXMLスキーマコンパイラであり、独自のコンポーネント記述言語Relaxer Component Definition Language（RCDL）ベースのコンポーネントコンパイラである。

[関連記事]
Relaxer：XMLがJava開発を変える （XML eXpert eXｃhange）
W3Cスキーマに対抗するXMLの新仕様「RELAX NG」 （＠ITNews）
RELAXが目指しているもの （XML eXpert eXｃhange）
XMLにおける「ボヘミアンと貴族の階級闘争」を読み解く （XML & Web Services）

◇2.1 スキーマコンパイラ

　Relaxerの持つ最重要機能がスキーマコンパイラである。 Relaxerは図1に示すようにRELAXスキーマをはじめとする入力から、さまざまな出力を生成する。

図1 スキーマコンパイラ

　入力は以下の4つである。

RELAX NGスキーマ

RELAX Coreスキーマ

XML文書

リレーショナルデータベーススキーマ

　出力は以下の10種類である。

Relaxerオブジェクト

Relaxerテーブルオブジェクト

RELAX NG

RELAX Core

DTD

XML Schema

HTML FORM

Relaxer Dialog

XSLTスタイルシート

Relaxer Meta

　Relaxerオブジェクトは、RELAXでモデル化されたXML文書をマッピングしたJavaオブジェクトである。XML文書との相互変換が可能である。また、Relaxerテーブルオブジェクトは、RelaxerオブジェクトおよびXML文書をRDBMSに格納するためのデータアクセスオブジェクトである。さらに、RelaxerはRELAX NGスキーマ、RELAX Coreスキーマ、DTDスキーマ、XML Schemaスキーマの4種類のスキーマを生成することができる。モデリング時には、RELAX NGスキーマまたはRELAX Coreスキーマを生成し、目的に応じてDTDやXML Schemaに変換して利用することが可能となるわけだ。
　
　プロジェクト開始前のRelaxerでは、内部データとしてRELAX Coreベースのメタモデルを使用していた。今回のプロジェクトでは、このメタモデルをRELAX NGベースのものに更新することでRELAX NGスキーマを入力にすることが可能になったのである。

　そのほか、HTML FORMやXSLTスタイルシートなどの成果物も生成することができる。
　
　スキーマコンパイラの1つの応用がデータバインディングである。図2に示すように、RELAXスキーマから、これに対応するJavaクラスを生成する機能がデータバインディングである。作成されたJavaクラスを用いることで、RELAXスキーマに準拠したXML文書とJavaオブジェクトの相互変換を容易に行うことができるようになる。

図2 XMLとJavaのマッピング（クリックすると拡大）

◇2.2 コンポーネントコンパイラ

　Relaxerは、スキーマコンパイラの基盤の上にコンポーネントコンパイラ機能を実現している。Relaxerのコンポーネントコンパイラ機能は、図3に示すようにRCDL定義よりさまざまなコンポーネント実装を生成する。

図3 コンポーネントコンパイラ

　Relaxerが生成するコンポーネントの種類は以下のものがある。

JavaBeans

EJB

RMI（Remote Method Invocation）

RMI over IIOP

JAXM（Java API for XML Messaging）

　JavaBeansは、クライアントサイドにおけるJavaの基本コンポーネントである。EJBは、J2EEアーキテクチャ上で用いられるサーバサイドコンポーネントだ。RMIは、Java専用のRPCメカニズムで、RMI over IIOPは、Java上におけるCORBA分散オブジェクトの実装である。そして、JAXMは、XMLベースメッセージングのためのAPIであり、現在のところ、事実上JavaにおけるSOAP APIと考えてよい。つまり、JAXMを利用することでWebサービスのコンポーネントを実現できる。Relaxerのコンポーネントコンパイラによって実現される世界は図4となる。

図4 J2EEにおけるRelaxer

3.アプリケーション・スタイル

　続けて、Relaxerプロセスが想定しているアプリケーション・スタイルについて説明する。

◇3.1 伝票指向アーキテクチャ

　Relaxerプロセスでは、アプリケーション・アーキテクチャとして「伝票指向アーキテクチャ」を提案している。伝票指向アーキテクチャの構成を図5［伝票指向］に示す。伝票指向アーキテクチャでは、データベースに格納する「元帳」と外部入出力で利用する「伝票」を基本のモデル要素としてアプリケーションを構築する。

図5 伝票指向

　さて、ビジネスアプリケーションの核となるのが、以下の外部入出力である。

画面に対する帳票出力

画面からの帳票出力

プリンタに対する帳票出力

データベースに対するレコード入出力

他システムとのレコード送受信

　これらの処理はかなりの定型化が可能であるため、この部分の開発効率をいかに上げていくのかという点が、コスト低減や信頼性向上のポイントとなる。

◇3.2 伝票指向アーキテクチャの理由

　Relaxerプロセスが伝票指向アーキテクチャを提案しているのは、伝票指向アーキテクチャに以下の長所があるからである。

ビジネスアプリケーションとの相性の良さ

XML技術との相性の良さ

コンポーネント技術との相性の良さ

　では、それぞれの長所について見ていこう。

●3.2.1 ビジネスアプリケーションとの相性

　ビジネスアプリケーションとの相性の良さは、ビジネスアプリケーションが本質的に元帳と伝票を操作する処理を行うものであることによる。従来、ビジネスアプリケーションはCOBOLで記述されメインフレーム上で動作するアプリケーション・アーキテクチャが主流だったが、これは元帳と伝票の操作に特化されたCOBOLの言語仕様が、本質的に重要だったことを物語っている。

　もちろん、従来技術からの連続性は、現在第一線で活躍しているエンジニアのスキルを次世代システムの開発に有効に活用できるということでもある。

●3.2.2 XML技術との相性

　伝票指向アーキテクチャはXML技術との相性がとても良い。つまり、伝票指向アーキテクチャにおける「伝票」の実装技術としてXMLを用いることができる。XMLのアーキテクチャを図6に示す。

図6 XMLアーキテクチャ

　伝票指向アーキテクチャでは、「画面に対する帳票出力」「画面からの帳票入力」「プリンタに対する帳票出力」「データベースに対するレコード入出力」「他システムとのレコード送受信」といった入出力を重要視していることは前述したが、これらの入出力処理に対して、XML技術は表［入出力機能とXML技術］に示すような標準機能で対応することができる。

入出力機能	XML技術	機能
画面に対する帳票出力	HTML	Webブラウザでの表示
	XSLT	XML文書の変換
画面からの帳票入力	HTMLのFORM	簡単な帳票入力
	XForms	本格的な帳票入力
プリンタに対する帳票出力	XSL	XML文書から印刷表現を生成
データベース入出力	XQuery	XMLデータベースに対する問合わせ
	XPath	XMLデータベースに対する簡易問合わせ
	DOM	XMLデータベースのアクセスと更新
他システムとのレコード送受信	SOAP	XMLを表現形式としたRPC/メッセージング
表 入出力機能とXML技術

　以上の技術が現時点ですべて利用可能というわけではないが、将来的にはXMLだけでかなりの処理をカバーできることになる。もちろん、入出力処理のすべてをXML技術だけで賄（まかな）うことはできないが、この点をスキーマコンパイラであるRelaxerが補完することができる。図7はRelaxerによる伝票指向アーキテクチャである。Relaxerが、XMLの持つ入出力機能を補完している。

図7 Relaxerと伝票指向アーキテクチャ

　画面に対する入出力とプリンタからの印刷は、XMLの持つ機能をそのまま利用する。データベースに対する入出力では、リレーショナルデータベースに対してXMLを格納するためのJavaプログラムをRelaxerが生成する。他システムとの通信では、EJBおよびSOAPでの通信を行うJavaプログラムをRelaxeが生成する。つまり、XMLの標準機能が利用できるところではこれを用い、XMLではカバーできない機能についてはRelaxerがJavaプログラムを生成し、補うわけである。

●3.2.3 コンポーネント技術との相性

　伝票指向アーキテクチャはコンポーネント技術との相性も良い。この相性の良さにはXML技術の恩恵もある。コンポーネント指向によるアーキテクチャでは、図8に示すように以下の3種類のデータが存在する。

データベースに格納されるデータ

コンポーネント内で使用するデータ

コンポーネント間を流通するデータ

図8 コンポーネントとデータ

　純粋なオブジェクト指向では、プログラム内で使用するデータとデータベースに格納するデータを、永続オブジェクトという形でシームレスに統合することが理想とされてきた。このモデルではプログラムを構成するオブジェクト間でデータが共有されることになる。しかし、この方法はコンポーネント指向では必ずしも有効でない。図9は、データ共有モデルとデータ流通モデルである。データ共有モデルでは、データベースに格納されるデータのカプセル化が行われていないために、コンポーネントの再利用が阻害される。それに対して、データ流通モデルでは、データベースに格納されるデータはカプセル化されており、コンポーネントは伝票を用いてデータを流通させる。伝票の構造さえ決めておけば、データベースの構造はコンポーネントの都合でどのようにも変更することができる。

図9 データ共有モデルとデータ流通モデル

　つまり、コンポーネント指向では、データをコンポーネント内にカプセル化し、データの流通は共有データではなく、コンポーネント間を流通するデータを通して行われる方法が基本になると考えられる。この場合、コンポーネント間を流通するデータの実装技術としてXMLは有力な選択肢となる。

　さらに、現代のコンポーネント指向では、分散コンポーネントが基本となる点も重要だ。分散コンポーネントでは、コンポーネントが同一のプロセス内に配備されなくても、さらには同一のマシン上に配備されなくても、協調動作できなくてはならない。このためには、プロセス間あるいはマシン間でもシームレスに流通させることができるデータを軸にコンポーネントの連携を考えなくてはならなくなる。

　つまり、この点でもコンポーネント間で共有されるデータをできるだけ減らすことと、コンポーネント間を流通するデータとしてXMLを用いることが本質的に重要となるのだ。図10は、伝票指向アーキテクチャとコンポーネントの関係を示している。アプリケーションは複数のコンポーネントを組み合わせて構築されるが、これらのコンポーネントは伝票の流通を通して連携するわけである。

図10 伝票指向アーキテクチャとコンポーネント

◇3.3 コンプレックス・レコード

　伝票指向アーキテクチャを支えるコンセプトとして、Relaxerプロセスでは「コンプレックス・レコード」を提案している。コンプレックス・レコードは、RDBMSのレコードのような平板なレコードではなく、ツリー構造を持ったレコードである。さらにコンプレックス・レコードはXMLとしてモデル化され、Javaオブジェクト、RDBMSレコードにマップされる。この処理に利用されるのがスキーマコンパイラであるRelaxerである。 図11はRelaxerの提案するコンプレックス・レコードによるモデリングである。

図11 コンプレックス・レコード

　RELAXスキーマを用いて、XML文書のセマンティクスを持ったデータを定義する。このデータがコンプレックス・レコードである。 まず、コンプレックス・レコードは、その定義上、当然XML文書として操作することができる。さらにスキーマコンパイラであるRelaxerによって、このXML文書とJavaオブジェクトおよびRDBMSレコードを相互変換するJavaプログラムが自動生成される。このため、アプリケーションプログラムは必要に応じて、XML文書、Javaオブジェクト、RDBMSレコードに相互変換できるわけだ。 このようにXML文書、Javaオブジェクト、RDBMSレコードをシームレスに相互変換できることがコンプレックス・レコードのコンセプトであり、伝票指向アーキテクチャの基盤となる。

◇3.4 J2EE

　コンポーネント指向開発を考えるうえで、今後重要になってくるのがいうまでもなく分散コンポーネント・ミドルウェアであるJ2EEである。ここで、J2EEにおけるデータの流れに着目してみたい。 図12はJ2EEにおけるデータフローである。

図12 J2EEのデータフロー

　図の上側は、Java指向のデータフローである。従来は、このJava指向のデータフローが設計の中心となっていた。リソース・ティアでは独自形式のデータが用いられるが、これをインテグレーション・ティアでJavaオブジェクトに変換する。そして、このJava オブジェクトがWebティアまで流通し、Webティア上でHTMLに変換される。つまり、アプリケーションのほとんどの処理ではJavaオブジェクトとしてデータが流通する。

　一方、図の下側は、XML指向のデータフローである。リソース・ティアでは独自形式のデータが用いられるが、これをインテグレーション・ティアでXML文書に変換する。また、Webティアからクライアントまでの処理でもXML文書の形でデータが流通する。Javaオブジェクトが使用されるのは、ビジネス・ティアにおいてビジネス・ロジックを実行する処理においてのみとなるわけだ。

　このXML指向のデータフローは少し極端に感じるかもしれないが、ある意味では必然性を持ったアーキテクチャである。なぜなら、XML指向のデータフローを採用することで、再利用可能な部品の数が圧倒的に増えるからである。

　前述したようにXMLを用いればXSLTスタイルシートやXQueryなどのXML技術をそのまま利用することができる。また、EAI（Enterprise Application Integration）などで提供されているデータ統合ミドルウェアもXMLとの相性が良い。ここで、アプリケーション・アーキテクチャとして伝票指向アーキテクチャを採るとどうなるだろう。伝票指向アーキテクチャではXMLによって実装された「伝票」が外部入出力およびコンポーネント間のデータ流通で用いられる。このメカニズムは、そのままXML指向のデータフローを採用したJ2EEアプリケーションとして実現できる。J2EEをターゲットにしたコンポーネント指向アプリケーションのアプリケーション・アーキテクチャとして伝票指向アーキテクチャが有力であることがお分かりいただけたと思う。

　以上、RelaxerおよびRelaxerプロセスが想定するアプリケーション・アーキテクチャについての確認を行った。次回はRelaxerプロセスの全体像を紹介する。

IT Architect 連載記事一覧