第1章　　はじめに

１．１  研究目的

インターネットに関連した技術や仕様は次から次へとめまぐるしく登場し、発展を続けている。これから述べるXMLとJavaもそのひとつである。しかし、その新しい技術や仕様に対し、手放しで導入すべきかというとそうではないのではないだろうか。特にXMLについては「新しいHTML」という間違った認識がまだなおあり、XMLなら何でも可能にしてしまうような流行現象がそれに拍車をかけているように思える。これはXMLだけに言えることではなく、どんな技術にでも言えることであるが、その技術がどういうものでどういったことができるのか。（機能性）また、その技術を導入するにあたりどれくらいのコストがかかり、どれくらいの効果が期待できるのか（効率性）ということについて検討し、見極めることが必要である。

現在、インターネットはビジネスにおいてなくてはならないものになっており、すべての業務を電子化、システム化してコスト削減、効率化しようとする動きが広がっている。これまで、品物や資材などを注文、購入する場合は、相手先へ電話を使って伝えるか、伝票に書いて注文するのが一般的であった。しかし、最近では社内のコンピュータから通信回線を使って、相手先のコンピュータにデータを送り、注文するということが広く行われるようになっている。ひとつの取引で発注書や見積書、契約書など多数の書類を紙で扱い、なおかつ人がその書類を手に持って自社と取引先との間を往復し届けていたコストをインターネットを介した電子化した情報のやり取りなら省くことができる。手紙や電報に代わって電子メールが普及しているように電子情報の交換は時間と手間とコストを削減できるためビジネスにおいて必要不可欠なものになっている。

インターネットが普及する以前、コンピュータやワープロによる文書処理の目的は文書の清書（印刷）にあり、デジタルデータの大きな利点であるデータの交換や再利用性は意識されていなかった。しかし、ネットワークが普及し、データ交換や再利用性の重要性が認識され始めると、データの非互換性の問題が顕在化してきている。

そこで本研究では、インターネット交換フォーマットとして現在普及しつつあるXMLを例にとり、その効果と有益性を検証することを目的とする。

また、XMLと同じくして効果と可能性が期待されるJavaを研究対象として取り上げる。XMLとJavaとの関連性については書籍などでも多く取り上げられ[1],[2]、その相性、効果はすでにいくつか実証されている。しかし、どちらとも比較的新しい技術であり、速いスピードでバージョンアップやそれらの付属技術、仕様が発表されている。そのような新しい状況の中でXMLとJavaの相性、効果を実証していくことを二つ目の目的とする。

三つ目の目的は第５章で詳しく触れるが、システム構築における開発知識の習得とその応用を探る。本研究を進めていく上でシステム構築を行い、検証を行うため、やはり技術的な知識の習得は不可欠であると考える。

１．２　　研究方法

まず最初にデータ交換の必要性、インターネット環境における現状の問題点を述べ、XMLの必要性を明らかにしてからXMLとは何か、Javaとは何か、またその優位性、関連性を論じる。

実際の研究方法としてはXMLをデータフォーマットとして利用し、サーバサイドJava技術を採用したシステム構築を行うことによりその有益性を検証する。

またシステムそのものの評価を仰ぐため実際、システムを利用してもらい、アクセス件数とアンケート形式で集計、分析しその後の保守、運用、機能拡張に生かしていく。

最後にこれらの研究結果から考察をしていく。

第２章　　研究背景

２．１　　B2Bの発展経緯と動向

B2BとはBusiness-to-Businessの略であり、企業間取引のことを意味する。1994年4月、アメリカでインターネットを商取引に適用することを目的として電子決済やイントラネット間の相互運用のための標準化を進める非営利団体CommerceNet[10]が発足された。これがきっかけでB2Bの商取引への適用が始まり、世界へ広まった。

インターネットはこれまで考えられなかったような新しい商取引を可能にし、B2Bを根本的に変え始めている。

B2Bはまず最初にEDI[1]という形で広まることとなる。このことにより紙の伝票をやり取りしていた従来の方式に比べ、情報伝達のスピードが大幅にアップし、事務工数や人員の削減、販売機会の拡大につながった。しかし、これは特定の取引相手と固定的で長期的な契約のもと頻繁に行われていたが、導入コストが高く、自動化の効果が期待される分野でしか導入できないという理由からスケーラビリティ[2]が低かった。また、現在のほとんどのEDI構造は図1のようなメッシュ構造になっているため、基本的には1対1の企業間取引であり、異なる企業間を結ぶ運用システムの維持管理や新しいシステムへの対応など、当該企業間で調整、解決する必要があった。

図1　現在のEDI構造（メッシュ構造）

また、EDIでは個別企業間でのみ契約書を取り交わし、取引事務の効率化が行われている。その一方で、取引相手の数だけ存在する契約事務を管理しなければならず、これが大きな負担になっている。長期間にわたる固定的な取引ならこれで良いかもしれないが、市場環境の変化はめまぐるしく、従来の製品販売計画だけでは読み取れなくなってきている。

現在ではeMarkets(Electronics Marketplaces)、またはe-marketplaceとよばれる形態へ移行している。eMarketsとはインターネット上に設けられた企業間取引所のことであり、Webサイトを通じて売り手と買い手を結び付ける電子市場のことである。図2のようなスター型接続になっているため、取引先を状況に応じて選択でき、取引を柔軟に効率良く行うことが可能となる。また、売り手と買い手が直接取引を行うことにより、これまでの中間流通業者を「中抜き」にして取引することができ、流通コストが削減できる。売り手にとっては、新規取引先の開拓や、営業コストの削減、取引先の増加による在庫リスクの平準化、在庫調整などを実現できる。買い手にとっては、調達コストや物流コストの削減などが実現できる。

図２　eMarkets

当初は、オフィス用品の購買から始まったが、商品の種類や業界ごとに様々なeMarketsが立ち上がっており、中核事業に直接影響する原材料の調達や最終製品の販売にも普及が進んでいる。企業間電子商取引(B2BEC)のほとんどはeMarketsの形で実現するのではないかといわれている。

このように複数の売り手と買い手が、今までのEDI取引に特有の固定的な商取引から、流動的でダイナミックな取引相手探しや取引そのものを進めるための機能を提供できるようになった。

緊急時にいかにして早急に調達手段を確保するかといった商取引の流れが速くなっている現在では長期間の企業間取引以外に、短期の顧客要求にも対応しなければならない。長期取引と短期取引の比率は変化し、今では短期取引の比重が高くなっている。特に製造業では、突発的な工場のトラブルや顧客からの発注の追加、キャンセルはつきものである。これにより、工場や倉庫にはどうしても在庫の過不足が生じてしまう。この在庫の販売・調達先として、電子市場をうまく活用する方法が取られている。まさにeMarketsはそのような市場ニーズに合った形態である。

　
　　　２．２　　問題点

２．２．１　　システム連携における柔軟性の欠如

企業にとってIT導入によって期待できる大きな効果のひとつとして情報の共有化がある。ここでいう情報の共有化とは電子化された情報（デジタルデータ）を社内の各システム、または取引先のシステムと効果的に連携し、システム間での情報交換、情報管理、情報活用がスムーズにそして効率的に行われることである。

情報共有化によってこれまで行われていた書類による保存や情報交換、またそれを人の手でデータ入力する無駄を省くことができる。また、情報を一元管理することで常に新しい情報を即時に入手でき、情報の有効活用を可能にする。

確かに今日においてビジネスのIT化は普及している。しかし、情報の共有化という点において、そのメリットが十分に生かされていないのではないだろうか。

情報共有化の前提に情報の電子化が必要である。情報の電子化については現状でもすでに各種ドキュメントの電子化はすんでいるといってよい。なぜなら会議資料や各種の書類でワープロを使わずに手書きのままのものはすでに存在していないからである。しかし、ワープロを使っていることと情報の共有が実現されていることとはまったく異なることである。情報の電子化から共有化へステップアップするにはシステム間で連携しなければならない。現在、システム連携においてその柔軟性が欠如している。

その理由は標準化されたデータ交換フォーマットが存在しないということである。このため企業独自のフォーマットや各ベンダが提供する特定のプラットフォーム、アプリケーションに依存したフォーマットでの情報の共有化がすすめられている。システム間の連携は特定のフォーマットを理解でき、利用できるプラットフォームやアプリケーションを備えたシステム間のみでしか行われていないのが現状である。そのため、これまでの情報システムにおいては、部署ごと、業務系ごと、地区ごと、取引先ごとに局所的最適化を行っており統合化が未発達であった。このために情報化投資が局所的にとどまってしまい限界効用が著しく低下している。また、フォーマットのみではなく通信プロトコルや運用方法なども異なる場合は、いちいち個別に取り決めを行い、一方の企業（多くは受信側）が他方の企業に合わせる煩雑な作業や、その都度の多額な開発投資が必要となっている。

この結果生まれた弊害を以下に示す。

（１）多端末現象（図３）

取引先ごとにプラットフォームが異なるためそれぞれの専用端末を複数設置しなくてはならない現象。またはアプリケーションの違いを吸収するため取引先ごとに新たなシステムを開発しなければならない。（多ソフト化現象）これにより新しい取引先を開拓することに対するリスクが大きくなるため、不特定多数の企業と最適の取引を行うというインターネットのメリットを阻害するひとつの要因になっている。

　　　　　　　　　　　図3　多端末現象

（２）変換地獄（図４）

企業間の取引データの交換において、各社の業務システムの違いから生じるデータフォーマットの違いがあるために、相手が異なるたびにフォーマット変換プログラムを作成しなければならない。または自社システムの変更に膨大な投資を余儀なくされる問題。

　　　　　　　　　　　図4　変換地獄

（３）紙の洪水

取引先企業との情報交換が膨大な量の紙を通じて行われていることによる問題。電子化された情報を共有するフォーマット、プロトコル、インタフェースなどが対応していないためにデータを紙で受け取り、再びコンピュータに入力してデジタル化する作業を行わなければならず、オフィスワークの生産性を低下させている。

（４）情報の孤島

情報交換を行うインタフェースを持たないために情報の共有化が図れず情報が有効活用されていない問題。

このような弊害をもたらす原因として社会的側面から見ると、競争相手との差別化や優位性の確保、顧客の囲い込みといった企業競争力の強化を目的として現在の環境が構築されてきたといえる。資本関係を前提とした企業系列や特定の企業グループ、業界ごとに、独自のデータフォーマット、規格、プロトコルといったクローズドな形でネットワーク構築がなされてきた。このため、異なるグループ間、業界間でのネットワークの接続が困難であり、接続のために膨大な追加投資が必要である。また、結果的にこれらの負担費用が製品の価格に反映されるため、取引上弱い立場にある企業（多くは受注者）の取引参入が難しくなるばかりでなく、すべての企業において解決すべき問題となっている。

２．２．２　　データフォーマットとしてのＨＴＭＬの限界

現在、一般的に良く利用されているデータフォーマットはCSV形式3、バイナリデータ4、そしてHTML5である。CSV形式はテキストデータであり、データとデータの間をカンマで区切って表示しているだけであるため簡潔で見やすく、またデータ転送量も最小限で済むというメリットがある。また、表計算アプリケーションなどの汎用フォーマットの一つとして、データ出力、データ入力機能が備えられているため汎用性が高く、広く普及している。しかし、データの順番や意味を互いに理解している企業同士、アプリケーション同士でしかデータ交換を行うことができない。データを扱う人間から見ればデータの内容から意味が判断できるかもしれないが、コンピュータはデータの意味を理解することはできない。また、バイナリデータも同様にアプリケーションに依存したフォーマットである。

HTMLはデータの表現形式を規定したレイアウト目的のデータ記述言語である。HTMLはもともとインターネット環境で使用されること、仕様が分かりやすく単純であること、さまざまなプラットフォーム上でデータを表示できる世界共通の言語などの特徴を持ち、WWW6によってインターネットを爆発的に普及させるひとつの要因になった。

そのため、現在ほとんどのデータがHTMLの形式でWebに蓄積されている。HTMLはCSV形式やバイナリデータとは異なりデータに属性情報を付け加えるタグを使用して表示規定を行っている。しかし、そのタグはデータをどう表示させるかという属性情報のみを付加しているため、データ交換フォーマットとしては適していない。情報産業業界は『良いものが普及するのではなく、普及したものが良いものだ』という世界である。そのため少しでも早く普及したものが、この世界の標準となる。HTMLはインターネットの普及をもたらすものとして、いち早く普及したが、データ交換という観点から見ればフォーマットとして限界がある。

CSV形式、バイナリデータ、HTMLはたとえばデータに変更が発生した場合、データに対し順番でしか意味付けを行っていないので、それぞれシステム、アプリケーションに対し変更を行わなければならず、コストがかかる。その点、データそのものに意味付けを行うタグを用いたデータフォーマットならタグに対して検索、処理を行うため、そのリスクを回避できる。

２．３　ＸＭＬの必要性

これまで述べてきたように、これからは今まで行っていた取引においてEDIを利用してコスト削減、効率化をすすめるだけではなく、eMarketsという形で新規顧客を開拓し、最適な取引を行っていかなくてはならない。また取引形態も長期的、固定的な取引から短期的で柔軟性のある取引へと移行しつつある。今後さらにB2Bの占める取引の割合は増加することが予想され、データ交換の必要性も明らかである。

このような状況の中で必要とされるのが新しい標準化されたデータ交換フォーマットである。そのデファクトスタンダードとして現在最も期待されているのが本研究のテーマとして取り上げるXML7である。

XMLはインターネット上でデータ交換をするために作られたメタ言語8であり、またW3C9で策定された標準フォーマットであるため、さきほど述べた問題が解決されることが期待され、これからの商取引の主要フォーマットとして序々に普及しつつある。

第３章 　　ＸＭＬ

３．１　　ＸＭＬとは

３．１．１　　歴史

異なるプラットフォームやアプリケーションの間で確実にデータ交換を行う場合、テキスト形式でデータ交換を行うのが一般的である。しかし、そのデータの意味（例えば会社名なのか、商品名なのか、数量なのか）までは相手に伝えることができない。そこでタグを用いてデータに意味を付加するマークアップ言語が開発されることになり、その標準規格としてSGML10が登場した。

SGMLはデジタルデータの多面的な利用と異機種間でのデータ交換を目的としたマークアップ言語である。コンピュータやアプリケーションに依存した文書処理の形式やレイアウト情報を、データから一切切り離し、文書の内容だけをテキストデータで作成したものである。このことにより、プラットフォームやアプリケーションに依存しないデータ交換が可能になる。またタグの中身はタグにはさまれたデータの意味をユーザが定義して使用することができるため、ある業界やある一定の範囲のみで使用されるマークアップ言語を設定することができるメタ言語でもある。

SGML文書のメリットとして、文書構造や用途に応じた文書設計ができる。データ交換、データ管理が容易になる。システムに依存しないためデジタルデータとして半永久的に保存できる。データが構造化されているためデータ検索が容易になる、などがあげられる。

しかし、実際のところSGMLは一部の政府関係機関や企業しか使用しておらず、広く普及するには至らなかった。その理由として一つは、様々な利用場面を想定して作られているため、仕様が複雑すぎて一般ユーザだけではなくアプリケーション開発者にとっても障害になっていた。もう一つは文書構造の定義やマークアップの作業には膨大な作業量とプログラミングに近い能力が必要であり、また、活用するには作成、編集、プレビュー、印刷などの周辺ツールが必要であった。

そこでインターネット環境だけに利用場面を限定し、ネットワーク回線の能力に適した、小規模で単純な文書の表示だけを規定するHTMLが誕生した。しかし、HTMLも第2章で述べた理由により不具合が生じている。

そこでさらにSGMLのデータ構造の特徴とHTMLの簡易性を引き継いだ新しいマークアップ言語であるXML[11]が開発された。1996年7月ごろからW3Cで新しいSGMLの仕様策定作業を開始し、11月に最初の草案11が公開され、XMLと名づけられる。そして1998年2月にW3C勧告となった。

３．１．２　　特徴

XMLの特徴としてまず情報の意味を表現できるということである。これは、その情報がどういう内容の情報なのかということをタグによって規定できるということである。例えばある情報がタイトルなのか、作者なのかということをタグで規定しておくことで、タグによる情報検索が可能になる。また、XMLはHTMLとは異なりタグを自由に決められるため、ある特定の用途ごとにタグを設定することができる。業界ごとでタグの取り決めを行っておけば、タグによる情報検索、アプリケーション処理が可能となるため、これまで行われてきた曖昧なデータの順番によるアプリケーション処理を行わなくて済むメリットがある。

このタグの取り決めのことをDTD13といい文書型定義と訳される。このDTDによってタグの名前（要素名）、データ構造、出現回数などを規定することができる。HTMLとは異なりXMLではデータ構造をDTDで厳密に規定することによって、入れ子構造をとる木構造のような複雑なデータもテキストデータとして階層的に表現させることができる。これにより情報項目の検索、追加、削除が容易にできる。

二つ目の特徴としてはデータと表現方法を分離したことにある。データを独立させたこととテキストデータであること、この二つによりプラットフォーム、アプリケーションに依存しないデータフォーマットになる。しかし、依存しないといってもどのプラットフォーム、アプリケーションでも対応できる共通のフォーマットであるだけなので、実際、処理を行う際にはそのプラットフォーム、アプリケーションに適した形式で処理させる必要がある。そこでXMLデータをその独自の利用可能な形式に変換するソフトウェアが必要になってくる。そのソフトウェアをXMLパーサ（もしくはXMLプロセッサ）という。（図５）XMLパーサはもう一つ、XML文書を文法的に正しいかどうか検証する機能をもっている。最近ではInternet Explorer5.0等のブラウザがその機能を内蔵する形になってきたのでエンドユーザはパーサを意識することはほとんどない。

　　　　　　　図5　XMLパーサの役割

XMLパーサを利用する際に使用するAPI14として代表的なものにDOM15とSAX16がある。DOMはひとつながりのXML文書をツリー構造に階層化された、プログラムやアプリケーションから操作可能な対象物（DOMオブジェクト）に変換するものである。そこではじめてアプリケーションはDOMオブジェクトとなった要素や属性に対して、DOMのAPIを通してアクセスできる。このような仕組みによりプラットフォーム、アプリケーションに依存しないデータ交換が可能になる。

もう一つデータと表現方法を分離したことによる特徴として、XML文書に独自の処理をさせることができる。これは目的、用途、対象者に合わして表示させる内容、表示方法を選択することができることである。例えば一般ユーザに対しては分かりやすい、なじみやすい表現にしたり、携帯電話に表示するときは情報量を少なくしたりといった具合である。しかももとのコンテンツとなるXMLデータは一つで、表示させるスタイルシートを用途によっていくつか用意するだけで良い。スタイルシートにはCSS17、XSL18、XSLT19などがある。（図６）

　　　　　　　　図６　XSL、XSLTの役割

３．２　　ＸＭＬの優位性

データ交換フォーマットとしてXMLはCSVやHTMLに比べ、絶大な優位性が期待できる。そのメリットを三つ、以下に示す。

（１）現存資産の維持

現在、各企業が最も良く利用しているデータ管理はRDB20を利用したデータベース管理である。RDBはデータの検索、削除、更新などが容易にできるSQL21を備えている。SQLを用いることで、表の定義やデータ操作、関係演算など、RDBに関するほとんどの操作を機械可読なテキストとして記述でき、これにより、データベースそのものと、データベース管理システムとの関係を抽象化することが可能となる。

このRDBの構造はXMLの構造と似ており、繰り返しの階層的なデータ構造となっている。RDBからXMLへの変換を考えた場合、このデータベース名、テーブル名、列名をそのままXMLのタグ名に置き換えて変換することが可能であり、これまで利用していたデータをそのままXMLへXMLパーサを通して変換してデータ交換を行うことができる。（図７）

また、新規取引先のアプリケーションと対応していなくても、今まで使用していたシステム、アプリケーションを変更することなくXMLを導入することが可能になり、他システムとの接続性が高い。

　　　　図７　RDBからXMLへのマッピング

（２）柔軟性

これまではシステムの導入、拡張、変更を行うにあたり、今まで接続されていた他のシステムとの連携を第一に考えなければならず、システム設計に制限があった。しかし、XMLを導入することにより、他のシステムとの接続を考えなくて済むため、独自のシステム設計を行える。このことからシステムの変更や拡張に対する柔軟性が高いことがいえる。

（３）低コスト、リスク回避

XMLの技術や仕様はインターネット標準であるため無償で入手でき、また、まだ十分とは言えないが、あらゆるベンダがXML製品、XML対応ツールを開発しているため低コストでの構築、運用が可能である。さらに現在稼動しているシステムを拡張、変更することなく、XMLツールやアプリケーションを追加できるため、余計なコストをかける必要がない。

３．３  ＸＭＬの実用例

現在、XMLをB2Bで活用しようと様々な団体が標準化をすすめている。その代表的なものにRosettaNet[12]、OBIConsortium[13]、eCo Framework[14]、ebXML[15]、BizTalk Framework[16]などがあり、日本ではResettaNetJapan[17]が標準化をすすめている。

その中でたくさんの応用技術が生まれてきている。例えば、HTMLの後継として期待されているXHTML[18]、地理情報システムに活用できるG-XML[19]、数式用のMathML22[20]、マルチメディアの統合に使用されるSMIL23[21]などがあり、これからもXMLに準拠した技術、仕様は数多く出てくる事が予測される。その中で一つ電子カルテの標準仕様として研究がすすめられているMML24について触れる。

MMLは医療情報交換規約と訳され、異なる医療機関、または電子カルテシステム間で診療データを交換するための規約である。これまでの電子カルテシステムは紙のカルテ（診療情報）をデジタル化し、管理するだけのシステムであった。しかし、それでは一つの施設内だけの情報にとどまり、他の施設では参照することができず再びカルテを作るために再検査しなければならなかった。そこである単一のデータフォーマットを使用しデータ交換することで、データの有効活用を図ろうと考案されたフォーマットがMMLである。

1995年5月に宮崎で開かれたSeagaia Meeting（日本医療情報学会電子カルテ研究会）でMMLの元となるアイデアが提出され[22]、そのあと厚生省電子カルテ開発プロジェクト[23]、電子カルテ研究会[24]に継承されている。当初、MMLはSGMLの技術を用いて策定、研究がなされてきたが、MML2.21[25]からXMLに準拠している。現在では開発母体をMedXMLコンソーシアム[26]に移し、MML2.3[27]を公開している。

電子カルテは文字の情報だけでなく、レントゲン写真やビデオなどの画像や音声も記録できるため、より確かな分かりやすい形式で保存、管理ができる。そのデジタルデータを施設間、医師同士、スタッフ間で情報交換ができるため、重複検査がなく、医師、患者両者にとってメリットがある。また、MMLをデータベースとして利用することで、より限定した検索が可能になり、患者側は自分の診断状況を情報開示という方法で知ることができる。例えば、旅先で病気になった場合でも、近くの病院で自分のカルテが参照でき、適切な診断が受けられるということも考えられる。

今後さらに医療技術の向上とともに、世界レベルでの利用やネットワークを利用した治療、診断と可能性は広がっていく。そこでもデータ交換のフォーマットはXMLであることは間違いないだろう。

第４章 　　ＸＭＬの利用方法

４．１  利用方法の考察

これまではB2B取引におけるXMLの意義を説明してきた。第4章からは具体的なXMLの利用方法を考察していくこととする。

XMLはそれ自体、何の操作性もないデータフォーマットである。XMLを利用するためには、XMLで書かれた情報を操作する環境を組み合わせなくてはならない。論理的にはどのプラットフォームでも、どのプログラム言語でもそのXMLを読みこみ、また変換させるツールさえあれば、利用可能である。しかし、実際ではプラットフォームやプログラム言語によって、ツールが不充分であったり、対応が遅れていたりと今すぐ利用できるほど満足いくものではない。

そこで本研究ではXMLを利用するにあたって、もっとも効果的で有益性を検証できるであろうと考えられる方法をとる。その方法とは研究目的でも触れたようにシステム構築を行うことである。XMLの特性から、ネットワークを通した異システム間でのデータ交換を行うシステムを構築する。システムはWebを利用した方法であり、実際、データ交換を行い、検証することを目的とする。また、データ交換を行うだけではなく、その受け取ったXMLデータをXMLパーサを利用して、独自の形式に変換して活用するところまで行う。

システムの型はクライアント／サーバ型、リクエスト／レスポンス型をとる。これはWebを利用する場合、もっとも良く利用されている型で、クライアントからの要求に対し、サーバ側で処理し、結果だけ返す。これには二つのメリットがある。一つはクライアントを特定しないこと。クライアントはただ結果をブラウズする機能さえ持ち合わせていれば良く、特別な処理を行う機能やアプリケーションを追加する必要がない。クライアントを特定しないことによって、より大規模なより広範囲なシステム構築が可能になる。もう一つは管理、運用が容易になる。システムの変更や機能拡張を行う際にサーバを一台だけ変更すれば良く、システム管理、保守にコストをかけずに済む。大規模でネットワークを利用するシステムでは、このアプリケーションサーバの利用が効率的である。

次にシステムに採用する言語、技術を策定する必要がある。策定基準にはシステムの規模やデータ量が関わってくるが、ここでは純粋にXMLとの相性、効率性を考慮する。開発言語の選定としてPerl、Java Scriptなどのスクリプト言語やC++、Visual Basic、Javaなどの主要なプログラム言語はすでにXMLパーサのインタフェースを持っている。そのため、使いやすさの程度差はあるが、ここでは言語による策定は検討せず、開発技術について検討してみる。

（１）CGI（Common Gateway Interface）

プログラムの処理結果に基づいて動的に文書を生成、送出する仕組みであり、リクエスト／レスポンス型の技術である。しかし、CGIは小規模なシステム開発に向いており、アクセス数の増加によりサーバに負担がかかってしまい、安定したシステム構築にはリスクが高い。また、複雑なセッション管理やサーバサイドでロジックを用意するにはそれなりの技術が必要になってくる。

（２）ASP（Active Server Pages）

動的にWebページを生成するWebサーバの拡張機能の一つであり、VBScriptやJava Scriptで記述することができる。ASPはマイクロソフト社のWebサーバであるIIS25にしか対応しておらず、マルチプラットフォームを謳うXMLの開発に適しているとは言い難い。

（３）PHP（Hypertext Preprocessor）[28]

ASPと同じく動的にWebページを生成するWebサーバの拡張機能をもつスクリプト言語である。XMLのサポートや各種データベースとの連携に優れていることから近年普及しつつある。プログラム構文はC、Java、Perlを準用したもので、仕様、プログラムはオープンソースソフトウェアとして無償で入手することができる。PHPの特徴として一つは言語選択の自由度が高いことである。このため技術者の確保はしやすいが、その反面、管理が難しくなり、管理者の入れ替わりの時に問題になる可能性がある。二つ目の特徴は言語仕様が簡素で柔軟性があることである。中小規模のシステム開発では効果が期待できるが、大規模システムの開発では返って欠点となり得る可能性がある。また、そうなるとPHPだけで補えない部分を他のシステムで分散しなければならず管理面で問題が残る。

（４）JSP（Java Server Pages）[29]

ASPのJava版であるJSPはPHPと比較して、開発言語はJavaのみであり、また、しっかりとした言語仕様、たくさんのクラスライブラリが準備され、充実した開発環境が整えられている。ロジックとデザインを分離したことから大規模システムでの効果が期待できる。また、Javaの特性として、インターネット対応であること、プラットフォームに依存しないこと、低コストで再利用性があるといったXMLと良く似た特徴を持っているだけではなく、実際、XML関連の技術、仕様はJavaが一番強くサポートしている。

以上のことから、Javaの生産性、移植性、汎用性を考慮した上でJSP、およびJavaのサーバサイド技術を利用したシステム構築という形で研究を実証していくこととする。

４．２　　Javaとは

Javaとは1995年にSun Microsystems社が発表したオブジェクト指向言語である。Javaは当初、クライアントサイドで動くJavaアプレットとして普及した。文字や絵だけのブラウザにJavaアプレットを組み込むことで、見るだけのページから操作できるページにすることができた。しかし、インターネットの普及とともにJavaの特性が見直されるようになった。

Javaの大きな特徴はインターネット環境で利用されることを目的とした技術、仕様を備えていることである。現在、インターネット上には膨大な数のコンピュータがあるだけではなく、その種類も様々である。電子メールやWWWはどのコンピュータでも利用できる仕組みのため、今日のような普及につながっている。このようにどのコンピュータでも利用できる環境を作ることが重要になっている。電子メールやWWWは単にデータのやりとりをしているだけにすぎないが、Javaはどんなコンピュータでも実行できるプログラムを書くことができる。これがJavaの最大の利点である。この特徴を実現しているのがJavaバーチャル・マシンという考え方である。（図８）JavaプログラムはJava環境（JavaVM）を搭載しているコンピュータなら、どのコンピュータでも動くようなJava実行ファイルに一度コンパイルされたあと、そのコンピュータ独自の形式にさらに変換される。このため処理性能が他のプログラム言語に比べ劣っていたが、1999年春に発表されたJava 2 26より処理性能が改善され、またハードウェア能力の進化なども重なって、今では他プログラム言語と変わらない処理性能を発揮する。

　　　　　　　　　　　　図８　JavaVM

「Write Once, Run Anywhere」（一度書けば、どこでも動く）の特徴を生かしてJavaはミドルウェアとしての役割を果たすことも可能である。Javaのみでシステム構築するよりも、いくつかの安定したソフトウェア製品を組み合わせ、Javaで操作させる方が生産的でコストも削減できる。また、開発者は接続先がどのメーカーのどんな仕様のコンピュータか意識せずにプログラムを書くことができるため、様々な種類のコンピュータがネットワーク上でそれぞれの得意な処理を行い、ネットワーク全体で一つのシステムとして稼動するネットワークコンピューティングが今後進むことが考えられる。その主要な技術をJavaは備えている。例えば業務ロジックを部品化し、ネットワーク環境で実行できるようにしたEnterprise JavaBeans[30]、異機種、異言語間のプログラムをつなぐCORBA[31]、IIOP[32]や周辺機器、家電など様々な機器をネットワークを通じて接続し、相互に機能を提供しあうための技術仕様Jini[33]などがある。

４．３　　サーバサイドJava

Java 2 の主要技術としてサーバサイドでのJavaアプリケーション開発技術をサーバサイドJavaという。JSPもサーバサイドJavaのひとつであり、その他、サーブレットとJavaBeansで構成される。クライアントからWebサーバへ処理要求が出されると、まずサーブレットが呼び出され、その要求をJavaBeansへ渡す。JavaBeansがデータベースサーバなどと連携して処理を行い、その結果をJSPへ渡し、JSPがHTMLファイルに変換してクライアントに返すといった一連の処理を繰り返す。（図９）Javaはサーバ上で実行され、ネットワークを通るのはHTMLベースの処理要求（リクエスト）と結果送信（レスポンス）のみのため定型的な大量の処理に向いている。

CGIやASPなどと大きく異なるところは、デザインとロジックが分離しているところである。CGIやASPは一つのプログラムに処理プログラムと表示プログラム（HTML）を書きこむが、システムを変更、拡張する場合、Webデザイナとプログラマが同じプログラムを操作するので管理面で問題が起こりやすい。サーバサイドJavaではJavaBeansがロジックを担当し、JSPがデザインを担当する。サーブレットはそれらを制御するコントローラの役割を果たすため、管理が行いやすく、Webデザイナ、プログラマ共にお互いを気にせずにプログラムを操作できる。

　　　　　　　　図９　サーバサイドJava

第５章 　　システム構築＊

５．１　　目的

①　研究の実証を行う

サーバサイドJava技術を利用したシステム構築を行い、また、データ交換フォーマットとしてのXMLの利用価値を実際にデータ交換することによって検証する。

②　問題の解決、

現に起こっている問題を調査、分析し、システム構築、アプリケーション開発を行うことによって、その問題を解決することを二つ目の目的とする。システム分析を効果的に行うため、身近に起こっている問題を取り上げ、実際、利用してもらうことを想定したシステム構築を行う。

③　システム開発技術の習得

プログラミングを行うだけでなく、調査、分析からシステム要件、実装方法を考察し、テスト、保守、運用に至るライフサイクル全般の流れをつかむことでシステム全体を考える能力を養う。また、それに伴う技術、多面的な洞察力を身につける。

５．２　　概要

　　５．２．１　システム化要件定義

①　問題の調査、分析

当ゼミの研究体制は24時間、自分の都合の良い時間に研究室を利用できるシステムになっている。ゼミ生全員、研究室に集合する時間は「演習」の授業が週に一時間あるだけである。教官は大学での仕事があるため、常に研究室に居るわけではなく、ゼミ生個人の研究進捗状況を把握することが難しい。また、そのような状況であるため十分な教育が行き届かない恐れがある。また、ゼミ生同士でも研究取り組みに差が出てくることが懸念され、コミュニケーションを蜜に取り合う必要がある。

そこで以下の三つの要求が考えられる。①ゼミ生個人の研究進捗状況を把握するツールが欲しい。②研究室の状況を手軽に確認するための情報提供ツールが欲しい。③研究室での雑用、所用を遠隔地にいてもリアルタイムに指示を出せるようにしたい。

これらを総合的に分析すると、「遠隔地に居ても、手軽に研究室の状況をリアルタイムに把握できるツールを利用して、連絡、コミュニケーションを取れるシステムを開発していく必要がある。」とまとめることができる。状況把握の材料としてはいろいろ考えられるが、本システムでは「研究室に誰が居るか」という情報のみにしぼって開発をすすめていく。また、コミュニケーションツールとしてはＥメールや電話を利用することで十分対応できるので、本システムではそのための情報（Eメールアドレス、電話番号）を提供することだけにとどめる。

②　システムの特徴

・Webを利用したシステム

・サーバ／クライアント型システム

・リクエスト／レスポンス型システム

・携帯電話から利用できるサービスの提供

・リアルタイム処理

③　要旨

具体的なシステムの内容としては、入室、退室時にWebから操作し、その情報をリアルタイムでWebで公開するシステムである。ブラウザによって表示させる内容、表示方法を変更させるJSPを用意する。それらはすべてHTMLファイルで配布する。XMLで配布する場合、そのXMLを表示させるXSL、またはXSLTも加えて配布しなければならず、また、XMLに対応していないブラウザもあるため、このような方法をとることとする。

扱う情報はゼミ生の個人情報と入退室時間の履歴情報となるため、データベースを用いたデータベース管理システムを利用する。XMLでのデータ交換はデータベースの情報を使用して行う。そのためデータベースとXML間をJavaを用いてパースし、それぞれに変換させる必要がある。

５．２．２         　　システム構成

サーバの構成はWebサーバにJSPコンテナを組み込んで使用する。本システムではサーブレットを使用せず、JSPとJavaBeansのみの構成でシステム構築を行う。理由はサーブレットを用いるほど複雑なプログラミングではないということとプログラム本数を減らすことで、すっきりしたシステム構造をとることができることからである。

クライアントからのリクエストをまずJSPが受け取り、JSPに埋め込んであるロジックをJavaBeansがデータベースと連携して処理を行う。その結果をJSPで加工して、ブラウザに合わせた情報をクライアントに返す。

　　　　　　　　図10　システム構成図

５．２．３　　開発環境

XMLパーサはXerces1.2を選択した。XercesはApache XML Project27[34]が提供するXMLパーサでJAXP1.1に準拠している。また、XML 1.0、XML Namespaces、XML Schema 1.0、SAX 2、DOM Level 2をサポートしている。JAXP28[35]はSun Microsystemsが提供するXML文書を操作するAPIの統一した仕様である。これまでJavaでのXMLの扱いについては、特に標準となる仕様がなく、SAXやDOMの仕様に従って操作を行うことのできるライブラリが、各ベンダから提供されていた。このことは、当然ながら、コーディングにベンダ依存性をもたらしていた。しかし、JAXPで仕様を統一することによってベンダ間の依存性をなくし、ベンダによる実装の違いを吸収できる。

サーバOSにはRed Hat Linux 7.1Jを選択した。これはRed Hat社がディストリビュートするLinuxである。使用ユーザが多いことに加え、1998年、IntelやIBMなどの出資を受けたこともあって、Linux関連企業の中でも知名度は高い。RPM29と呼ばれる独自のパッケージ管理システムによる、システム管理の単純化を図ることができる。

WebサーバはこのRed Hat Linux 7.1Jに標準装備されているApache　1.3.15である。ApacheはUNIX系OSやWindowsで動作する。Apacheはフリーソフトウェアとして無償で公開され、世界中のボランティアのプログラマたちの手によって開発された。誰でも修正・再配布することができる。現在では独立したWebサーバで、世界で最も普及しているWebサーバである。

JSPコンテナとはWebサーバに組み込む形で、リクエスト／レスポンス型システムのサービスを提供する。具体的にはサーブレットの維持管理、HTTPの実装、セッション管理などを行う。そのJSPコンテナにはTomcat 3.2.1を採用した。TomcatはThe Jakarta Project[36]がリリースするサーブレットコンテナ（JSPコンテナも含む）である。開発にはApacheプロジェクトメンバー、Sun Microsystems、IBMなど複数のベンダが加わっている。

データベースにはPostgreSQL 7.1[37]を採用した。これは主要なUNIX系OSで動くフリーのRDBMS31であり、フリーのデータベースの中では比較的高機能で、また実績、信頼性が高い。PostgreSQLはJavaプログラムからRDBへアクセスするためのAPIであるJDBC[38]を提供している。JDBCを利用することで、データベースの種類によらない汎用性の高いプログラムを開発することが可能となる。

５．２．４　　機能

本研究の目的でもある「XMLの有効性を検証」するため、システム機能としてXMLフォーマットでのデータ交換を行う。一つはXMLデータを入力する機能である。他システムからXMLデータを受け取り、そのXMLデータをパースし、データベースと照合、更新を行う機能である。二つ目はXMLデータの出力の機能で、JSPファイルでXMLデータを出力し、配布する。

システムの機能はこの他に、入退室状況を把握できる閲覧機能、入退室操作を行う変更機能の全部で四つの機能を備える。

その他、セキュリティ面を考慮し、クライアント側からのアクセス時に認証作業を行う機能を付け加える。システムを使用するグループで、一意のパスワードを使用して認証を行う簡単なものである。

①　閲覧機能

クライアントから要求があった際に、その都度データベースの情報を抽出し、HTMLファイルで研究室の在室状況をクライアントに返す処理を行う機能である。まず、クライアントの通信媒体を選択するHTMLファイルを返し、その選択されたブラウザによって、サーバサイド（JSPファイル）で表示内容を変換する。選択ブラウザはInternet ExplorerやNetscapeなどの一般的なブラウザに対応するパソコン用と携帯電話用の二種類を用意する。それぞれのJSPファイルを準備し、データベースからデータを取得するJavaBeansからの結果を元にHTMLファイルに変換し、クライアントに返す。パソコン用のJSPファイルは現在の日付、全員の名前、入退室状況、入退室時間、携帯電話番号を表示し、メール送信リンクを備える。携帯電話用のJSPファイルはブラウザの表示能力を考慮し、現在の日付と入室者の名前だけを表示させる。

②　変更機能

研究室に在室しているかいないかを各個人、入退室の際にWebよりデータベースに対してデータの更新を行う機能である。入退室操作を行うためまず、JSPファイルより入退室する人と入退室の選択を行う。このJSPファイルはJavaBeansによりデータベースの個人情報から名前を取得し、リスト形式で人の選択を行う。その情報を元にJavaBeansからデータベースへ履歴テーブルのレコード挿入を行う。もし、在室時に入室操作を行った時、または不在時に退室操作を行った時はエラーメッセージをクライアントに返すエラー処理を行う。それ以外は入退室した人の名前、時間、入退室の確認メッセージをクライアントへ返す処理を行う。

③　XML変換機能

要求があった場合、必要データを選択した上でデータベースの情報をXMLファイルに変換し、クライアントへ返す処理を行う機能である。まず、XMLファイルで取得したい人とデータ（個人情報、もしくは履歴情報）を選択する。この場合も変更機能と同じJavaBeansを利用してデータベースの個人情報から名前を取得し、リスト形式で人の選択を行う。データの種類によってそれぞれのJSPファイル、JavaBeansがデータの抽出、XMLファイルへの変換を行い、クライアントへ返す。もし、データ選択の時点で誤りがあればエラーメッセージを返す処理を行う。この機能はXMLファイルでの出力の検証を行うための機能である。

④　データ照合、更新機能

他データベースとのデータ統合を目的としたデータ照合、更新を行う機能である。これも同じくXMLをデータフォーマットとして利用する。他データベースとのデータの整合性を保つため、まずXMLフォーマットでデータを取得する。それを本システムのデータベースの内容と照合し、変更されている部分のみ更新作業を行う。他データベースのデータは必ず正しものとして処理を行う。ここで行うデータとは個人情報のことをさす。また、この機能のみリアルタイム処理ではなく、バッチ処理を行う。他システムとのデータ交換を行うため、そのシステムとの間でDTDを取り決めなくてはならない。そのDTDは資料1に示す。

また、他データベースと本システムのデータベースでは一意にレコードが識別できる主キーが異なるため、そのマッピングを行うテーブルを用意する。

５．３　　効果の分析

５．３．１         　　アクセスデータの分析

　集計結果を表１、図11、図12、図13へ示す。

データ件数はシステム設計の段階で多くて一日100件程度と見積もっていたが、多い日で140件弱のアクセスがあった。また、少ない日で60件程度とばらつきが目立った。授業のため研究室に集まる木曜日がやはりデータ件数が多い。時間別では午後から深夜にかけてが多く、早朝から午前中は少ない結果となった。特に夕方にアクセスが集中している。これは授業が午後に行われることに加え、一回の入退室操作で約三回から四回、JSPファイルへアクセスするため、このような結果になったと推測できる。

集中的にアクセスが増加した時も、処理が遅くなったり、異常が発生したりということはなかった。しかし、一時間に最大で24件と負荷をかけているというにはまだ不充分であるため、サーバ負荷に耐えうるかどうかという点はデータ不足である。サーバ側の処理速度はデータベースの更新レコード数が増えるごとに遅くなることが分かった。現在（2002年1月23日時点）で履歴情報テーブルは342レコードあり、閲覧機能を操作するたびに、すべてのレコードを検索しているので、そのような結果になったのではないだろうか。処理速度を上げるには定期的に古いレコードを削除する必要がある。

操作別で見ると一番多いのはパソコン用閲覧操作であった。注目すべきは全体の21％を占める携帯電話用閲覧操作である。PC用閲覧は入退室操作の確認で行ったり、Webを見るついでに操作したりとあまり意識せずにアクセスする場合がある。それを除けば、携帯電話から閲覧する場合の方が多いと考えられる。携帯電話からの場合は意識的に操作を行うため、本システムを利用する携帯電話からの需要が高いことがうかがえる。携帯電話からの需要が高い理由は、一つに携帯電話の普及がある。もう一つは携帯電話からWebへアクセスする機能が充実してきているため、一般ブラウザに劣らない操作、表示が可能になってきているためである。

当初、携帯電話からのアクセスは付属的なものとして考えて、システム設計を行っていたが、アクセスデータを見る限りでは、携帯電話へのサービスの向上を考慮して、システム拡張を行っていく必要がある。具体的には携帯電話からでも入退室操作ができるようにしたいが、現在ではNTTDocomoのi-modeしか対応できていない。これは各携帯電話のブラウザの機能に依存するところが大きいため、この問題解決は困難を要する。もう一つの問題は文字コードの問題である。キャリアや各機種によって扱う文字コードが異なるため、文字化けを起こしている。これは文字コードごとに変換を行うJSPファイルを準備することで解決できるが、逆にファイル本数が増え、管理面で負担がかかる。

５．３．２         　　システム効果の分析

システム効果の分析を行うため、アンケートの形式でデータ収集、分析を行うこととする。以下、アンケート実施の概要を示す。

集計結果を表2、表3、図14から図22に示す。

アンケートの集計結果（システムについて）より、「表示内容」、「質問事項の分かりやすさ」、「見やすさ」、「色、配色」のデザイン面、表示面については良い評価を得ることができた。特に「必要性」については高い評価が得られ、アクセスデータにも、その評価は反映されていることが分かる。システム利用者に便利さを提供できていることから、システム構築の二つ目の目的である「問題の解決」は達成できたのではないか。

しかし、「入力のしやすさ」の項目でも分かるように、操作性については改善すべき点があることが分かる。特に選択方法による操作性の悪さを指摘する声が多かった。入退室操作とXMLデータ取得操作時にリスト形式で選択を行っているが、この時に複数人選択できるチェックボタン形式やラジオボタン形式で選択できれば、操作性の向上につながる。また、入退室操作を行う際に、三回程度のページ移動、アクションが必要となっているため、もっと操作を簡略化する必要がある。

仕様書については初めて作成したが、特に目立った意見はなく、それなりの評価を得ることができた。

セキュリティに関しては、第二回特殊研究発表（2001/12/27）で意見を出されたところであり、また今回、特に意識せずにシステム設計を行ったところでもある。しかし、本来はシステム構築を行うにあたり、注意すべきポイントの一つであり、また、本システムでは個人情報を扱っているため、情報流出の危険性を考えれば、セキュリティの重要性は明らかであった。今後、最優先にセキュリティの強化を図る必要がある。

最近のセキュリティホールに対する攻撃の傾向として、無差別な攻撃、Webアプリケーションの脆弱性を狙った攻撃が増加している。現在のIPアドレスはシーケンシャルな数字の並びによって、表現されているので無差別な攻撃が行いやすい状況である。また、セキュリティホールを狙った悪質なウィルスも最近さらに増えてきている。（Sadimind(2001/5)、CodeRed(2001/7)、Nimda(2001/9)等）各ベンダやIPA32[39]が発表しているセキュリティ情報は常に気にかけておく必要があり、新しく出たセキュリティパッチを必ず当てておくことが重要である。また、安易な認証キーを使用しない、セッションごとにクッキーの値を変える、不要なファイルは置かないなど、システム設計者、管理者共にセキュリティホールを作らないことを心掛ける必要がある。

第６章 　　考察、まとめ

　　　６．１　XMLとJava

　B2B取引が多くなるにつれ、業務システムをWebアプリケーションとして構築する事例が増えてきている。そこで必然的にデータ交換のフォーマットをXMLで行うことが今後さらに増えると予想される。つまり、Webアプリケーション開発技術とXMLはこれから密接に関わっていかなければならないのである。現在のところ、XMLは中間フォーマットとして利用されていくことが最も現実的であろう。なぜなら、「3.2 XMLの優位性」でも述べたように、これまで投資を行ってきた現存資産との連携を利点とするXMLは、まず現在利用している資源を取りこむ形で普及していくことが予想されるからである。中間フォーマットであるため、システム利用者や一般ユーザの目からは直接触れることはないが、システム開発者、または経営者にとってはデータの有効活用という点でコスト削減などのメリットがある。その恩恵は目に見えない形でシステム利用者や一般ユーザも享受するであろう。

　中間フォーマットであるからには現存資産との受け渡しを行わなくてはならない。その受け渡しとしてXMLパーサを利用することは先に述べた。基本的にはXMLパーサさえ備えていれば、XMLを操作できる。現在、主要な言語はこのXMLパーサを備えており、XMLデータを扱うという点ではさほど問題はない。しかし、実はそれだけでは足りない。XMLには多くのスキーマやXMLをベースにした、たくさんの技術が登場している。これらを利用するにはXMLパーサだけでは対応できない。それらを扱うためのAPIやライブラリが必要である。そして、現在それらの多くはJavaによって提供されている。

　今回、開発言語としてJavaを選んだのもそのことからである。今回のシステムでは、XMLデータをパースする機能のみを実装したため、XMLの付加価値の部分のメリットは実証できなかったが、データ交換という点ではXMLの有益性を示せたのではないか。他データベースとの整合性を保つJavaプログラムをコーディングしたわけだが、XMLをデータフォーマットとして利用するメリットは大きく二つあることを感じた。一つはタグによるデータ検索ができるということである。もう一つはタグの出現頻度、回数、順番を規定するDTDを取り決められるということである。本研究ではニつのシステム間でのデータ交換を行ったが、もし、不特定多数のシステム同士でのデータ交換を行うならば、このDTDに従ってパースを行うプログラムを一つ準備すれば良く、その有益性は明らかである。DTD規定の善し悪しによっては、その業界のデータ交換の機能性や効率性を大きく左右することも考えられるため、DTD規定作業は十分考慮する必要がある。

　　　６．２　XMLの今後

これまでXMLの有益性について、システム構築という手法を取り、検証をすすめてきた。実際、JavaでXMLをパースし、入出力部分をプログラミングしてきた。その結果、感じ取れたことは、非常に曖昧な表現になってしまうが、使い方次第であるということだ。

XMLの優位性は第３章で述べたとおりであり、XMLがこれからのB2B取引の主要技術として利用されていくのは間違いないであろう。実際、XMLを利用したeMarketsも存在しており、その可能性も実証されている。しかし、未だXMLへ移行したいと考えている経営者は数多いが、実際のところ、導入までには至っていない。その理由はXMLが成熟していないということである。各ベンダが提供するXML製品は、まだ十分とは言えないが、XML利用拡大の流れに乗り、これからさらに充実していくと思われる。しかし、最も肝心な標準仕様が定まっていない。XML1.0やXSLT1.0などの基本的な仕様は勧告されているが、それに付随する仕様がなかなか決まらない状況である。XMLデータのクエリ言語であるXQuery1.0やXPath2.0、XSLT2.0、自身のアップデートであるXML1.1などは未だ策定中である。今やXMLベースの技術は非常に重要な存在となっているため，検索方法やデータの操作方法といったXMLのハイレベルな技術の定義に関して，全員の意見を一致させるのは非常に難しい。そのため、「XMLの各種規格の間で、同じようなことを実行する方法がそれぞれ異なる」といった重複の問題が数多く生じてしまっている。XQueryやXPathの仕様はXMLデータベースの製品仕様に大きく関わってくるため、XML製品化が進まない一つの原因となっている。

また、これまでのクローズドなつながりで顧客の囲い込み経営を行ってきた企業や、特定企業同士の取引で経営を行っている企業にとって、これまで莫大な投資をして積み上げた関係を崩すほどのメリットは、今のところ見当たらない。また、XMLを利用してデータ交換を行う際は、当然ながらデータベースとの関連性を考慮しなければならない。データベースの特性、またはデータベースの操作を行うドライバのXMLデータへの対応次第によっては、かえって使いづらくなったり、コストがかかったりする。　　　XMLデータベースはリレーショナルデータベースに十分, 対抗できるほどの技術的強みを備えていない。管理機能、相互運用性、プログラミングの容易さ、管理の容易さなど、リレーショナルデータベースが提供する数々の利点が、XMLデータベースには欠落しているのである。さらに、クエリ構文のXPathは、データのグループ化、ソートおよびサマライズをサポートしていない。遥かに豊富な機能を提供するXQueryも、前述のとおりまだドラフトの段階である。XQueryの仕様が正式に確定したとしても、更新、挿入および削除の各機能はサポートされない。現在、製品化されているXMLデータベースはいずれもベンダ独自のクエリ言語、およびプログラムインタフェースを採用しているため、XMLデータベースの早期採用ユーザにとっては、これらの問題が解決するまでの間、余計なコスト負担を強いられることになる。

しかし、これは今現在のことであり、3年後、もしくは5年後はどうなっているかわからない。確かに現在では、XMLによるB2B取引の普及はすぐに成果は出ないかもしれない。しかし、技術的に標準化がさらにすすみ、業界ごとにしっかりとしたDTDを標準化団体によって規定されるのであれば、XMLのメリットを十分生かしたeCommerceが企業の規模、業種を問わず達成できる日もそう遠くはないであろう。

これまでB2Cの分野で成長を遂げているベンチャー企業もeMarketsが普及すれば、B2Bに何らかの形で参画しなければ生き残っていけない。また、これまでIT化に縁のなかった中小企業にしてみれば、より低コストでXML導入を行えるメリットからeMarketsへの参入も可能になる。そうなると、これまでの大量仕入、大量販売の一般的なB2B構造が多種少量、精度（質）の要求、価格競争の構造に変化していくであろう。つまり、企業の規模に関わらず、最適な取引を行うインターネット本来のメリットが生まれてくるはずである。

さらに今後の動向としては、XMLですべてが行えるようにしようという動きがある。データ交換はもちろん、データベース、通信、その他WebサービスをすべてXML化する技術として、SOAP、WSDL、UDDIなどがある。SOAP[40]はネットワーク上のアプリケーション間（オブジェクト間）の情報を交換し合うための単純で軽量なプロトコルの仕様である。DevelopMentor、IBM、Lotus、Microsoft、UserLand SoftwareがW3Cに提案中で、現在は技術ノート（Note）として仕様が公開されている。このプロトコルを表現するための手段としてXMLが利用されている。これは現在、使用しているHTTPやSMTPといったサーバに標準で実装されているプロトコルにバインディングして使用することができるため、低コストで実現でき、また通信相手が限定されないといったメリットがある。また、WSDLはWebサービスのインタフェースを定義するものであり、UDDIは検索を行うためのディレクトリサービスを提供する。

このような形で今後、XMLを意識しなくても自然に利用している環境が訪れる可能性も大いに期待できる。

XMLを取り巻く環境は動きが速い。新しい技術仕様には大抵「XMLに対応」を謳ったものが多く、デファクトスタンダードとしての認識が高くなっている。その反面、実際名前は知っていても、一般的に普及しているとはまだ言えないものでもある。そういった意味で、XMLは使い方次第であるとのべた。使い方によってはB2Bを利用した最適な取引を行うことができる。またその逆もしかりだろう。これからはXMLを使って何をするかということを考えていかなくてはならない。

　　　参考文献　及び　関連リンク

[1] Michael C. Daconta,Al Saganich:”XML Development with Java 2”,ペーパーバック,2000年

[2] Benoit Marchal（著）、安藤　慶一（翻訳）:” JavaとXSLTによるXML応用ソリューション” 、ビアソン・エデュケーション、2001年

[3]池田 実,小野寺 尚希:”ＸＭＬがわかる”,技術評論社,2000年

[4]ＸＭＬ／ＳＧＭＬサロン:”標準ＸＭＬ完全解説”,

技術評論社,1998年

[5]藤田 一郎:”Ｊａｖａがわかる”,技術評論社,1999年

[6]たなか ひろゆき:”はじめてのＪＳＰ＆サーブレット”,

ソフトバンクパブリッシング,2001年

[7]原田 洋子:”Ｊａｖａサーバサイドプログラミング”,

技術評論社,2001年

[8]横井 与次郎:”標準ＸＭＬ＆Ｊａｖａプログラミング”,

秀和システム,2001年

[9]木村 宏一:”ＳＥへの入門システム設計 第２版”,共立出版,1999年

[10]CommerceNet:”CommerceNet”,http://www.commerce.net/,2002年

[11]W3C:”XML1.0”,http://www.w3.org/TR/REC-xml/,2000年

[12]ResettaNet:”ResettaNet”,http://www.rosettanet.org/,2001年

[13]The OBI Consortium:”OBI Consortium”, http://www.openbuy.org/,2001年

[14]CommerceNet:”eCo Framework”, http://www.commerce.net/projects/currentprojects/eco/,2002年

[15]United Nations:”ebXML”,http://www.ebxml.org/,2002年

[16]Microsoft Corporation:”BizTalk Framework”, http://www.biztalk.org/home/framework.asp,2001年

[17]RosettaNet:”ResettaNet　Japan”,

http://www.rosettanet.gr.jp/,2001年

[18]W3C:”XHTML1.0”,http://www.w3.org/TR/xhtml1/,2000年

[19](財)データベース振興センター:”G-XML”, http://gisclh.dpc.or.jp/gxml/contents/index.htm,2001年

[20]W3C:”MathML”,http://www.w3.org/Math/,2000年

[21]W3C:”SMIL1.0”http://www.w3.org/TR/REC-smil/,1998年

[22]吉原 博幸:”電子カルテの現状と将来”, http://www.miyazaki-med.ac.jp/medinfo/Documentation/iHICS_&_future/iHICS_&_future.html,1995年

[23] 財団法人医療情報システム開発センター:” 財団法人医療情報システム開発センター”,http://www.medis.or.jp/,2002年

[24]Seagaia Meeting:” Seagaia Meeting”, http://www.seagaia.org/sgmeeting/,2002年

[25]SeagaiaMeeting:”MML2.21”,

http://www.miyazaki-med.ac.jp/mmlspec910/default.html,1999年

[26]MedXMLコンソーシアム:” MedXMLコンソーシアム”, http://www.medxml.net/,2002年

[27]MedXMLコンソーシアム:”MML2.3”,

http://www.medxml.net/mml23/,2001年

[28]The PHP Group:”PHP”, http://www.php.net/,2002年

[29]Sun Microsystems.Inc:”JSP”, http://java.sun.com/products/jsp/,2002年

[30]Sun Microsystems.Inc:”Enterprise JavaBeans”, http://java.sun.com/products/ejb/,2002年

[31]Sun Microsystems.Inc:”CORBA”, http://java.sun.com/j2ee/corba/,2002年

[32]Sun Microsystems.Inc:”IIOP”, http://java.sun.com/products/rmi-iiop/,2002年

[33]The Jini Community:”Jini”, http://www.jini.org/,2001年

[34]The Apache Software Foundation:”Apache XML Project”, http://xml.apache.org/,2001年

[35]Sun Microsystems.Inc:”JAXP”, http://java.sun.com/xml/jaxp/index.html,2002年

[36]The Apache Software Foundation:”The Jakarta Project”, http://jakarta.apache.org/,2002年

[37]the PostgreSQL Global Development Group:”PostgrSQL”, http://www.postgresql.org/,2001年

[38]Sun Microsystems.Inc:”JDBC”, http://java.sun.com/products/jdbc/,2002年

[39]情報処理振興事業協会:”IPA”,http://www.ipa.go.jp/,2001年

[40]DevelopMentor,International Business Machines Corporation,Lotus Development Corporation,Microsoft,UserLand Software:”SOAP1.1”,http://www.w3.org/TR/SOAP/,2000年

[41]Sun Microsystems.Inc:”Java(TM) 2 SDK Document”, http://java.sun.com/j2se/1.3/ja/docs/ja/,2000年

　　　　　　表1　アクセスデータ

表1　アクセスデータ（つづき）

　　　　　　　　　図11　日付別アクセスデータ

図12　時間別アクセスデータ　

　　　　　　　　図13　操作別アクセスデータ

　　　　　　　　表2　アンケート集計結果

評価基準

（５．たいへん良い　４．良い　３．普通　２．やや悪い　１．悪い　０．わからない）

図14　表示内容（Ⅰ）

図15　必要性（Ⅰ）

図16　入力のしやすさ（Ⅰ）

図17　質問事項の分かりやすさ（Ⅰ）

図18　見やすさ（Ⅰ）

図19　色、配置（Ⅰ）

図20　構成（Ⅱ）

図21　見やすさ（Ⅱ）

図22　分かりやすさ（Ⅱ）

表3　要望、意見（Ⅲ）

資料１　ＤＴＤ

<!-- 個人情報ＤＴＤ -->

<!-- 要素型定義 -->

<!DOCTYPE personal-information [

<!ELEMENT personal-information (kakunin | person+)>

<!ELEMENT kakunin (#PCDATA)>

<!ELEMENT person ((userid | id) , jname , kname , birth , male ,

postal , address1 , address2 , address3 , tel1 , tel2 , mail)>

<!ELEMENT userid (#PCDATA)>

<!ELEMENT id (#PCDATA)>

<!ELEMENT jname (#PCDATA)>

<!ELEMENT kname (#PCDATA)>

<!ELEMENT birth (#PCDATA)>

<!ELEMENT male (#PCDATA)>

<!ELEMENT postal (#PCDATA)>

<!ELEMENT address1 (#PCDATA)>

<!ELEMENT address2 (#PCDATA)>

<!ELEMENT address3 (#PCDATA)>

<!ELEMENT tel1 (#PCDATA)>

<!ELEMENT tel2 (#PCDATA)>

<!ELEMENT mail (#PCDATA)>

]>

資料１の続き

<!-- 履歴情報ＤＴＤ -->

<!-- 要素型定義 -->

<!DOCTYPE history [

<!ELEMENT history (kakunin | person+)>

<!ELEMENT kakunin (#PCDATA)>

<!ELEMENT person (id , jname , data*)>

<!ELEMENT id (#PCDATA)>

<!ELEMENT jname (#PCDATA)>

<!ELEMENT data (date , entrance)>

<!ELEMENT date (#PCDATA)>

<!ELEMENT entrance (#PCDATA)>

]>

資料２　環境構築経緯

OS、Apacheはすでにインストール済みであることを前提にする。

(OS:Red Hat Linux7.1J , Apache:Apache1.3.15)

１．       JDKのインストール

　①JDKのインストール

http://java.sun.com/j2se/1.3/ja/download-linux.htmlより

j2sdk-1_3_1-linux-i386-rpm.binをダウンロードしてインストールを行う。

　  # rpm -ivh jdk-1.3.1.i386.rpm

　②JSDKのインストール

http://java.sun.com/products/servlet/archive.htmlより

　　jsdk2_1-solsparc.tar.Zをダウンローﾄﾞしてインストールを行う。

　　cd /usr/local/src/Manabu-Project/Sun-Java

# tar -xvfz jsdk2_1-solsparc.tar.Z

　③ANTのインストール

　http://jakarta.apache.org/builds/jakarta-ant/release/より

jakarta-ant-1.4-bin.tar.gzをダウンロードしてインストールを行う。

cd /usr/local

# tar -xvfz jakarta-ant-1.4-bin.tar.gz

２．       Tomcatのインストール

　①Jakarta-Tomcatのインストール

http://jakarta.apache.org/builds/jakarta-tomcat/release/より

jakarta-tomcat-3.2.1.tar.gzをダウンロードしてインストールを行う。

cd /usr/local

# tar -xvfz jakarta-tomcat-3.2.1.tar.gz

  ②Jakarta-ServletAPIのインストール

　http://jakarta.apache.org/builds/jakarta-servletapi/より

　　jakarta-servletapi-3.2.1.tar.gzをダウンロードしてインストールを行う。

　　cd /usr/local/src/Manabu-Project/Jakarta

# tar -xvfz jakarta-servletapi-3.2.1.tar.gz

３．各種設定

①パスを通す

　　/etc/profile.d/java.cshのところで

　　setenv PATH "$PATH:/usr/java/jdk1.3.1/bin:/usr/local/jakarta-ant-1.4/bin"

setenv JAVA_HOME /usr/java/jdk1.3.1

setenv TOMCAT_HOME /usr/local/jakarta-tomcat-3.2.1

setenv ANT_HOME /usr/local/jakarta-ant-1.4

　　と設定する。また、/etc/profile.d/java.shのところで

　　PATH="$PATH:/usr/java/jdk1.3.1/bin:

/usr/local/jakarta-ant-1.4/bin"

ANT_HOME=/usr/local/jakarta-ant-1.4

JAVA_HOME=/usr/java/jdk1.3.1

TOMCAT_HOME=/usr/local/jakarta-tomcat-3.2.1

export PATH JAVA_HOME TOMCAT_HOME ANT_HOME

　　と設定する。

　②TOMCAT_HOME/conf/worker.propertiesのところで

　　　workers.tomcat_home=/usr/local/jakarta-tomcat-3.2.1

　　　workers.java_home=/usr/java/jdk1.3.1

　　と設定する。また、TOMCAT_HOME/conf/ wrapper.propertiesのところで

　　　wrapper.tomcat_home=/usr/local/jakarta-tomcat-3.2.1

　　　wrapper.java_home=/usr/java/jdk1.3.1

　　と設定する。

　③/etc/httpd/conf/httpd.confの最後尾に

　　　Include "/usr/local/jakarta-tomcat-3.2.1/conf/mod_jk.conf-auto"

　　を追加する。

④/etc/httpd/modulesを同じディレクトリにコピーし、名前をlibexecに変換する。

⑤mod_jk-eapi.soとmod_jk-noeapi.soを
http://jakarta.apache.org/builds/jakarta-tomcat/release/v3.2.1/bin/linux/i386/から
ダウンロードし/etc/httpd/libexec/の下へコピーする。

⑥jsdk2.1/server.jarおよびTOMCAT_HOME/lib/servlet.jarを

　　  JAVA_HOME /jre/lib/ext/へコピーする。

⑦ANT_HOME/lib/ant.jarをTOMCAT_HOME/lib/へコピーする。

⑧/usr/java/jdk1.3.1/jre/lib/font.propertiesを
http://java.sun.com/j2se/1.3/ja/install-linux-sdk.htmlのfont.propertiesに書き換える。

４．       JAXPのインストール

http://java.sun.com/xml/jaxpよりjaxp-1.1.tar.gzをインストールする。

　cd /home/manabu

# tar –xvfz jaxp-1.1.tar.gz

　jaxp1.1/crimson.jar、jaxp.jar、xalan.jarをJAVA_HOME/jre/lib/extの下へおく。

５．       JDBCのインストール

①   cd /home/manabuの.bashrcで

　　　　export PATH=$PATH:/usr/local/pgsql/bin

export CLASSPATH=.:/usr/local/pgsql/share/java/postgresql.jar

を付け加える。

　②/usr/local/pgsql/share/java/postgresql.jarを

　　TOMCAT_HOME/libおよびJAVA_HOME/jre/lib/extへコピーする。