WSDLを使ったWebサービスインタフェースのモデリング：FTP Online

Webサービスのキーコンポーネント「WSDL」に関する全2回の解説のうち、第1回となる本記事では、Webサービスベースのインタフェースのモデリングにおける、新しいコンセプトに注目する（日本語訳：澤田侑尚）。

[Ash Parikh and Rajesh Pradhan，FTPOnline]

この数年におけるWebサービス利用の著しい成長は、誰もが認識するところだろう。多くの組織が、既存の開発資産を活用するための容易な方法としてWebサービス技術に注目している。しかし、ここで重要なのは、正確なWebサービスベースの設計方針の確立であり、それにより、ソリューションにおける信頼性およびメンテナンス性、相互運用性、再利用性が向上するのである。

　Webサービスを基盤とする技術でキーとなる要素は、WSDL（Web Services Description Language）である。CORBAにおけるIDL（Interface Definition Language）と同様に、WSDLはWebサービスの利用とそのインプリメンテーションの間を強力に媒介し、またアクセスされるアプリケーションを具体化するものでもある。

　W3C（World Wide Web Consortium）によると、WSDLはネットワークサービス記述のためのXMLフォーマットとして定義されるが、それはドキュメントオリエンテッドもしくはプロシージャオリエンテッドな情報を含むメッセージの、エンドポイント操作のセットに等しい（関連リンク参照）。

　しかし、自動処理またはWebサービスツールキットなどの魅力的な環境から、ほとんど思慮なく作成されるWSDLは、Webサービスの世界ではその存在にあまり気づかれていない。WSDLは単に自ら表現するネイティブインタフェースの奇行をシンプルに反映しているだけだからである。

　以下ではWSDLのモデリングを紹介していく。このWebサービスの設計と最良の事例が、WSDLの強制的な性能をテコとして、システムのリユーザビリティおよび携帯性、柔軟性、メンテナンス性を確実なものにする。

ビジネスプロセスとは？

　ビジネスプロセスとトランザクションは、有意義で協調性を持ったエンタープライズアプリケーションの基本であり、その心臓部分となる。ビジネスプロセスは、ステークホルダー（利害関係者）たちの役割および関連性、責任を示すタスクとスキーマのシーケンスとして記述できる。ビジネスコラボレーション、つまり可視化されたビジネスプロセスは、XMLにおいて表現されるモデルとして定義できる。

　それらの相互関係は、ビジネストランザクションにおける統制されたセットとして引き起される。ビジネストランザクションは最小単位のユニットとして考えることが可能で、それぞれのビジネストランザクションは電子的なドキュメントの、あらかじめ定義されている1つか2つのビジネスドキュメントフローのやり取りとして表現される。

　ここで視点を変えて、実行可能なビジネスプロセスと抽象的なビジネスプロセスの微妙な違いについて考えてみよう。実行可能なビジネスプロセスとは、ビジネスのプロセスに参加する人々の振舞いをモデル化したものである。それに対して抽象的なビジネスプロセスとは、組織間おける相互による可視化を指定する処理記述、もしくは相互に識別が可能なメッセージ交換のいずれかに属す。また、個々の組織内の振舞いを露呈することのない、ビジネスプロセスの関連性を示すものでもある。

　ビジネスプロセスにおけるオーケストレイションとコレオグラフィの違いを理解することも有益である。オーケストレイションとは、どのようにWebサービス同士が相互に影響し合うかを記述するもので、メッセージレベルで含むのは相互関係におけるビジネスロジックとオーダーの実行である。これは実行可能なプロセスで、Webサービスの内部と外部の双方に影響するものとなる。

　一方、コレオグラフィはメッセージのシーケンスを追尾するもので、顧客およびパートナー、サプライヤーなどの、多様な組織と多様な資源を関連させるものである。それは、関連する各組織間での協調プロセスであり、相互関係において行うべきパートを記述する。最近になって、これらのパラダイムは多少一元化されている。

　ビジネスプロセスを効果的に表現するには、最初にビジネスプロセスに関するモデルを定義する必要があるほか、顧客およびパートナー、内部構成要素など、業務を遂行する各種の人々の間の相互関係をも定義する必要がある。さらに、各種のタスクを正確に定義する必要があるが、それらはビジネスプロセスの中で正確に引き起されるものであり、完成に向けた体制的な要素と時間的な要素に対して、慎重に注意を払うべきである。

　いずれにせよ明らかなのは、我々がパワフルなデザインタイムツールを必要とすることであり、こうしたツールにより、エンタープライズアプリケーションにおけるビジネスプロセス間の、意味のあるトランザクションと協調的な相互関係を実現可能にするのである。

Webサービスツールキット

　現代的なWebサービスツールキットは、開発者がWSDLの定義を記述することを望んでいない。それどころか、WSDLをそんざいに扱っている。それらは既存のサーバサイドソースコード、例えばどんなカスタム言語のマッピングにでも基づくJavaクラスからWSDL定義を生成する。このWSDLが表現するものは、貴方と、貴方のサービスを使うユーザーとの間の契約である。現実の世界とは異なり、いくつかの理由から、この契約は精巧に作られる必要がある。

　真っ先に挙げられる理由は、誤りであると言われることに対して、将来的に訴訟を起されないことを確実にするためである。だからこそ、この契約は提供されるサービスについて（理想的には提供されないサービスについても）、可能な限り明快な用語で記述されるべきである。このWebサービスの契約書は、その価値を明確に伝えるべきであり、（もしあるならば）標準の言語を用いるべきだ。ビジネスコンポーネントを単純に露出する現状のアプローチは、ビジネスコンポーネントインタフェースに対する意味を伝播することの責任を、単純に先延ばしにしているだけだといえる。

　これらのインタフェースは、新しい要件を想定して設計されていないかも知れず、また、組織の内外で必要なサービスに対するコンポーネントのバージョニングを要求するだろう。このアプローチは、既存の生産資源に対する変更を要求する限り、大半のディプロイメントとサポートにおける悩みとなる。また内的なインタフェースは、それらが外部との協調のために展開される前に、いつもリエンジニアリングを要求する。思慮を伴わない内的なインタフェースの客観化は、最終的には予想以上に大きな問題となり得る。

　技術面に目を移してみると、すべのWebサービスツールキットが、オプションを等しくバインドするWSDLメッセージをサポートしている訳ではない。現状で、ほとんどのJavaツールキットはRPCエンコードのバインディングをデフォルトとするが、.NETツールキットのデフォルトはドキュメントリテラル（literal）のバインディングである。現在、WS-Iのウォーキングドラフトは、RPCエンコードのバインディングの使用を考慮していないが、RPCリテラルタイプの使用を除外してはいない。

　いくつかのツールキットは今後制限が予測されるタイプをサポートしているが、サポートしないツールキットもある。また、要求されるSOAPActionヘッダおよびパーオペレーション（per-operation）ベース要素の名前空間連携の、オーバーローディングをサポートするものもあれば、サポートしないものもある。

　このため、開発者がWSDLを理解していない場合、また、ツールキットのWSDL定義がデフォルトでサーバサイドのネイティブインタフェースから何を生成するかを知らない場合、また、ツールキットの振舞いに関するカスタマイズのやり方を知らない場合には、相互運用性を強制することは困難であり、不可能である。現実に開発者のコミュニティは、WSDL仕様のメッセージとバインディング、トランスポートの各セクションの具体的なパートに関する部分を、まだ明確にしていない。

　多くのツールキットはWSDLをオンザフライで生成する。ここでの最大の前提は、ユーザーがサーバの記述により開発を開始することであり、その後にWebサービスとしてエクスポーズすることである。ここで、クライアントの記述から始めたいと思ったらどうなるのだろうか？　従来からのRPCモデルでは、一度IDL内でインタフェースが定義されると、開発者はクライアントとサーバを別個に記述できた。現実に、前述のとおり、異なるプラットフォーム上でレガシーなデータソースをラッピングするために、CORBAは頻繁に利用された。一度インタフェースがCORBAのIDLで定義されると、サーバの記述と同時にクライアントの開発を行うことができたのである。クライアントの開発が完了したとき、同一のクライアントサイドのプロキシコードで、異なるサーバ内のオブジェクトをコールできた。いずれの場合も正確なオブジェクト参照が必要とされていた。

　したがって、WDSLの抽象概念とディレイドクリエーション（delayed creation）は、BPEL4WSおよびWS-Choreography、ebXMLのように、より完璧なWebサービスフレームワークを要求する。

　次回は、WSDL仕様に欠点はあるか、また、その作成に関する方式の中に問題があるかといった、さらに深い疑問の内容を探求していく。そして、より有益なWSDLを作成するために、UMLを活用する方式にたどりつくことになる。

執筆者について

Ash Parikh氏はIopsis Software Inc.のモバイル＆マーケティングドリブンエンジニアリングのディレクターである。分散コンピューティング分野の専門家であり、BEA e-World 2002およびJavaOne 2003、JavaOne 2002では抽象的観念を立案している。彼は10年以上の、コンピュータとITに関する経験を有しており、そこには、オブジェクト指向における分析と設計、および分散アーキテクチャ、ミドルウェアアーキテクチャ、ソフトウェア設計と開発などの専門技術も含まれる。 　また彼は、「Bay Area Chapter of the Worldwide Institute of Software Architects」のプレジデントでもある。多彩なソフトウェアアーキテクチャパラダイムに関する彼のエバンジェリズムを通じて、同組織はイニシアティブを発揮している。最近の共著にはOracle9iAS Building J2EE Applications（Osborne Press, November 2002）のほか、数多くの技術記事を執筆している。同氏へのコンタクトは [e-mail] まで。 　Rajesh Pradhan氏はIopsis Software Incの創業者兼CTOである。彼が共著する記事には、国際会議のためのアーキテクチャ的ストラテジーとオブジェクト指向アプローチに関するものがある。彼はヒューレッド・パッカードが特許出願中の「Retail Web Services Framework」の共同立案者であり、現在それは、HPのConsumer Business Systemsとともに10社以上の小売業者を統合するために利用されている。 　彼も「Bay Area Chapter of the Worldwide Institute of Software Architects」の創立メンバーであり、JCPやOASISなどの各種の標準化団体でIopsisを代表している。同氏へのコンタクトは [e-mail] まで。