Web Servicesインサイダー: 第2回 W3C Web Services Workshopの要約

(Web Servicesの)マニアたちの重要な会合

先週、Web Servicesインサイダーは、W3Cの最初のWeb Services Workshopに参加しました。このワークショップは、新興のWeb Servicesアーキテクチャーを標準化するためにW3Cがどのような方向に進むべきかを探るために開催されたものです。今回の記事で彼は、そこで議論された内容の要約を報告しています。

James Snell (jasnell@us.ibm.com), Software Engineer, Emerging Technologies, IBM

James Snellは、IBMのEmerging Technologies Toolkitチームの一員です。過去2年間は、新興のWebサービス技術や標準などに焦点を当てており、またAtom 1.0仕様にも貢献しました。新興技術に焦点を当てたウェブログ、http://www.ibm.com/developerworks/blogs/page/jasnellを維持管理しています。



2001年 4月

表題からも想像が付くように、カリフォルニア州サンホセで先週 (4月11日および12日) 開催されたWeb Services Workshopでは、非常に知的な人々が大勢集まり、この新興のパラダイムの将来について語り合いました。私は幸運にも、ワークショップのプログラム委員 (提出された方針書を検討し、ワークショップに参加する人員を選択するためのグループ) の一員として参加するだけでなく、セッションの1つで司会も務めることができました。私にとってこれは初めての公式なW3Cイベントであったため、W3Cがその仕事をどのように成し遂げているのかを目の当たりにして、きわめて有益な経験をすることができました。「Web Servicesインサイダー」の今回の記事では、そこで行われたプレゼンテーションとディスカッションのハイライトを紹介したいと思います。

W3Cプロセスについて

まず初めに、このワークショップに参加する以前の私と同じように、W3Cプロセスになじみのない読者のために、簡単な概要を示しておきます。W3Cは、標準化プロセスの仕事を開始する前に、しばらくの間W3Cのメンバー企業に対して、W3Cが何をどのように進めるべきかについてフィードバックと情報の提供を求めていました。これらのワークショップは、このプロセスの一部です。

W3C Workshopの目的は、最終的に独立したW3C Working GroupまたはInterest Groupに発展する可能性のあるトピックを、ブレーンストーミングすることにほかなりません。私たちが親しみを込めてW3C勧告と呼んでいる実際の仕様は、この ワーキング・グループによって決められています。したがって、このワークショップでWSDLやUDDIなどの標準化を進めるために実際の決定が行われたのかどうかという、端的な質問に答えるとすると、「ノー」ということになるのですが、そうしたことをどのように、いつ、またなぜ行いたいのかについて、私たちは非常に詳しく議論しました。


2日間をどう過ごしたのか

まず最初に、当然のことですが、通常このような行事につきものの雑談で始まり、その後イベント会場となっているホテルが用意してくれたすばらしい昼食のご相伴にもあずかりました (ついでながら、こうしたすべてのことを後援してくれたIBMに賛辞を送りたいと思います)。2日間の日程の多くは、Web Servicesに並々ならぬ関心を持つさまざまなW3Cメンバー企業によって行われたプレゼンテーションを聞き、それに関して意見を交換することに費やされました。その後で議論が行われました。つまり、私たちとしては最初に何を行いたいのか、誰がそれを行うべきか、また他の組織 (OASISなど) が行った仕事のうち、私たちが何を活用できるのかについてのブレーンストーミングです。行事がどのように進行したのかをはっきり理解するためには (そしてまた、提出されたすばらしい方針書を読むためには)、ワークショップの公式Webサイト (参考文献を参照) を調べ、ワークショップ・プログラムへのリンクをたどってください。


何を話し合ったのか

ワークショップ全体は、いくつかの異なるテーマを中心に展開しました。これらのテーマは、この新興Web Servicesアーキテクチャーの発展を注目してきた人にとっては、すでにかなりなじみがあるはずです。

私たちは、Web Servicesアーキテクチャーの3つの異なる概念的なコンポーネントについて話し合い、それらを識別し、各コンポーネントに適合するいくつかの要件とテクノロジーを定義するプロセスを開始しました。IBMのEmerging Technologies担当副社長Rod SmithとMicrosoftのXML教祖であるAndrew Laymanによって行われたプレゼンテーションから、「Web Services Stack」の姿が見えてきました (図1 を参照)。

図1: Web Services Architecture Stackの概要
図1: Web Services Architecture Stackの概要

Web Serviceを「記述する」ということが本当は何を意味するのか、ということを議論し、またWeb Services Description Language (WSDL) については、W3CがWSDLの標準化作業を開始すべきか、あるいはより一般的に、W3CがWeb Service Description全般の標準化作業を開始すべきか、ということを詳しく話し合いました。グループの一般的な意見は、Web Service Descriptionを標準化するためのW3C Working Groupを短期間のうちに立ち上げるべきである、ということでまとまりました。そうしたワーキング・グループの設立趣旨の正確な詳細については、これから決める必要があります。しかし、SOAPがW3CのXML Protocolプロセスの中核部分となったのと同じように、WSDLがそのプロセスの中核部分になることは確かです。

図2: Service Description Stack
図2: Service Description Stack

図2 から分かるように、WSDLは、IBMがWeb Services Description Stackとして識別したもののうち、下部の2つの層を対象としています。このスタックの上のほうのレベルについても、多くの注目が集まりました。つまり、信頼性に関してWeb Serviceの特性を記述できる以上、能力、メッセージの順序付け、誰がいつ、どのメッセージを送るのかということのオーケストレーションなどはすべて、Web Serviceの「記述可能な」コンポーネントであるものと識別されました。これらのそれぞれをService Description Stackのレイヤーにするための基礎として、単一の、定義された、拡張可能なフレームワークが必要であるということで意見が一致しました。これをどのような形に仕上げるのかについては、若干の意見の相違がありましたが、中心的な話題はWSDLであり、そうした作業の基礎をなぜWSDLが築くことができるのか、またなぜ築くべきなのかについて、非常に有意義な議論が行われました。

Tim Berbers Leeはワークショップの皮切りとして、Web Servicesが事実上「セマンティックWeb」を具現化したものであるという彼の見解を詳細に述べました。この議論のトピックは、さまざまなカテゴリーに基づいてWeb Servicesをカテゴリー化、分類、および発見できるということから、WSDLとRDFをどのように組み合わせることによって、すでに存在するRDFベースのインフラストラクチャーを活用できるのかということまで、多岐にわたりました。


異なる世界が衝突するとき

私の考えでは、最も興味深かったディスカッションの1つは、この新興Web Servicesアーキテクチャーと、OASISグループがebXMLで行っている作業の収束に関するものでした。ebXMLのことをよく知らない読者のために、ごく短い、しかも水で薄めたような要約を示しておきます。ebXMLは、XMLその他のオープン・スタンダード・テクノロジーを使用してインターネットでEビジネスを運営するための、プロトコルと仕様のエンドツーエンドのスタックです。「エンドツーエンド」というのは、ebXMLが基本的に、(WSDLまたはその他のメカニズムを使用して行う) 単純なサービス・エンドポイントの定義の記述から、取引に関するビジネス・プロセス・ワークフロー全体の記述まで、Eビジネス取引のすべての局面を扱うための仕様を備えているということです。ebXMLの仕様 (2001年5月半ばに完成予定) の範囲は、信頼性の高いメッセージング、セキュリティー、トランザクション、メッセージ・パッケージング、サービスの記述、サービス能力の記述、メッセージの順序付け、メッセージのワークフローとオーケストレーション、さまざなま取引先との合意などに関する、広範囲にわたる局面をカバーしています。

ebXMLは、多くの点で、Web Servicesアーキテクチャーが構築しようとしているものと非常によく似ているようです。確かにそのとおりであり、2つのアーキテクチャーが行おうとしていることとそれを行う方法との間で衝突と収束が見うけられるようになったのは、そのためです。たとえば、ebXMLはXMLベースのメッセージを回線でやり取りするための方法を必要としていました。彼らは、まず最初にSOAP (バージョン1.0) に目を向け、それを使用しないことに決めたため、主としてXMLドキュメントを個々のマルチパートMIMEの部品に押し込むことにより、独自にXMLメッセージング・プロトコルを開発しました。やがて、基本プロトコルとしてSOAPを使用して、まったく同じことを行う、SOAP Messages With Attachments仕様が登場しました。ebXML Working Groupは選択に迫られました。自分たちのXMLメッセージング仕様で続けていくか、あるいはSOAP With Attachments仕様に切り替えるかを選ぶ必要がありました。2か月ほど前、彼らは賢明にも、SOAP With Attachmentsを自分たちのメッセージング標準として採用することに決定しました。

開発者たちがこの方法によってWeb Servicesアーキテクチャーを進化させ続けるかぎり、同じような衝突を解決する必要が生じます。そこで、明らかな疑問が起こります。ebXMLですべてのことができるのなら、なぜebXMLを使わないのか?なぜ、わざわざ苦労して新しいアーキテクチャーを定義するのか?

この質問は、Web Services Workshopで何度も尋ねられたもので、それに対する答えは単純でした。XML MessagingやService Discoveryのエリアのように、オーバーラップするエリアがある場合、私たちが行おうとしていることの要件にebXMLのやり方 (おそらくは、別の方法で設計された仕様) が適合するかどうか、そして適合する場合には、そうしたものをWeb Servicesアーキテクチャーに最大限利用するにはどうすればよいのかを、真剣に検討する必要があるということです。注意しなければならないことは、これが新興アーキテクチャーであって、まだパズルのピースがすべて定義されてはいないということです。しかし、出来上がっているものを一からやり直すことは、できるだけ避けたいと思っています。

ebXMLとWeb Servicesの違いについてもう1つ忘れてならないことは、両者がともに、異なる視点から同じ問題に取り組んでいるということです。ebXMLは、頂上からふもとに向かって作業を進めています。つまり、インターネットでEビジネスを正常に運営するために必要なすべての要件を識別したうえで、そうした要件を満たす仕様を具体化させようとしています。しかし、Web servicesアーキテクチャーは、ふもとから出発して上に登っています。つまり、個々の中核的な要件 (単純なXMLメッセージングやサービス記述など) を満たす仕様を具体化させたうえで、それをもとにアーキテクチャーを構築しようとしています。

ebXMLとWeb Servicesは競合するのでしょうか?ある意味ではイエスであり、ある意味ではノーです。ebXMLは多くの点で、いくつかの非常に難しい問題に答えるために特別の仕様のセットを使用して、Web Servicesアーキテクチャーの実装を複雑な形で行っている、と見ることができます。これらの仕様が、一般にWeb Servicesアーキテクチャーの中核と考えられている仕様 (WSDLやUDDIなど) と異なっている、という事実は、全体としてのアーキテクチャーがまだ流動的であることを認識すれば、問題とはなりません。重要なことは、これら2つのアーキテクチャーを共存可能にするための努力が払われていて、実際に双方にとって有益な追加のレイヤーが付け加えられている、という事実です。たとえば、ebXMLのService Repositoryの設計にあたっては、UDDI Service Registryと共存でき、さらには統合できるようにすることが配慮されています。


結論

Web Services Workshopの結論は次のようなものでした: Web Servicesの発展は非常に重要であり、W3Cはそのアーキテクチャーのさまざまなコンポーネントを標準化する作業を開始すべきである。私たちは、サービス記述の標準化を、この努力における最優先事項の1つとする必要がある、という点でかなり意見が一致しました。ということは、ごく近い将来、読者はWSDLに関する何らかの活動を目にするようになるはずです。読者の会社がWSDLベースのツールを実装するしているのであれば、事態の成り行きに特別の注意を払うようにお勧めします。

WSDLを使用して実際のアプリケーションを短期的に実装しようとしている現場の開発者にとって、W3C Workshopがどのような意味を持つのかということに関連して、私がお勧めしたいことは、Web Servicesアーキテクチャーの中核的なコンポーネントに早く習熟できるように、いまから始めてくださいということです。まだ始めていない人は、SOAP、WSDL、そしてUDDIの学習を始めてください。読者がJava開発者である場合には、IBM Web Services Toolkitをダウンロードして、Web Servicesアーキテクチャーを体験してみてください。

参考文献

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=SOA and web services
ArticleID=242288
ArticleTitle=Web Servicesインサイダー: 第2回 W3C Web Services Workshopの要約
publish-date=042001