2.1.2.1 例の説明 (Explanation of Example)

<description

全てのWSDL 2.0文書は、最上位要素としてdescription要素を持つ。 これは単に、そのWSDL 2.0文書の残りの部分のコンテナとして働き、その文書を通して利用される名前空間の宣言に使われる。

xmlns="http://www.w3.org/ns/wsdl"

これがWSDL 2.0自身のXML名前空間である。我々は、これに対する接頭辞を定義しないことによって、この例のデフォルト名前空間として割り当てた。 言い換えると、この例に現れる接頭辞のないあらゆる要素は、WSDL 2.0要素であると期待される（例えばdescription要素。）

targetNamespace="http://greath.example.com/2004/wsdl/resSvc"

ここでは、先に述べたGreatH予約サービスのために我々が選択したWSDL 2.0ターゲット名前空間を定義している。 これが実際のXML名前空間宣言ではないことに注意して欲しい。 より正確には、これはXML Schemaターゲット名前空間と類似した目的を持つWSDL 2.0属性である。

xmlns:tns="http://greath.example.com/2004/wsdl/resSvc"

これが、我々のGreatHサービス記述で使うための実際のXML名前空間宣言である。 このURIが、先ほどtargetNamespace属性の値として指定したものと同じであることに注意して欲しい。 こうすることによって、我々は後に、GreatHサービスのWSDL 2.0ターゲット名前空間を参照するために、Qnameの中でtns:接頭辞を使えるようになる。（QNameに関する詳細は、[XML Namespaces]第3セクションQualified Namesを参照。）

これで、我々はGreatHサービスを記述し始めることができる。

2.1.3.1 例の説明 (Explanation of Example)

xmlns:ghns = "http://greath.example.com/2004/schemas/resSvc"

我々は別の名前空間宣言を追加した。ghns名前空間接頭辞は、（あとでインタフェースを定義するときに）我々のメッセージ型を定義するXML Schemaターゲット名前空間を参照できるようにする。つまり、我々が指定したURIは、XML Schema型のターゲット名前空間として定義するURI（次を参照）と同じでなければならない -- WSDL 2.0文書自身のターゲット名前空間ではない。

targetNamespace="http://greath.example.com/2004/schemas/resSvc"

これがXML Schemaターゲット名前空間である。これは、GreatH予約サービスのために作ったものである。checkAvailability、checkAvailabilityResponseおよびinvalidDataError要素名は、このXML Schemaターゲット名前空間と結び付けられる。

checkAvailability、checkAvailabilityResponseおよびinvalidDataError

これらは、我々が用いるメッセージ型である。先ほど説明したように、これらがXML要素となるように定義されていることに注意して欲しい。

我々は幾つかの型を定義してきたが、我々はまだどれがWebサービスで使われるメッセージ型なのかを示していない。次の節ではそれをやってみよう。

2.1.4.1 例の説明 (Explanation of Example)

<interface name = "reservationInterface">

インタフェースは、description要素の直接の内側で宣言される。 この例では、我々はインタフェースを一つだけ宣言しているが、一般的には、WSDL 2.0文書は一つ以上のインタフェースを宣言してよい。 つまり、各々のインタフェースには、このWSDL 2.0名前空間で定義されるインタフェースの集合のなかで一意になる名前を与えなければならない。 インタフェース名は、スペースやコロン (":")を含んではならないトークンである。

<fault name ="invalidDataFault"

name属性は、このフォルト (fault)の名前を定義する。 この名前は、オペレーションが定義されるときに、望んでいるフォルトを名前で参照できるようにするために要求される。 フォルト名は、インタフェース内で一意であれば良い。

element ="ghns:invalidDataError"/>

element属性が指定するのは、先にtypesの節で定義した、フォルト・メッセージのスキーマタイプである。

<operation name="opCheckAvailability"

name属性が定義するのは、このオペレーションの名前である。 こうすることによって、後で、バインディングが定義されるときに、参照可能になる。 また、オペレーション名は、インタフェース内で一意でなければならない。 （WSDL 2.0では、オペレーション名とフォルト名に対して、別々のシンボル空間を用いるので、オペレーション名"foo"はフォルト名"foo"とは区別される。）

pattern="http://www.w3.org/ns/wsdl/in-out"

この行が指定するのは、このオペレーションが、先に説明したin-outパターンを使うことである。 WSDL 2.0では、誰かが将来、新しいパターンを定義できるようにするために、識別子がグローバルに重複しない（unambiguous）ことを確保できるよう、メッセージ交換パターンを識別するためにURIsを用いる。 （しかしながら、誰かが新しいパターンを定義し、それを識別するためのURIを作ったからといって、他のWSDL 2.0処理系が自動的にそのパターンを認識、あるいは解釈できるようになるわけではない。他の拡張と同様、それを認識して解釈しようとする処理系でだけ利用できる。）

style="http://www.w3.org/ns/wsdl/style/iri"

この行は、このサービスの入力メッセージを定義するXMLスキーマが、IRI Styleで指定される規則の集合に従っていることを示している。IRI Styleは、そのメッセージが、IRIとしてシリアライズされることを保証している。

wsdlx:safe="true" >

この行は、このオペレーションが、どういう形であれクライアントに責務を負わせないことを示している。つまり、クライアントは、そのサービスが責務を課すかもしれないこと（例えば、何かの購入に同意すること）を恐れることなく、そのオペレーションを安全に呼び出せる。このことは、2.4.4 インタフェース・オペレーションで更に説明する。

<input messageLabel="In"

input要素は入力メッセージを指定する。我々が既にそのオペレーションが利用するメッセージ交換パターンを指定していても、メッセージ・パターンが表現するのはメッセージ・シーケンスのテンプレートであり、理論的には、複数の入力および／または出力メッセージで構成されるかもしれない。 従って、我々は、この特定の入力メッセージが表現するのが、そのパターンにおいて可能性のある入力メッセージのうちのどれであるかも、示さなければならない。 これがmessageLabel属性の目的である。 我々が選んだin-outパターンには唯一つの入力メッセージしかないので、この場合は当然の結論になる：我々は単に、メッセージ・ラベルに"In"を埋めるだけである。このラベル"In"は、in-outパターンを説明したWSDL 2.0定義済み拡張 [WSDL 2.0 Adjuncts]第2.2.3節In-Outで定義されている。 しかしながら、もし新しいパターンが複数の入力メッセージを含むように定義されていれば、そのパターンの異なるメッセージは異なるラベルを使って区別されることになるだろう。

element="ghns:checkAvailability"/>

ここでは、この入力メッセージに対するメッセージ型を指定している。typesの節で定義済みのとおりである。

<output messageLabel="Out" . . .

これは入力メッセージの定義と同様である。

<outfault ref="tns:invalidDataFault" messageLabel="Out"/>

ここでは、フォルト出力をこのオペレーションと結び付けている。 フォルトは、正常メッセージとは若干異なって宣言される。 ref属性が参照するのは、そのインタフェースで既に定義済みのフォルトの名前である -- メッセージスキーマタイプを直接指定するわけではない。 メッセージ交換パターンは、一般的には、複数メッセージのシーケンスを含むので、フォルトはそのメッセージシーケンスのさまざまな場所で発生する可能性がある。 異なるフォルトを、そのシーケンス内の各々の許されたポイントに結び付けたいときは、この特定のフォルトに対する望むポイントを示すために、messageLabelが使われる。 パターンによって、このフォルトのトリガとなるメッセージと、フォルトが置換するメッセージのどちらかを指定することによって、間接的に行う。 （幾つかのパターンがmessage-triggers-fault規則を利用している；他のものはfault-replaces-message規則を利用している。WSDL 2.0定義済み拡張 [WSDL 2.0 Adjuncts]第2.1.2節メッセージによるフォルトの起動および第2.1.1節フォルトによるメッセージの置換を参照。）

ここまでで、我々は、GreatHサービスに対する抽象インタフェースを定義した。それに対するバインディングを定義する準備ができた。

2.1.5.1 例の説明 (Explanation of Example)

xmlns:wsoap="http://www.w3.org/ns/wsdl/soap"

我々は、二つの名前空間宣言を追加した。一つは、WSDL 2.0 Part 3 [SOAP 1.2 Part 1: Messaging Framework]で定義されているSOAP 1.2バインディング拡張の名前空間である。そこでは、接頭辞wsoap:を持つ要素と属性の構造が定義されている。

xmlns:soap="http://www.w3.org/2003/05/soap-envelope"

この名前空間は、SOAP 1.2仕様自身で定義されている。 SOAP 1.2仕様では、特定のコンセプトを明確に識別する、この名前空間内の特定の用語を定義している。 つまり、それらの用語の一つを参照する必要があるときは、soap:接頭辞を利用することになる。

<binding name="reservationSOAPBinding"

バインディングは、description要素の直接的な内側で宣言する。 name属性が定義するのは、このバインディングの名前である。 各々の名前は、WSDL 2.0ターゲット名前空間内の全てのバインディングを通して一意でなければならず、あとで、このバインディングを参照するサービス・エンドポイントを定義するときに利用する。 WSDL 2.0では、インタフェース、バインディング、サービスのために、別々のシンボル空間を利用するので、インタフェース"foo"と、バインディング"foo"とサービス"foo"は区別される。

interface="tns:reservationInterface"

これは、我々が指定するメッセージ・フォーマットと転送プロトコルに対するインタフェース名である。 2.5 バインディングの詳細で議論されているように、interface属性を省略することで、再利用可能なバインディングを定義することが可能になる。 また、tns:接頭辞を利用していることにも注意して欲しい。この接頭辞は、このWSDL 2.0文書に対する定義済みのWSDL 2.0ターゲット名前空間を参照している。この場合は、tns:接頭辞を指定しなければならないことが馬鹿らしく思えるかもしれないが、3.1 WSDLのインポートで、WSDL 2.0のインポーティング・メカニズムが、異なるWSDL 2.0ターゲット名前空間で定義されたコンポネントを、どのように結合できるかを見ることになる。

type="http://www.w3.org/ns/wsdl/soap"

これは、利用する具体的メッセージフォーマットの種類を指定する。この場合はSOAP1.2である。

wsoap:protocol="http://www.w3.org/2003/05/soap/bindings/HTTP/"

この属性は、WSDL 2.0のSOAPバインディング拡張に固有の属性である（そのため、wsoap:接頭辞を使っている）。 これは、下層で利用されるべき転送プロトコルを指定する。この場合はHTTPである。

<operation ref="tns:opCheckAvailability"

これは新しいオペレーションを定義しているわけではない；正しくは、定義済みのopCheckAvailabilityオペレーションを、そのバインディングの詳細を指定するために、参照している。 この要素は、代わりにデフォルト規則が必要な情報を提供するために使えるのであれば、省略することができる。（WSDL 2.0 Part 2 [WSDL 2.0 Adjuncts]第4.3節Default Binding RulesのSOAPバインディング拡張を参照。）

wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response">

この属性も、WSDL 2.0のSOAPバインディング拡張に固有である。 これは、opCheckAvailabilityオペレーションが定義されたときに指定された、抽象WSDL 2.0メッセージ交換パターン（in-out）を実装するために使われるSOAPメッセージ交換パターン (MEP)を指定する

下層の転送プロトコルにHTTPが使われるときは（この例の場合）、wsoap:mep属性で下層のHTTPメソッドとしてGETとPOSTの何れが使われるのかも制御する必要がある。 この場合は、wsoap:mep="http://www.w3.org/2003/05/soap/mep/soap-response"を利用していることが、デフォルトでGETが使われる原因となっている。2.5.7 HTTP GET対POST: どちらを使うか？も参照。

<fault ref="tns:invalidDataFault"

バインディング・オペレーションと同様、これは新しいフォルトを宣言しているわけではない；正しくは、opCheckAvailabilityインタフェースで定義済みのフォルト（invalidDataFault）を、そのバインディングの詳細指定するために、参照している。

wsoap:code="soap:Sender"/>

この属性も、WSDL 2.0のSOAPバインディング拡張に固有である。 これは、SOAP 1.2フォルト・コードを指定している。この指定によって、フォルト・メッセージが送信される。 もしそうしたいのであれば、任意指定のwsoap:subcodes属性を用いて、サブコードのリストを指定することもできる。

2.1.6.1 例の説明 (Explanation of Example)

<service name="reservationService"

ここでは、このサービスの名前を定義している。そのWSDL 2.0ターゲット名前空間内のサービス名を通して一意でなければならない。 name属性は必須である。WSDL 2.0記述でコンポネントを識別するためにURIsを作ることが許されている。 （WSDL 2.0 Core Language [WSDL 2.0 Core] appendix C IRI References for WSDL 2.0 constructsを参照。）

interface="tns:reservationInterface">

ここでは、これらのエンドポイントがサポートする定義済みのインタフェースの名前を指定している。

<endpoint name="reservationEndpoint"

ここでは、サービスに対するエンドポイントと、そのエンドポイントの名前を定義している。エンドポイント名は、このサービス内で一意でなければならない。

binding="tns:reservationSOAPBinding"

ここでは、このエンドポイントで使われる定義済みのバインディングを指定している。

address="http://greath.example.com/2004/reservation"/>

ここでは、binding属性で指定されてバインディングを使ってこのサービスにアクセスできる物理的なアドレスを指定している。

That's it! だいたい終わった。

2.1.7.1 例の説明 (Explanation of Example)

<documentation>

この要素は任意選択であるが、含めておくのは良いことである。この要素の内容には、任意の要素を混ぜて含んでよい。

at http://greath.example.com/2004/reservation-documentation.html

含めるべき最も重要なことは、そのサービスを利用するためにクライアント開発者が必要な全ての追加文書に対するポインタである。

これでGreatHサービスの例の提示が完了した。後続の節では、我々はWSDL 2.0仕様のさまざまな面に関する更なる詳細を見ていくことになる。

2.2.2.1 WSDL 2.0要素の順序 (WSDL 2.0 Element Ordering)

この節では、最上位のWSDL 2.0要素の順番に関して、WSDL 2.0仕様がWSDL 2.0スキーマをどのように制約するかの例を与える。

WSDL 2.0スキーマが要素の順序についての要求を示していないくても、WSDL 2.0仕様（WSDL 2.0 Part 1 [WSDL 2.0 Core] section "XML Representation of Description Component"）では、description要素の子要素がどのような順序を持つべきかの制約の集合を明確に表明している。 こうして、WSDL 2.0スキーマがこの制約を含んでいないとしても、WSDL 2.0要素の順序は問題となる。

次の例は、description要素の擬似内容モデルである。

<description>
  <documentation />?
  [ <import /> | <include /> ]*
  <types />?
  [ <interface /> | <binding /> | <service /> ]*
</description>

言い換えると、description要素の子要素は、次のように並ぶべきである：

• もしあれば、任意指定のdocumentation要素が最初に来る。

• 次に、次のものの中から、任意の順序で、ゼロ個以上の要素が来る：

  • include

  • import

  • 拡張要素

• 任意指定のtypes要素が続く

• 次のものの中から、任意の順序で、ゼロ個以上の要素が来る：

  • interface

  • binding

  • service

  • 拡張要素

ここでは「拡張要素」という用語は、名前空間指定された拡張要素を指す便法として遣われている。 それらの拡張要素の名前空間名は、"http://www.w3.org/ns/wsdl"であってはならない。

2.2.3.1 WSDL 2.0インポートとインクルード (WSDL 2.0 Import and Include)

WSDL 2.0コンポネント・モデルは、特に、import and include要素の意味を定義するのに役に立つ。 include要素のおかげで、名前空間のコンポネントを定義する複数のWSDL 2.0文書から、与えられたWSDL 2.0名前空間の内容をつなぎ合わせることができる。 ある与えられたWSDL 2.0文書で定義される複数のコンポネントは、その文書に定義が含まれるものと、include要素によってその文書に含まれるWSDL 2.0文書で定義されるものから構成される。 include要素の効果は、もし文書Aが文書Bを含み、文書Bが文書Cを含むのであれば、文書Aによって定義されるコンポネントは、文書A, B, Cに含まれる定義によって構成されるという、蓄積的なものである。

対照的に、import 要素は、いかなるコンポネントも定義しない。 代わりに、import要素が宣言するのは、与えられたWSDL 2.0名前空間に対するWSDL 2.0文書に定義が含まれるコンポネントが、別のWSDL 2.0名前空間に属するコンポネントを参照することである。 もし、WSDL 2.0文書が他の名前空間を参照するコンポネント定義を含むのであれば、それらの名前空間はimport要素で宣言されていなければならない。 import要素はまた、任意指定のlocation属性を持っていて、これは、処理系に対して、インポートされた名前空間の定義がどこで得られるかのヒントになる。 しかしながら、処理系は、他の手段、例えば、カタログを利用することで、定義を見つけるかもしれない。

なんらかのinclude要素が処理され、なんらかのインポートされた名前空間に属するコンポネントの場所が特定された後は、そのWSDL 2.0文書のWSDL 2.0コンポネント・モデルは、その文書のWSDL 2.0名前空間となんらかのインポートされた名前空間と属するコンポネント群の集合を含むようになる。 これらのコンポネントは、通常はQName参照によって、お互いに参照しあう。 もし何らかのコンポネント参照が解決できないのであれば、その参照されているコンポネントが属している名前空間が、同じものであれ、別のものであれ、そのWSDL 2.0文書は不正である。

WSDL 2.0のインポートとインクルードの使い方については、3.1 WSDLのインポートで、より多くをカバーする。

2.4.4.1 オペレーション属性 (Operation Attributes)

operationは、二つの必須属性と、一つの任意属性を持つ：

• 必須name属性は、既に見てきたとおり、インタフェース内で一意でなければならない。

• 必須pattern属性の値は、そのオペレションに対して望んでいるMEPを識別する絶対URIでなければならない。MEPsについては、2.4.4.3 メッセージ交換パターン(Message Exchange Patterns (MEPs))の理解で更に説明されている。

• 任意style属性の値は、絶対URIsのリストである。各々のURIは、このoperation定義で従うある規則集合を識別する。もし、特定のスタイルが指定されているが、関連する規則が守られないのであれば、エラーである。[WSDL 2.0 Adjuncts]では、次のものを含むスタイルの集合が定義されている

  • RPCスタイル。RPCスタイルは、styleの値にhttp://www.w3.org/ns/wsdl/rpcを割り当てるときに選択される。 リモートプロシジャーコール型のやりとりに制約とするときに使われる。

  • IRIスタイル。IRIスタイルは、styleの値にhttp://www.w3.org/ns/wsdl/style/iriを割り当てるときに選択される。 HTTP URLエンコードのような形にシリアライズされるかもしれないメッセージ定義の制約に使われる。

  • Multipartスタイル。Multipartスタイルは、styleの値にhttp://www.w3.org/ns/wsdl/style/multipartを割り当てるときに選択される。 HTTPバインディングでは、XFormsクライアントに対して、メッセージはMultipartスタイルに従って定義し、"Multipart/form-data"としてシリアライズされなければならない。

  これらのWSDL 2.0定義済みスタイルの更なる詳細を見つけることができる。 4.3 RPC Style節では、RPC styleの利用例を提供する。 [WSDL 2.0 Adjuncts]では、IRIスタイルとMultipartスタイルの例を提供する。

[WSDL 2.0 Adjuncts]がオペレーションの安全性を示す定義済み拡張を提供することに注意して欲しい。 ブーリアン値を持つwsdlx:safeグローバル属性は、クライアントからの呼び出しに対して、そのオペレーションが"safe"である（Section 3.5 of the Web Architecture [Web Architecture]で定義されている）と注釈されているかどうかを示すためにオペレーションに指定できる。 本質的には、安全なオペレーションとは、クライアントに対していかなる新しい責務も負わせない任意のオペレーションのことである。 例えば、クライアントが製品の価格を確認できるオペレーションは、通常はクライアントにそれらの製品を購入させる責務を負わせないであろうから、安全であるだろう。一方、製品購入のオペレーションは、クライアントに注文された製品に対する支払いの責務を負わせるだろう。

Web Architecture [Web Architecture]のセクション3.5で定義されている安全なやり取りの条件を満たすのであれば、オペレーションは安全であるとマークされるべき（このマークにはwsdlx:safeを用い、その値には"true"をセットする）である。 このことによって、基盤が有効な最適化、例えば、プリ・フェッチ、リフェッチ、キャッシングなどを行えるからである。

この属性のデフォルト値は偽(false)である。 もし偽または何も設定されていないのであれば、そのオペレーションの安全性については一切注釈されない；つまり、そのオペレーションは、安全であるかもしれないし、そうでないかもしれない。

2.4.4.2 オペレーション・メッセージ参照 (Operation Message References)

operationは、子要素として、input, output,infault, and/or outfault要素を持つ。これらの子要素で、そのオペレーションによって使われる正常メッセージ型とフォルト・メッセージ型を指定する。 pattern属性によって指定されるMEPは、これらの要素のどれがインクルードされるべきかを決定する。 各々のMEPは、そのパターンに含まれるメッセージタイプのための、プレイスホルダーを持つからである。 The MEP specified by the pattern attribute determines which of these elements should be included, since each MEP has placeholders for the message types involved in its pattern.

オペレーションについては、既に2.1.4 Defining an Interfaceで議論されているので、このセクションでは、先ほど説明されていない追加の機能に関してコメントするだけにする。

2.4.4.3 メッセージ交換パターン(MEPs)の理解 (Understanding Message Exchange Patterns (MEPs))

WSDL 2.0メッセージ交換パターン(MEPs)は、オペレーション内の抽象メッセージのシーケンスとカーディナリティを定義するために使われる。 設計上は、WSDL 2.0 MEPsは抽象である。 まず第一に、特定のメッセージ型を抽象化する。 MEPsはメッセージのプレイスホルダーを指定し、プレイスホルダーは、オペレーションが定義されるときに特定のメッセージ型と結び付けられる。ここでは、そのオペレーションのためにどのMEPが使われるのかの指定が含まれる。 第二に、他に明示的に表明されていない限り、MEPsはメッセージ間のタイミングや、そのパターンが同期か非同期か、メッセージ送信が単一チャネルか複数のチャネルかといったような、バインディング固有の情報も抽象化する。

WSDL 2.0 MEPsがサービスと他のノードの間で交換され得るメッセージのセットを余すところなく記述しているわけではないことを指摘しておくことは重要だ。 幾つかの事前の合意によって、他のノードと/やサービスがMEPによって記述されていない他のメッセージを（お互いに、または他のノードへ）送っても良い。 例えば、MEPがサービスから他のノードへ送られる単一メッセージを定義したとしても、そのMEPによって定義されたサービスがそのメッセージを他のノードへマルチキャストしても良い。 再利用を最大化するために、WSDL 2.0メッセージ交換パターンは、他の組織やWebサービスとの間の、最小の契約しか指定しないし、そのサービスに従事するWebサービスとクライアントの両方に関係する情報だけを含む。

全8つのMEPsは[WSDL 2.0 Adjuncts]で定義されている。 これらのMEPsは、ほとんどの一般的なユースケースをカバーするはずだが、オペレーションで使われ得るMEPsの全ての一覧であることを意味するわけではない。 利害関係者による特定の適用ニーズのために、他のMEPsも定義できる。 （2.4.4.3 Understanding Message Exchange Patterns (MEPs)参照。）

WSDL 2.0で定義された8つのMEPsにとって、それらのうちの幾つかは、他のもののフォルト・メッセージの生成方法に基づくバリエーションである。 例えば、In-Onlyパターン("http://www.w3.org/ns/wsdl/in-only")は、他の何らかのノードからの厳密に単一のメッセージ受信で構成されている。フォルト・メッセージはまったく生成されない。 In-Onlyパターンのヴァリエーションとして、堅牢In-Onlyパターン("http://www.w3.org/ns/wsdl/robust-in-only")もまた、サービスから厳密に単一のメッセージ受信によって構成されるが、この場合は、メッセージによってフォルトが起動され得て、メッセージ送信元に送達されなければならない。 このノードへのパスが存在しなければ、そのフォルトは破棄される。8つのWSDL 2.0 MEPsによって使われる一般的なフォルト生成モデルについての詳細は、[WSDL 2.0 Adjuncts]参照。

MEPの最初のメッセージの初期化方法に依存して、8つのMEPsは二つのグループに分けられる： インバウンドMEPsは、サービスはその交換の最初のメッセージの受信から始める。アウトバウンドMEPsは、その交換の最初のメッセージの送信からはじめる。（このグルーピングは、WSDL 2.0仕様では提供されておらず、ここで提示したのは、この入門で簡単に参照するためだけである。）

アウトバウンドMEPsに関する頻出質問は、サービスがどのようにしうてメッセージの送信先を知るかである。 アウトバウンドMEPsを用いるサービスは、定型的には、マッピングとルーティング・ファシリティに依存した大規模統合システムの一部である。 そのようなシステムでは、アウトバウンドMEPsは、サービスの機能を抽象的に指定し、潜在的顧客の要求を取り込むために有意義だ。エンドポイント・アドレス情報は、仮想の統合基盤によってデプロイや実行時に提供され得るからである。 例え