IBMのWebSphereのフィーチャ・パックは、アプリケーション・サーバに新しいフィーチャを提供する、製品の拡張用のパックで、インストールするかどうかは、オプションである。IBMが 最近公開した XMLのフィーチャ・パックは、アプリケーション開発者に、もっとも最近承認されたW3CのXML標準セットのサポートを提供する:
- XQuery 1.0: XMLデータのコレクションをクエリするために設計され、新しく導入されたクエリかつ関数型プログラム言語である。それは、XPath式のシンタックスを使い、XMLドキュメントの特定部分を処理し、"FOR, LET, WHERE, ORDER BYと RETURN"という表現を加えている。一般に、"FLWOR"と略され、SQLと同様な方法で、多数のXMLストリーム間で結合を実行するために使える。
- XPath 2.0: XMLドキュメントと一緒に機能する式言語である。XPath式の結果は、典型的には、入力ドキュメントからのノードの選択、あるいはアトミックな値である。XPath 2.0は、今やXPath 1.0のサブセットである。XPath 1.0 から XPath 2.0への変更で最も際立つのは、ずっと豊富になった型システムの導入である：今や、すべての値は、シーケンスであり、単一の値も長さが１のシーケンスとして扱われる。XPath 2.0は、Schema Awarenessをサポートする。すなわち、ツリーの要素が、XPathをナビゲートするのに使うことができる型のアノテーションを持つことを意味する。XMLプロセッサは、文字列や数や日付などの組み込み型を含んだ、Schema Aware（スキーマの認識能力）を提供しなければならない。オプションで、ユーザ定義の型をサポートしてもよい、そうすれば必要な式を非常に単純化することができる。例えば、インターネット・メール会社は、顧客の発注と紐づいた請求先アドレスと配達先アドレスのあるXMLドキュメントを持っているとする。もし両アドレスのフィールドが、共通のAddressTypeを持つなら//element(*, tns:AddressType)/postalCodeという式は、両アドレスの郵便番号を返すだろう。新しい関数には、パターン・マッチングのための正規表現シンタックス、今日の日付のような新しい日付関数群、床(floor),天井(ceiling),丸め(round)関数などの新しい数値処理関数などがある。
- XSLT 2.0: XMLを新しいXMLフォーマット、あるいは、他の表現形式、例えば、HTML, XHTML や SVGに変換するために使われるプログラム言語。XQuery 1.0のように、XSLT 2.0 は、パス言語にはXPath 2.0を使っている。XSLT 2.0は、いくつもの新しい能力を加えており、グループ化、一つの入力ドキュメントから多数の結果を出力する能力、そしてXPathから呼び出せるXSLTの関数を定義できる能力などがある。XPath 2.0プロセッサのように、XSLT プロセッサもオプションで"Schema Aware"であってもよい。そうであると、いくつもの利点を提供できることになる、例えば、XSLT変換の前に入力ツリーを確認する能力や、XSLT変換が問題なく出力することを保証するために、出力ツリーを確認する能力などである。また、変数、入力パラメータ、関数からの返り値、ユーザ定義に関数、そしてテンプレートのデータ型を定義することができる。XSLTは、XMLデータを変換する際の第一の選択肢でありつづけ、XQueryは、XMLドキュメントをクエリするための標準になると思われる。XQuery と XSLT 2.0の両方が、パス言語としてXPath 2.0を使用しているが、XQueryのXPath 2.0への拡張は、XSLT開発者にとっては、実際上、無関係なことである。
フィーチャ・パックについてもっと知るために、InfoQは、主任アーキテクトのAndrew Spyker氏にインタビュした:
InfoQ: XMLは、明らかに、企業コンピューティングで広く使われているフォーマットです。これらの標準の新しいフィーチャが特に重要となる、アプリケーションの例をいくつか教えてくれませんか？
既存のXMLは、企業コンピューティングで非常に使われていますので、このフィーチャ・パックが使われるあらゆるシナリオについて話すのは、ほとんど不可能です。なので、これから話すのは、完全なものではなく、単に説明のためのものです。XMLソースにクエリし、そこからのデータを表現するアプリケーション。例として、ブログのフィード、コメントそしてフィードに関連した分析です。コメント欄に投稿された問題のある内容を探すために、あなたのブログを徹底的に調べたり、あなたが傾向を調べることができるように、webフォーム内の情報を見せたり、あるコメントの投稿者を厄介者と警告したりするアプリケーションを考えてください。次第に、そのリストをデータベースに貯めて、あなたは、やっかいなコメントを積極的に見極めることができます。このシナリオのすべての入力ソースが、webで表現するのに簡単に使うことができるXML やXHTML（新しくサポートされたXSLT 2.0のシリアライズ形式）であると、仮定するなら、XMLベースのプログラミング・モデルを使うのが当然です。フィーチャ・パックにこれを説明するアプリケーション例があります。
業界標準のスキーマと連携するアプリケーション。ほとんどあらゆる垂直市場は、業界標準のスキーマと連携していて、大抵の企業は、これらのスキーマを自分たちのビジネス用にカスタマイズしている。過去に、XPath 1.0 (とこれに依存した XSLT 1.0)を使って、XMLのランタイムは、スキーマの知識を持っていません。すなわち、もしあなたがPurchaseOrder型のすべてのデータ要素を探しているとしたら、サーチコードの中に、あらゆる可能な認証された名前をハードコードしなければならないのです。よくても、これは、非常に保守するのが難しくなり、最悪、企業における新しい型が既存の型を拡張する時に、もろいコードは、動かなくなります。XPath 2.0（とこれに依存したXSLT 2.0と XQuery 1.0）では、クエリに型を入れてサーチできます。
XPath 1.0 と XSLT 1.0を使っていたアプリケーション。これは、当たり前ように思えますが、話す価値があります。XPath 2.0 と XSLT 2.0は、７年に渡って業界での使われ方を考えてきたものです。新しい能力により、以前には不可能だった、たくさんの新しい機能的なシナリオ（例えば、複数言語をサポートする照合、XSLT 2.0による複数出力）が提供されます。また、（例えば、グループ化のサポートのような）XSLT 1.0では、複雑な表現となったパターンのサポートが能力に加わったので、コードが少なくなり、保守が楽になり、殆どの場合パフォーマンスも以前よりよくなります。- ランタイムがこれをサポートするであり、ランタイムの上にコード化されるのではありません。
多数のデータソースに跨いでデータをクエリするアプリケーション。ある時、XMLをネイティブにサポートする（例えば、DB2のpureXML）データベースでは、XQueryは、サポートされていたが、ミドルウェアでXQueryをサポートすると、XMLデータベースからと、データベース外のXML保存場所からとのデータを結合することができます。一つの例は、XMLデータベースにあるデータと連動するバッチで、Web 2.0 APIを呼び、そのデータを処理して、それから別のデータベースに保存するものである。XMLフィーチャ・パックはこのシナリオをシンクライアントでサポートします。シンクライアントが、アプリケーション・サーバの機能性をサポートして使われる限りは、このシナリオを、サーバのJVM外で、標準のJavaSE アプリケーションで使うことができます。
以前、私が言ったようにもっとたくさんのシナリオが可能です。あらゆる可能な使用範囲は、企業において、XML形式で保存したデータあるいはドキュメントの量によってのみ、その限界が決まるのです。非常に大きいとしか言えません。
InfoQ: マルチコアやクラウドの環境でXMLを扱うJavaのDOMのモデルを使うより、XSLT 2 や XQuery 1のような言語は、どのような有利な点がありますか？
XMLフィーチャ・パックでサポートされている宣言型(命令型に対して)のXML中心（言語中心に対して）の言語を使うことには、２つの大きな有利な点があります。第一に、宣言型プログラミングは、ユーザに何をしたいかを訊ねます。これは、命令型プログラミングとは、反対です。例えば、DOM や JAXB APIと動くJavaコードのような命令型プログラミングでは、ユーザにやりたい事をどのようにやるかを問います。宣言型プログラミングは、より小さく、変更をより早く取り入れるコードをメンテするのがより簡単になります。また、宣言型プログラミングでは、ユーザは、XMLランタイムに何に興味があるかを表現でき、ランタイムが最適化できる方法で、どのようにクエリしたいとか、データ変換したいかを表現できます。これは、ユーザがランタイムに正確にどのように実行するかを言う方法では不可能です。この違いは、想像出来ると思いますが、マルチコアやクラウドの最適化では、非常に重要となります。単一CPU上でより早いだけでなく、マルチCPUや複数の仮想環境間でもより早く実行できる様々なパターンを認識する最適化です。そして、XSLTと XQueryは、機能的で副作用がありませんので、そのような最適化を完全に安全に実行できます。典型的なプログラミングAPIを使う、命令型の言語では、不可能なことです。私が個人的には、長い目で見れば、高レベルの宣言型言語の方が、特定のランタイムを仮定している低レベルの言語より、よりポータブルなので、クラウドによく合うと、信じています。
第二に、XML中心（JavaやC#や他の言語に対して）の言語は、XMLの型システムをコアの型システムとして持っているのがすべてです。XMLの型を言語ネイティブの型にマッピングするのは、２つの不利な点があります。第一、XML忠実性の問題です。XMLをオブジェクト表現にマッピングするのは、非常に大変で、もし上手くいかないと、情報を失う結果に成り得ます。JAXB 2.0のようなAPIは、この問題を非常にうまく処理していますが、結局、XMLの完璧なロスレス表現へのマッピングでは、純粋のXMLモデルよりいいものは、ありません。第二に、型システムの変換あるいは、DOMモデルへの変換には、著しいパフォーマンス上のオーバヘッドが加わります。本質的に、これは、ミドルウェアでのデータコピーであり、非常に高価で避けるべきです。XMLデータをネイティブな表現で扱うことによって、データを失うことはありませんし、パフォーマンスも最適です。もしXMLがビジネス間においてそして、企業においてよく使われるデータ交換形式になってきたのなら、これら２つの利点を持つことは、重要です。
注意すべきなのは、我々は、人々が既存のアプリケーションの全てをXMLプログラミングモデルに変えるとは、考えていない、ということです。ですから、XMLランタイムの実行に、既存のJavaのデータやロジックを加える簡単な方法を提供します。どのXML言語が使われているかにかかわらず、同じ一貫したAPIにより、この拡張は、なされています。この一貫性は、重要です。３つのXML言語を跨いで、同じプログラミングスタイルをとればよく、例えば、XQuery 1.0から XSLT 2.0へデータを効率良く、パイプライン化できますから。また、我々は、このXML技術がマルチスレッド化されたサーバ上で、使用が容易かつパフォーマンスが上がるように、APIを設計しました。以前のAPIは、クライアント環境で使われ、効率的なマルチスレッドのサポートをコーディングするのに容易であるよりは、単一スレッドにおいて単純化することを重要視して設計されました。今度のAPIにより、サーバで使用するコードが自然で、効率的になるように、共有されるすべてのオブジェクトがスレッド・セーフになります。
InfoQ: XMLの処理において、マイクロソフトのLINQと比べてW3Cの標準は、どうですか？
主要な違いは、XMLフィーチャ・パックは、XMLを処理するために、公開で開発されたW3Cの標準を実装した、ということです。標準の基盤を持つことによって、組織も開発者も標準の複数の実装に跨いで使われる、XMLプログラミング・モデルのスキルやツールにおける一貫性を享受できます。
InfoQ: Michael Kay氏によるSaxonの実装に対して、フィーチャ・パックの有利な点は何ですか？
まず最初に、言わなくてはならないのは、あらゆる業界からのフィードバックによると、Saxonは XPath 2.0, XSLT 2.0と XQuery 1.0のすばらしい実装です。またMichael Kay氏は、IBMや他の会社からの貢献者と一緒に、XMLの世界におけるW3Cの標準を推進する上で、すばらしい仕事をしてきました。SaxonもXMLフィーチャ・パックも同じような標準のセットを実装しました。そのため、プログラミング・モデルの立場から言えば、一貫性があります。運用の面から見れば、WebSphereのユーザは、IBMにより開発され、テストされ、現行のWebSphere Application Server V7の権利とともにサポートされる実装である、という保証を得ることができます。これまで話したように、WebSphereの上にXMLベースのソリューションの実装を望んでいる顧客のためのシナリオは、たくさんあります。このことを実現するために、我々の顧客が現在も将来も信頼できる形で、これらの標準によって可能な新しい能力を提供したいと思っていました。
InfoQ: Javaのプラットフォームに標準化された技術がいつ頃入ってくる、と予感できますか？もしそうなった時、あなたの実装に何か起こるでしょう？
今日、Javaは、JAXPによりXPath 1.0と XSLT 1.0をサポートしていますが、XPath 2.0と XSLT 2.0をサポートしていません。XQJと呼ばれているXQuery 1.0をサポートするJSRがあります。我々は、将来、Javaで汎用化されたXQueryを実装する最善の方法を考えるべきです。個人的には、私は、接続性指向のXQJのAPIと、いくつものXMLの標準に合わせるために、複数のAPI（JAXPと XQJ）をユーザが学ばなければならなくなってしまうことを懸念しています。Javaのプラットフォームは、業界が必要とするものにあわせてきたように思います。なので業界がサポートし、ユーザが必要であるなら、Javaプラットフォームは、いずれこれらの標準を採用し、サポートしていくと思います。IBMは、引き続き、ユーザにとって有益なかたちで、XMLがJavaの標準プロセスに組み込まれるように努力していきます。JavaプラットフォームがXPath 2.0, XSLT 2.0, とXQuery 1.0を扱えるように進化したとしても、我々の実装は残るでしょう。IBMは、今日、IBMのJVMに自分たちのXPath 1.0と XSLT 1.0の実装を入れて出荷してます。IBMは、Javaの標準をサポートしながら、JVMのXMLの部分に、パフォーマンスと信頼性と機能的な付加価値を提供してきた歴史があります。これらの改善によって、全WebSphere製品を通して、XML処理、webサービスそしてSOAは、強化され続けるでしょう。
WebSphereの XML フィーチャ・パックについてもっと知りたければ、WebSphere のブログをみるとよい、 ここ。 YouTubeによるインストール案内を含んだスタート・ガイドは、 ここ。