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