Webサービスの約束を果たすために開発されている多数のテクノロジーは、(私たちの意見では) ようやく成熟期に達し、初期の誇大宣伝や大騒ぎを越えて地道な実践段階に入ろうとしています。2002年4月にGoogleは、開発者が自分のアプリケーションからWSDLおよびSOAPテクノロジーを使用して、20億を超えるWeb文書を直接照会できるようにすると発表しました。少なくとも、この発表は、Webサービスを現実的に応用するアイデアが、開発者の意識にしっかりと根を張り始めたことを示すものです。実際に、私たちの顧客サービス窓口では、ある傾向が見受けられます。顧客たち (決して熱烈な支持者というわけではありません) が、企業の内外でWebサービス・テクノロジーを一刻も早く採用しようと躍起になっているのです。

しかし、こうしたテクノロジーを適用しようとしている多くの開発者やアプリケーション設計者にとって大きな障害となっているのは、にぎやかな宣伝文句があふれているにもかかわらず、SOAP、WSDL、UDDIなどの新規テクノロジーを実際のビジネス・シナリオに最もうまく適用するために役立つ指針が、現在のところほとんどないということです。こうした不備に気付いて、IBMのGlobal Services、jStart、およびEmerging Technologies Groupsから集まった多数の開発者および設計者が、Webサービス・テクノロジーをシナリオに応じて現実的に応用するベスト・プラクティスのコレクションを識別し、文書化することに努めました。

そのプロセスは単純明快です。私たちの方式にとって重要なことは、実際のビジネス・シナリオ (かくあるべきという考え方を説明するためにひねり出した架空のシナリオではなく、顧客が自分たちのビジネスにおける現実の問題を解決するために、それらのテクノロジーを実際に 適用している状況) に目を向けることです。これらのシナリオで、私たちは次のような非常に重要なことを問いかけています。

• そのソリューションのビジネス目標はどのようなものか?
• そのソリューションはどのような一般的なe-businessパターンを実践しているか?
• アプリケーションの論理アーキテクチャーはどのようになっているのか?
• そのアプリケーションを構築するためにWebサービス・テクノロジーをなぜ、どこで、どのように使用したのか?
• そのアプリケーションでWebサービスを使用して、どのような利益が実現できたのか?
• 使用するテクノロジーおよび方法論について、(肯定的な面と否定的な面の両方) どのようなことを学習できたか?

この記事は、私たちの調査結果を詳細に記録し、組織的に検討を加えるシリーズの第1回です。このシリーズは、ソリューション設計者、および特定のプロジェクトのためにWebサービスのテクノロジーと設計方法論をどのように採用するのか (あるいは、採用すべきかどうか) を決定する立場にある人々に、大いに役立つことでしょう。シリーズのロードマップは、分かりやすくできています。最初に土台を築き、さまざまなベスト・プラクティスの識別と分類のために使用した用語および方法を説明します。このプロセスには、専門用語、つまり一般的な用語のセットを定義するこの第1回、およびIBMのe-businessパターン (参考文献を参照)とベスト・プラクティス作業との関連を説明する第2回の記事が含まれます。第3回以降の記事では、実際のビジネス・シナリオのコレクションに関する上記のそれぞれの質問を扱います。最後は、ベスト・プラクティスのセットに関する私たちの提案を述べる記事で締めくくる予定です。

Webサービスとは何か?

Webサービスを巡る初期の騒ぎがはなはだしかったため、Webサービスとは何か、そしてそれらをどのように実践するのかを記述するための用語が、あまりに不明瞭になりつつあることは、率直に認めるべきであると思います。事実、最近組織されたW3C Web Services Architecture Working Groupが直面した最も困難な作業の1つは、Webサービスの一般的な定義はどのようなものか? という、一見簡単に思える質問にどう答えるかということでした。これだけもてはやされていることを考えると、Webサービスの定義に苦労することはなさそうに思えます。しかし、あり余るほど多くの定義があり、しかもその多くが矛盾を含み、Webサービスとはどういうものでありうるのか、またどういうものになりうるのかということを断片的にしか示していないという事態は、なんとか打開しなければなりません。

ベスト・プラクティスのコレクションから不純物を取り除くための第一歩として最も重要なことの1つは、さまざまな核となる概念を記述する用語を明快、簡潔、かつ正確なものにすることです。残念ながら、(既存の名称または用語がどのような混乱を引き起こす可能性があるかにかかわらず) すでに受け入れられている既存の専門用語の枠内で作業を行う必要があります。例えば、SOAPプロトコルそのものが、Webサービスの世界で誤って命名されたテクノロジーの典型なのです。SOAPという頭字語はSimple Object Access Protocol を意味しますが、これはメッセージング・プロトコル仕様を表していて、オブジェクトとはほとんど関係がなく、そのインプリメントは、シンプルとはほど遠いものです。

W3C Web Services Architectureグループで合意に達したWebサービスの実用的な定義は、次のようなものです。

Webサービスとは、URIによって識別されるソフトウェア・アプリケーションであって、そのインターフェースおよびバインディング情報は、XMLの技術によって定義、記述、検索が可能であり、インターネット・プロトコルを介したXML書式のメッセージを使用して、他のソフトウェア・アプリケーションとの直接的なやりとりをサポートするものである。

Webサービスは、(従来のSOAP株価情報サービスのように)HTTP接続を介してアプリケーションのメソッドを呼び出すために使用されるSOAPメッセージに限定されると考える人は、この定義にやや驚きを感じるかもしれません。しかし、この定義は、共通の専門用語という私たちの目標に関係する、以下の興味深い事実を示しています。

• WebサービスはSOAPを必要としない。
• WebサービスはHTTPを必要としない。

ただし、Webサービスは (W3Cによって定義されているように)、そのサービスの形態および機能を記述するために使用することのできる、XMLベースのなんらかの記述メカニズム (WSDLなど) を確かに必要とします。このような、業界をあげてのWebサービス・テクノロジー熱の背景として、サービス指向アーキテクチャー (SOA、詳しくは下記の参考文献セクションを参照) がありました。非XMLベースの記述メカニズム (IDLなど) ではSOAインプリメンテーションが複雑になり、またオープン性が低下したことでしょう。

また、W3Cの定義は、サービスの発見には言及していますが、UDDIまたはその他の特定の発見メカニズムには言及していません。この事実は、私たちがさまざまなビジネス・シナリオを扱い、なぜ、またどのようにして特定のサービス発見メカニズムが使用されるのか探る際に重要になります。特に、Webサービス・アーキテクチャーについて書かれた初期の文献は、UDDIには中核となる基本的な役割があると断言していましたが、Webサービスによってビジネス・ソリューションを現実にインプリメントしてみると、UDDIの最も顕著な役割が、実際には完全に特殊化されたものであることが明らかになりました。事実、多くのWebサービス・ソリューションは、いかなる方法でもUDDIを使用しないように構築されているのです。現在の非常に多くのビジネス事例ではこれらの発見メカニズムは、まだビジネス・パートナー間でのプロセスを統合するための中核コンポーネントとなっていないと言って差し支えないでしょう。

上に戻る

用語の定義、焦点の絞り込み

厳密な意味でWebサービスと呼ぶことのできるものの範囲に、XMLを使用して固有に識別し、記述することのできる任意の ソフトウェア・コンポーネントが含まれるという点で、W3CによるWebサービスの定義が与えた衝撃は大きなものでした。この範囲は、潜在的には無制限であり、ベスト・プラクティスのセットの概要を示すために、まったく何の役にも立ちません。Webサービス という用語自体は、幅広いW3C定義に適合するアプリケーションの全範囲を漠然と表すにすぎません。このような多くのアプリケーションが、Webや、Webの構築の基礎となっているテクノロジーにかかわっている可能性はまずないからです。しかし、なんとかして、Webサービス という用語を私たちの専門用語に組み込まなければなりません。この用語はすでに、私たちの会話に登場するテクノロジーの分野と関連を持ってしまっているからです。

顧客シナリオの分析を開始したときに私たちが発見したのは、使用可能なさまざまな記述、メッセージ、およびトランスポート・プロトコルを使用したときに現れる、Webサービスの各種のサブタイプ を区別するための、新しい視点および専門用語を考え出す必要があるということです。私たちは図1 に示すベン図からスタートしました。この図は、オープン・プロトコルのうち、サービス指向アプリケーションで使用される可能性のあるものとないものの範囲を識別しています。

図1 から、私たちの新しい専門用語に最初の2つの定義がもたらされました。

• Webサービス とは、以下の3つの基本的なテクノロジー・カテゴリーに属する特定のテクノロジーを使用して開発された、ソフトウェア・コンポーネントである。
  • XMLベースの記述形式 (例えば、WSDL)
  • アプリケーション・メッセージング・プロトコル (例えば、SOAP)
  • コレクションまたはトランスポート・プロトコル (例えば、HTTP)
  これらの各カテゴリー内では、プロプラエタリーな (ベンダーまたはプラットフォーム固有の) テクノロジーと、オープンな (ベンダーまたはプラットフォーム独立の) テクノロジーが使用可能である。
• サービス指向アプリケーション には、SOAPなどのWebサービス・テクノロジーを使用する可能性のあるアプリケーションが含まれるが、WSDLまたはその他のXMLベースの記述は含まれない。このようなアプリケーションは擬似Webサービス であると見なされるが、技術的にはWebサービスではない。

W3Cの定義および図1 のベン図を考慮すると、なんらかのXMLベースの記述メカニズムを使用して記述されたソフトウェアは、Webサービスとして適格であると言えます。このようなアプリケーションが他のなんらかのWebサービス・テクノロジーを使用しているかどうかは、問題ではありません。プログラム言語に依存するメッセージング・プロトコル (例えば、JMS) およびプロプラエタリーなトランスポート・プロトコル (例えば、MQSeries) を使用するアプリケーションを、そのアプリケーションのインターフェースをWSDLで記述するだけで、完全準拠のWebサービスにすることが可能です。逆に、HTTPを介してSOAPメッセージを送信するアプリケーションであっても、WSDL記述が提供されていない場合には、擬似Webサービスと見なされ、またサービス指向アプリケーションとして見なされますが、Webサービスとして適格ではありません。

したがって、Webサービスに関する私たちの新しい定義に基づいて、図1 の中の「オープンXMLベースの記述」を表す円に注目してみましょう。そのうえで、Webサービス・テクノロジーが当初目標にしていた厄介な部分、すなわち統合とインターオペラビリティーに注目しましょう。これら2つの厄介な部分は、企業の内部および外部の両方におけるアプリケーション開発に関係しています。事務部門で古くから受け継がれているCOBOLアプリケーションと統合する必要があるのか、あるいはなんらかの外部サーバーにある分散アプリケーションとインターネット経由で統合する必要があるのかにかかわらず、統合とインターオペラビリティーを容易に行えるようにするために、アプリケーションに抽象化するポイントを組み込む必要があります。この分野におけるデファクト・スタンダードの記述言語はWSDLです。これは、サービスのインターフェースおよびインプリメンテーションに関する抽象レイヤーを提供するために作成されたものです。

WSDLは選択の対象として可能性のある、オープンXMLベースの記述言語の1つであるため、Webサービスのカテゴリーの中には、記述プロトコルとしてWSDLを使用するものが存在します。図2では、このようなWebサービスのサブセットを示し、そこから私たちの専門用語に3つの新しい定義を追加しています。

• エンタープライズWebサービスは、WSDL記述を備えていながら、プロプラエタリーなアプリケーション・メッセージングまたはトランスポート・プロトコルを使用する可能性のあるWebサービスです。このようなサービスの例として、JMSを使用してIBM MQSeries経由でSOAPメッセージを送信するサービスがあります。
• インターネットWebサービスは、オープンなアプリケーション・メッセージングまたはトランスポート・プロトコルのみを使用しなければならないエンタープライズWebサービスです。このようなサービスの例として、HTTP経由でOTA XMLメッセージを送信するサービスがあります。
• XML Webサービスは、インターネットWebサービスのきわめて小さなサブセットであって、限られた範囲のトランスポート・プロトコルを介して、W3Cが採用したXMLベースのメッセージング・プロトコルを使用しなければならないものを表します。具体的には、XML WebサービスはSOAPメッセージのみを、HTTP、SMTP、またはTCP/IP直接接続をのみを介して送信します。

これらの新規定義は、最近数年にわたり業界内の多くの人々が抱いていた概念を取り込んだもので、オリジナルのWebサービス という (多くの概念を詰め込みすぎた) 用語が取り込もうとしながら明瞭に表現できなかった、コンポーネントのサブセットをカテゴリー化するための、意味体系の枠組みを備えています。例えば、Microsoftの .Net戦略はXML Webサービスに焦点を合わせていますが、CommerceQuestのCICS Process Integrator (CPI) はエンタープライズWebサービスに焦点を合わせています。この新しい専門用語は、Webサービス・テクノロジーに関する両社の意図を理解するための枠組みを提供します。

上に戻る

これから行うこと

最初に述べたように、このシリーズの目標は、実世界のさまざまなビジネス・シナリオを探究し、それを基に、企業環境におけるWebサービスを設計および実現するためのベスト・プラクティスのコレクションを築き上げることです。このシリーズの今後の記事では、それぞれ1つずつシナリオを取り上げ、この第1回の記事で紹介した用語およびカテゴリーを使用して、私たちが発見した内容を分類します。このプロセスの重要な要素は、ここでの演習が、今日行えることに関する見解を十分に反映した、実世界のシナリオのみを扱うということです。理論や、「もしも」という仮定の話は論じないことにします。定評のある一般的な設計パターン、戦略、および企業における開発のベスト・プラクティスに照らして、各シナリオを分析し、評価することにします。また、特定の状況でWebサービス・テクノロジーを使用することが設計にどのように役立ったのか (あるいは妨げとなったのか) を、包み隠さずにお知らせすることにします。

Webサービスは万能の解決策ではありませんが、多くの顧客にとって、きわめて適切な選択肢となります。企業内で他に替えがたい役割を演じます。私たちは、設計者や開発者がe-businessアプリケーションにWebサービス・テクノロジーを組み込むために役立つ、ベスト・プラクティスのセットを提供したいと考えています。

参考文献

• W3C Webサイトは、ここで取り上げた多くの標準へのリンクを提供しています。
  
  
• OASIS は、いくつかのXMLベースの標準およびテクノロジーに焦点を合わせています。
  
  
• Web Service Description Language (WSDL)のバージョン1.1を検討してみてください。
  
  
• GoogleのWebサービス・オファリングの詳細については、Google Tests Search Tools for Developers、Stephanie Olsen著 (CNet、2002年4月) を参照してください。
  
  
• GoogleのWebサービスAPIについては、同プロジェクトのホーム・ページを参照してください。
  
  
• サービス指向アーキテクチャーについては、e-businessサービスの道、Steve Burbeck著 (developerWorks、2000年10月) を参照してください。
  
  
• IBM's patterns for e-business を参照してください。
  
  

著者について

この記事を評価する

コメント

上に戻る

目次

• Webサービスとは何か?
• 用語の定義、焦点の絞り込み
• これから行うこと
• 参考文献
• 著者について
• コメント