- - PR -
「7つの原則は変革をもたらすか?」の感想
投稿者 | 投稿内容 | ||||||||
---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-05-14 11:47
つまり、オブジェクト指向でいうインターフェイスの考え方はそのままに、それに柔軟な変更可能性を追加したものがサービス指向の定義である、ということでしょうか? であると仮定すると、私は必ずしも同意しません。インターフェイスが堅いことがオブジェクト指向の長所であり短所であるということには同意します。ですが、Webサービスのインターフェイスというのはオブジェクト指向のインターフェイスよりも粒度がはるかに粗いものです。私はお役所の申請書に近いようなイメージを考えています。とにかく一度にこちらから出すことができるすべてのインプットを与え、後は「不備がありませんように・・・」と祈るわけです。たいてい不備があるので、突き返されて修正する羽目になります(あ、これにも他意はありません>お役所様)。お祈りがお役所の神様に通じると、願いが聞き届けられてなんらかのアウトプットが出てくるわけです。 できるだけ入力を避けるために、サービスベンダーと顧客はあらかじめサービス提供契約の中で一定のプリファレンスを渡しあいます。お役所は無理でしょうが、航空券の場合は、請求先、請求方法、値引き率などなどが契約に盛り込まれるでしょう。その結果、顧客会社の従業員は出張時にいつどこからどこまで飛びたいのかだけを指定すれば、航空券が発券されることになります。これは窓口で発券申請を行うのと同じであることに注意してください。こちらの要求(禁煙、通路側、エマージェンシーシート不可など)はすべてまとめて最初に伝えてしまいます。 さて、このときWebサービスのインターフェイスが変更され、予約ごとに入金確認が行われない限り、発券ができないことになったらどうしましょう?そんな面倒なことはやっていられないので、顧客会社は航空会社を乗り換えるでしょう。これはインターフェイスのSyntaxは変わらないが、Semanticsが変わってしまった例です。 では、航空会社のキャンペーンで、搭乗時にウェルカムドリンクサービスが提供されたらどうでしょう。Webサービスのインターフェイスが変更され、ビールかオレンジジュースを選択するブール値を予約メッセージに含められるようになるでしょう。これはSyntaxが変わった例です。この例については、私は反対していません。XML Schemaの範囲で実現できるでしょう。 ■第3の原則:「Webサービスのインターフェイスにおけるデータ構造は変更できるが、慎重に行わなくてはならない」 mahiroさんが挙げられているインターフェイス変更の例は後者のものと考えます。それなら変更がまったく不可能ではないでしょう。ただし、慎重に行わなければならないのは言うまでもありません。
プログラミング言語において、という話ですか?それならスレ違い だと思いますが、一言で言えば反対です。Javaのinterfaceはimmutableであるべきです。そうでなかったら、JDBCは成り立たなかったでしょう。 最後の点はちょっと意味を把握できませんでした。ズレていたらすみません。 | ||||||||
|
投稿日時: 2002-05-14 11:54
松さん、その他の方、興味深く読ませてもらいました。
厳格なインターフェイス定義に基づくWebサービスの定義については同意します。これとサービスレベルや非機能的要求、インターフェイスの「ゆらぎ」への対応は分けて考える必要があるんでしょう。また、そういったことが現実的なサービスの手続きに必要かどうかもまた別問題です。これらの問題をごちゃにして議論するのは、意味があることではありません。 たとえば、Webサービスのインターフェイスの引数の数、型、順序の違いを吸収するしくみを考えるとしても複数の技術的選択肢があり、かならずしも厳密なインターフェイス定義を崩す必要はありません。まず、第1に、考え方をRPCから切り離すべきです。Webサービスはメッセージベースが基本ですから、引数は通常XML schemaで定義されます。それらの順序性の自由度、型やelementの拡張性もXML schemaに従います(literal/documentを前提としています)。ですから、インターフェイス、厳密にはPortTypeの仕様を厳密に定義しても実現可能です。受信側は疎結合性を重視していれば拡張部分を処理するコードを動作させるのは、動的ではないにしても、適切な事前設定の下でも可能となるでしょう。ただし、こういったことが実装のサービスで必要とされるかどうかはまた別問題です。 特定のアプリケーションドメインでportTypeの仕様を統一しておき、そのうちの1つを動的に利用するシナリオはありうるでしょう。たとえば、現在の住宅ローン金利を取得するなど。しかし、ここではportTypeの定義を個別に変更する自由度はありません。また別のシナリオ、たとえば、SCMやB2Bのようなサービスレベル合意を必要とする業務トランザクションでは適用は困難でしょう。むしろ、こういった場合は、トランザクション参加者がportTypeの構文定義以上にそれぞれの操作の責任範囲、データモデルの意味の統一などを明確に決める必要があり、連携の自由度は減るはずです。ただ、だからといってWebサービスの実装の疎結合性を犠牲にすることは意味しません。 現在のオブジェクト技術はある意味では拡張性に乏しいといえます。少なくともWebサービスのインターフェイス定義に与えられるメッセージの柔軟性を扱う上でですが。したがって、オブジェクトで実装されたWebサービス、現在の大半の実装はそうですが、オブジェクト技術が持つ実装上の制約を受けているといえるでしょう。メッセージ定義拡張などはいずれかの方法で、polymorphismに対応づけるなどしなければなりませんから。あるいは、フレームワークのランタイム機能にコンテキストなどを持たせ、動的にコンテキストを作成しオブジェクトをその環境下で動作させるなどをしなければなりません。それらをパイプラインなどのアーキテクチャパターンで実装したとしても、特定のプログラミングモデルに束縛され隠蔽された複雑なフレームワークとなるでしょう。これはSOAPのSimpleの理念に反する気がします。これはある意味でWebサービスの実装にオブジェクト技術が最適ではないと言える証拠です。トランザクションなどがなれけばXSLTだけで片付くはずです。まあ、だから、Webサービスはプラットフォーム非依存であるわけです。ただ、世の中そういう方向に動いているのは事実です。 | ||||||||
|
投稿日時: 2002-05-14 11:59
たとえば、あるインターフェースのメソッドAと、別のインターフェースのメソッドBの意味が同じであることを判定することは可能なんでしょうか? [ メッセージ編集済み 編集者: autumn 編集日時 2002-05-14 12:01 ] | ||||||||
|
投稿日時: 2002-05-14 12:55
サービス合意の文書です。構文上の一致は意味の合意の副作用に過ぎません(たとえば、URIのマッチングなど)。
しかし、また別の問題として、Webサービスには構文上一致していても意味が異なってしまう実装上の問題があります。たとえば、日付データを取り出すインターフェイスがあった場合、その精度が実装上異なる場合。ミリ秒までなのか、ナノ秒までの精度を保証するかで、その意味すら変わる場合です。 | ||||||||
|
投稿日時: 2002-05-14 13:39
サービス合意の文章とは何でしょうか? それは構文ではなく意味を記述した文書でなければなりませんよね? 具体的に、どんな言語で書かれるものでしょうか? | ||||||||
|
投稿日時: 2002-05-14 14:01
たとえば、B2BトランザクションではTrading Partner Agreement Markup Language (tpaML)を指します。
http://www-106.ibm.com/developerworks/library/tpaml.html この場合はXMLで書かれます。ただ、XMLで書かれるかどうかは重要ではありません。別の構文であって、例えば、RDF、DTD...何でもいいと思います。現在は、業界あるいは特定ソリューションでmarkup languageをXML構文上で作るのが流行しているだけです。 | ||||||||
|
投稿日時: 2002-05-14 14:18
同じように思っていた人が他にもいて安心しました。
とりあえず一つだけコメントします。 ebXMLのCPP/CPAもサービス合意定義の一つです。 これらが現状すぐ使えるかというと疑問ですが、将来このような方向性はあります。 Semantic WebなどOntologyのWebサービスへの適用というのも考えられています。 以下にいくつかそれらしいのがあるかと思います。 http://www.cse.lehigh.edu/~heflin/courses/sw-fall01/ | ||||||||
|
投稿日時: 2002-05-14 14:42
ということは、やはりサービスの利用については(構文がなんであれ)サービスベンダーと利用者とが合意をしなければならず、合意した内容は(もう一度合意しなおすまで)変えられない=インターフェイスは変えられないってことになりますよね? ここで言われている「サービス合意定義」と呼ばれるものは、すでに現実世界でも「接続仕様書」という形で利用されているわけで、それ自体が「将来の」というものではないと思うのですが。 |