記事>
<記事情報>
<タイトル>XMLとオブジェクト指向タイトル>
<連載通番>4連載通番>
<サブタイトル>XML再分類サブタイトル>
<著者>おば著者>
記事情報>
<記事本文>
<章>
<章タイトル>はじめに章タイトル>
<章本文>
<段落>こんにちは。不定期連載としてXMLについて書きかじめてから、半年ほどたちました。XMLに対する注目度は高まる一方のようで、XMLに関する情報や記事は、あちこちの雑誌やWWWサイトに氾濫しています。ところで、どの雑誌もどの記事も、(そして、この連載も)、色の違いは多少あるにせよ、どうもXMLについて捕らえきれていないような、少し歯がゆい感じがしませんか?
段落>
<段落>この連載が始まってから、たくさんの方々とXMLについて話し合う機会を得ました。みなさん、自分の業務にXMLがどう関わってくるのか、どのように役に立てて行けばよいのかということを非常に熱心に考えられていて、そのような方々とお話するというのは、とても勉強になります。この場を借りて、あらためてお礼を申し上げたいと思います。> いままでお会いした皆様
段落>
<段落>さて、こうして多くの方と話をさせていただく中で、日々感じていることがあります。XMLは情報システムのあらゆるところと関係し、あらゆるところで活用可能である、ということです。そして、これがXMLをわかりにくくさせている最大の原因ではないかと感じています。ご存知のとおり、XMLそのものは、少なくとも入り口に関して言えば、非常にシンプルでわかりやすいものです。ただ、XMLの仕様、文法を理解しただけでは、XMLを理解したということにはなりません。XMLがシンプルで、あらゆる場面で活用できるということを踏まえた上で、では自分のところではどうするのか、ということを考える必要がありそうです。
段落>
<段落>今回は、しばしば「文書としてのXML」、「データとしてのXML」などと分類されているXMLを、もう少しブレークダウンしながら、あらためて概観してみたいと思います。さまざまなXML関連情報を読み、活用する際に、自分なりの視点を持つと整理がしやすくなると思います。これがその助けになれば幸いです。
段落>
<段落>今回も原稿はXML + XSLで記述しています。IE5.0でごらんの方はこちらでもどうぞ。第3回、第2回、第1回、第0回の原稿もXMLで参照可能です。段落>
章本文>
章>
<章>
<章タイトル>XML A Manager's Guide章タイトル>
<章本文>
<段落>昨年の暮れ、Kevin Dickの"XML A Manager's Guide"という本(1999, Addison-Wesley, ISBN0-201-43335-4)を読みました。タイトルのとおり、マネージャ向きの内容で、実装技術の詳細については触れられていないものの、XMLの特徴、可能性、活用におけるポイントがコンパクトにまとめられています(索引まで入れてもたったの185ページです)。図表も豊富ですし、気に入ったのは、各段落の要旨が本文の脇に青色で簡潔に記されていることです。これなら、後で読み返す場合にも、必要な場所をすぐに見つけることができます。
段落>
<段落>この本の章構成は以下のようになっています(()内は拙訳)。
- The Internet Crisis: Exchanging Information(インターネットの危機:情報交換)
- XML Basics(XMLの基礎)
- Related Standards(関連の標準規格)
- XML Tools(XMLのツール)
- Processes and People(開発プロセスと要員)
- Five XML Applications for Enterprises(企業における5種類のXMLアプリケーション)
- Five XML Applications for Vendors(ベンダーにおける5種理のXMLアプリケーション)
ご覧になればわかるとおり、前半は「XMLという言葉を最近良く耳にするけれども、いったいどういうものなんだろう?」という人を対象にかかれています。最近本屋さんでよく見かける「60分でわかる○○」といった感じです。特に2章から4章は、知っている人はあらためて読む必要は無いでしょう。
段落>
<段落>この本が面白くなってくるのは、5章から先です。
段落>
<段落>5章では、XML文書をその特徴に応じて、Content Documents、Business Documents、Protocol Documentsの3種類に分類しています。これらを分けるのは、文書の読み手が誰であるか(人かソフトウェアか)、文書の流通(フロー)の厳密さ、文書のライフサイクルなどです。もちろん、これらの特性は厳密にどこかで線が引けるわけではなく、3種類の文書にわたって、なだらかに推移していきます。そして、文書の種類ごとに、キーとなる技術、開発プロセスと必要な要員が示されます。
段落>
<段落>6章、7章では5章のXML文書の分類にしたがって、想定されるアプリケーションを、いわゆる企業システム開発者とソフトウェアベンダーの立場から5種類ずつ例示しています。企業システムとして例示されているのは、以下のとおりです。
- 情報流通(協調作業、プロジェクト管理)
- ナレッジマネジメント(製品プランニング、テクニカルサポート)
- ワークフロー(購買、経費報告書)
- アプリケーション統合(サプライチェーンマネジメント、ERP/HRの統合)
- データ統合(顧客管理、製品情報管理)
一方、以下のリストは、ソフトウェアベンダー向けとしてあげられているものです。
- パーソナライズされたウェブサイト(ポータル、オンラインショッピング)
- 情報の集約(PCコンポーネント情報、学術研究)
- ソフトウェア情報管理(自動アップグレード、デスクトップ管理)
- 設定情報、ログ(コンポーネント配布、セキュリティログ)
- 分散プロトコル*1
(*1: 「分散プロトコル」の()対応部分には、「設定情報、ログ」と同様、「コンポーネント配布、セキュリティログ」と記されていますが、誤植と思われます)
段落>
<段落>正直なところ、私はこの本(特に5章)を読んで、やっと今まで感じていたもやもやとした感覚から逃れることができました。以下では、この本で提示されたXML文書の3分類に、私なりの分類と解釈も加えて整理してみたいと思います。
段落>
章本文>
章>
<章>
<章タイトル>XML文書の再分類章タイトル>
<章本文>
<段落>私なりの分類として、以下の4つにXML文書を分類してみたいと思います。
- コンテンツ
- ビジネスオブジェクト
- プロトコル
- アプリケーション基盤
最初の3つは、上で紹介した本の分類(Content Documents, Business Documents, Protocol Documents)にほぼ準拠します。4つ目は、新しい分類です
段落>
<段落>コンテンツは、いわゆる「文書としてのXML」にもっとも近いものです。人に読まれることを主眼としていて、XSLTなどの技術を活用して、さまざまな形態で人に向かって公開されます。また、ナレッジマネジメントもここに分類されます。従来はプレーンテキストやベンダ固有のワープロフォーマットで扱われていた文書をXML化することにより、その活用が容易になります。文書に記されている内容そのものに価値がありますから、ここに分類されるXML文書は通常なんらかの形で保存、蓄積されるでしょう。
段落>
<段落>ビジネスオブジェクトは、たとえば、顧客、商品、あるいは注文書といった、アプリケーションで使用されるオブジェクトです(いわゆるビジネスオブジェクトの定義と比べると大雑把すぎますが、ご了承ください)。このようなビジネスオブジェクトの表現形式としてXMLが使用されることがあります。顧客データベースや商品データベース、注文履歴データベースなどとしての活用されます。ここに書かれている情報は人にとってもソフトウェアにとっても利用可能です。例えば、XMLで記述された顧客DBをそのままブラウザから参照して、必要な情報を得ることができます。ソフトウェアでは、XML文書をパースして、必要な情報を取り出し、言語オブジェクトに変換できます。逆に言語オブジェクトをXML化して保存もします。「文書としてのXML」と「データとしてのXML」の中間に位置するといってよいでしょう。
段落>
<段落>プロトコルは、複数のオブジェクト間、アプリケーション間、会社間での情報交換のためのフォーマット(プロトコル)としてXMLを使用するというケースです。EDIがここにあたります。多くの場合、ここで記述されている情報は、ソフトウェアで処理されることを前提にしています。また、必ずしもXML文書が長期にわたって保存される必要はなく、相手方に渡ってしまえば、適切に処理された後、XML文書そのものは破棄されるケースが多いでしょう。もっとも典型的な「データとしてのXML」です。
段落>
<段落>最後に、アプリケーション基盤は、アプリケーションを動作させるための仕組みとして、あるいは開発プロセスを支援するために使用されるXML文書を想定しています。前回あつかった、CCMやBMLはこれにあたります。まだきちんと取り扱っていませんが、メタデータの表現形式としてのXMI(XML Metadata Interchange)もこれにあたります。上の3つの分類の延長上にあるというのは、多少無理があるのかもしれませんが、このようにシステム開発のインフラ部分で使用されるXML文書は、上記のどれにもなじまないので、独立させて考えたいと思います。この分類のXML文書は、ソフトウェアで処理されることを前提としていますが、ライフサイクルはまちまちでしょう。「(メタ)データとしてのXML」といえるかもしれません。
段落>
章本文>
章>
<章>
<章タイトル>XML文書の分類と技術要素章タイトル>
<章本文>
<段落>さて、次に上の4分類について、関連する技術要素を考えてみましょう。
段落>
<段落>コンテンツは、文書の内容そのものが人にとって価値を持ちますから、これを公開するための技術、つまりWWW関連技術が重要になります。XMLは表現形式を規定しませんから、XSLTやスクリプトの技術も関係します。また、保存するためのデータベース技術も重要でしょう。文書の構造を維持する必要がありますから、XML文書の構造をそのまま保存できるなければなりません。
段落>
<段落>順序が前後しますが、プロトコルは、かなり違う性格をもちます。複数のオブジェクト、システム間での情報交換ですから、分散技術と切り離して考えることができません。例えば、CORBA、EJBなどの分散オブジェクト技術、MQ-Seriesなどのメッセージング技術などです。逆に、もともと独立して動いていたシステムを統合するという観点からは、EAI(Enterprise Application Integration)が大いに関係してきます。EAIについても、どこかで一度触れたいと考えています。
段落>
<段落>プロトコルについて、データベース技術という観点からはどうでしょうか。XML文書として送られてきたデータを保存する必要があるかもしれませんが、XMLの文書構造を維持する必要がある場合はまれだと考えられます。たいていの場合は、必要なデータ項目をDOMまたはSAXなどのプログラミングインタフェースを通して取得し、必要な場合にのみ、なんらかの形式で保存します。保存形態としては、RDBやODBを利用するケースがもっとも多いでしょう。XML以前の、従来から使用してきたデータベースを活用していくことが可能ですし、データベースがXML対応している必要もありません(XMLアダプタくらい用意されていると便利でしょうが)。同じく、従来からXMLとは無関係に構築されてきたデータベースも、このように考えていくことで、XMLの力を借りてさらに活用していくことができます。
段落>
<段落>ビジネスオブジェクトとしてのXML文書は、コンテンツとプロトコルの中間に位置します。両方の特徴をあわせもつといってもよいかもしれません。そのために、関わってくる技術要素も増えてきますし、複雑さも増します。データベースの例でいえば、XMLの構造を保持すべきかどうかは大きな問題になってきます。このような問題にあたるときには、かなり注意が必要でしょう。自分の扱っているXML文書は、コンテンツ的性格とプロトコル的性格のどちらがより強いのだろうか?私はXMLによって、何を実現したいのだろうか?場合によっては、そもそも対象のデータはXMLで表現されることが適切なのだろうか?このような問いに答えていくことによって、必要な技術要素が見えてくるのかもしれません。
段落>
<段落>最後に、アプリケーション開発基盤は、他の3つがアプリケーションが処理対象とするデータであるのに対し、これをもとにアプリケーションが動作する、構成されるということになりますから、2つの選択肢の間で悩むことは少ないでしょう。おそらく、ここに分類されるXML文書を利用する際の問題は、このような技術がまだ仕様策定段階であったり、十分な実装を見つけるのが難しいということです。ここについては、これからの推移を見守りたいと思います。
段落>
章本文>
章>
<章>
<章タイトル>なぜXMLか?章タイトル>
<章本文>
<段落>このようにXML文書を分類することにどのような意味があるのでしょうか?ここで、今回の文章の最初にもどりたいと思います。4つの分類が示すとおり、XMLはシステムのあらゆるところに活用可能で、いろいろな部分を効率化してくれます。しかし、今まで、私(達?)は、XMLという新しく魅力的な技術の華やかさに目を奪われすぎていたのかもしれません。その輝きに少し目がくらんでしまい、あれもこれもと言い過ぎていたような気がします。
段落>
<段落>XMLを使うことに注意を奪われてしまうと、そのXML文書の性質によらず、あらゆるXML関連技術、XML関連製品を活用したくなります。また、システムの目標によらず、あらゆるものをXML化したくなってきます。このようにして作られたシステムは、ある部分はXMLであるがゆえにパフォーマンスが落ちているかもしれません。スケーラビリティに欠けたものになっているかもしれません。既存のシステムとの整合性がとれないものになっているかもしれません。これらは、極端な話かもしれませんが、ありえない話でしょうか。杞憂かもしれませんが、これが事実となって、XMLに対して不当な評価が与えられ、XMLの発展が妨げられるような事態になることを恐れます。
段落>
<段落>ソフトウェア開発に携わる私たちは、「なぜ、XMLなのか?」という、XMLについての解説書の第1章に必ず出てくるこの問いを、つねに考えつづけるべきだと思います。自分のシステムでは、何のためにXMLを利用するのか、XMLによって期待する付加価値は何か、ということを考えていけば、システム内におけるXMLの位置付けが見えてくるはずです。それによって、必要な技術要素、活用方法も見えてくるのだと思います。
段落>
章本文>
章>
<章>
<章タイトル>最後に章タイトル>
<章本文>
<段落>またしても「オブジェクト指向」という観点からはずれてしまいました。少しだけ、このような文章を書いたことについて言い訳させてください。
段落>
<段落>この一年ほどのXMLに対する注目度の高まりは驚くべきものがあります。XMLが注目されればされるほど、たくさんの応用技術が発表され、応用事例が発表されることになります。これはXMLの発展、成長のためには喜ばしいことに間違いありません。しかし、一方で、それらから何を読み取っていけばよいのかが難しくなります。どれが自分に関係し、自分に関係しないのか、見分けるのが困難になってきます。このような状況から抜け出すために必要なのが、ものごとをはかるための尺度なのだと思います。本文でとりあげた分類は、まだまだ未熟ですが、私なりの尺度をつくっていくための第一段階としてまとめてみました。
段落>
<段落>本文中で紹介した、"XML A Manager's Guide"は、XMLについて、一度整理して考えてみたい方には最適だと思います。参考までに、出版元のAddison-WesleyとAmazon.comのこの書籍へのリンクを紹介しておきます。
段落>
章本文>
章>
記事本文>
記事>