- - PR -
「7つの原則は変革をもたらすか？」の感想
| 投稿者 | 投稿内容 | ||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
投稿日時: 2002-05-12 18:18
私が思うに、Bloomberg氏が述べているのは、現在のSOAP/WSDL/UDDI(または.NET)
によるWebサービスではなくて、未来の(本来の)動的接続を狙ったWebサービスでは ないでしょうか？ 吉松さんが述べているのは、今現在のSOAP/WSDL/UDDI(または.NET)についてです。 かみ合ってないのはそれが原因ではないでしょうか？ 私自身は、late binding, lazy binding, dynamic bindingを実現する未来のWebサービス に興味があります。 以下は本文に対するコメントです。 第１の原則 インタフェース定義とSemantic WebのようなOntologyを用いて動的バインディングを することは将来はある程度可能になるのではないでしょうか？ もちろん今は無理ですけど。 第２の原則 ここでの要件定義はあきらかに「統合化」の要件定義です。各コンポーネントが Webサービスとして開発されていれば、システムレベルの統合化の要件定義は ほぼできてると言ってよいのではないでしょうか？ 第６の原則 ここで皮肉といっているのは、プラットフォームの問題がなくなるのにプラットフォーム の戦いが始まっているのは皮肉だと言っているだけで、実行プラットフォームの問題が なくなるとは言ってないでしょう。 | ||||||||||||||||||||
|
投稿日時: 2002-05-12 21:34
吉松です。まずは、ご感想をいただきありがとうございます。読んでいただいている方がいらっしゃると思うと励みになります。
Bloomberg氏は、ツールについてはその未熟さを指摘していますが、解説の内容は現状のWSDLを肯定している（少なくともWSDLそのものの存在価値や意義を問題にしていない）ように受け取りました。そして、現状のSOAP/WSDLでも、技術的には動的接続は可能です。 私自身は記事の中で必ずしも現状のSOAP/WSDLを肯定はしていません。したがって、私「が述べているのは、今現在のSOAP/WSDL/UDDI(または.NET)についてで」はありません（「」内yamさんの投稿から引用）。また、現状の.NET FrameworkはすでにWebサービスの開発ツールとしては時代遅れの代物であると考えています。したがって、私は本記事で.NETの話をしているつもりは一切ありません。その上で、インターフェイスが次々に変わっていくようなソフトウェアなど使い物にならない、というのが私の主張でした。それは「粒度の荒いDLL地獄」を招くことになりませんか？
私も興味がまったくないわけではありません。ですが、実業務への適用という観点からは、まだまだ実現は難しいと思います。人間である自分の部下にすら権限委譲ができないのに、壊れたり止まったり病気に感染したりする機械に権限が委譲できるでしょうか？Bloomberg氏は実業務への適用を楽観視しているようですが（UDDIの議論からそれがわかると思います）、私はWebサービスの適用ができる業務はまだまだかなり限定されていると考えています。
私はSemantic Webというものをきちんと理解していないので、将来可能になるかどうかもよくわかりません。そして、今よりも一段進んだ動的バインディングは、Semantic Webというものとは別の次元で近い将来達成されるだろうと思います。たとえばWS-Referral、それにWSFLやXLANGなどが、それにかかわるプロプライエタリな仕様として見えていると考えます。 これらの仕様は、Webサービスそのもののインターフェイスを変えるというよりも、Webサービスのフローを動的に変化させることを可能にするものです。このとき重要なのは、（現在の用語を使えば）WSDLのportTypeをbindingやserviceと独立して記述することで、「同じサービス」の実装を選択できるようにすることです。第1の原則での私の主張は、portTypeを変えてはいけないというものです。
Bloomberg氏のいう「トップダウンのアプローチ」と「ボトムアップのアプローチ」との違いがどこにあるのかが私にはわかりませんでした。コンポーネントがWebサービスとしてできていたものの、その粒度が統合化の際に問題になるということはないのでしょうか？「統合」したい各種サブシステムをWebサービス化するときに、統合のことを考えずに「コンポーネント化」することができるものでしょうか？これらは「トップダウン」とか「ボトムアップ」という一言で片付けられる問題ではないと考えます。
「サービス指向の開発がプラットフォームの問題全体を完全に無意味なものにしてくれるであろう」というBloomberg氏の主張そのものが（故意に？）あいまいになっているのが原因だと思います。ここでいう「プラットフォームの問題全体」とは何のことなのでしょうか？MicrosoftもJava陣営も自社の開発プラットフォームを開発者に採用してもらうべく旗を振り回しています。ですが、これは「問題」でしょうか？相互運用性がプラットフォーム選択のファクターにならないのであれば、この戦いは歓迎されるのではないですか？開発者はベンダーの切磋琢磨の恩恵を、サービス連携のリスクなしに受けられるのですから。これは皮肉でもなんでもなく、業界が正常化しつつある証明と私は考えています。 | ||||||||||||||||||||
|
投稿日時: 2002-05-13 01:30
丁寧な回答をいただき恐縮です。
Bloomberg氏の原則を「明確」に理解はしていないかもしれませんが、大体納得 してます。吉松さんの記事での吉松さんの意見にも大方納得していて両方の意見 があると思います。どちらも正しいと思ったのですが、Bollomberg氏の原則を 批判するのは違うなと感じたので感想を述べさせていただきました。 私はBloomberg氏と吉松さんの意見の違いは、未来のWebサービスと現在の Webサービスの差かなと思ったのですが、そうではないということですよね？ 「インターフェイスが次々に変わっていくようなソフトウェアなど使い物にならない」 というのが未来に対しても言えるというのが吉松さんの御意見として以下再び 感想書きます。 「インターフェイスが次々に変わっていくようなソフトウェア」これこそが 未来のWebサービスの一つの形ではないでしょうか。インタフェースが次々変わる というのは多少のゆらぎを許すということだと考えています。 一つのインタフェースに対して以下のようなゆらぎが考えられます(他にもあるけど)。 ・引数の数 ・引数の順序 ・引数の型 ・引数の名前 ・引数の意味(これはWSDLにはありませんが) このゆらぎを吸収するのはサーバ側かもしれませんし、新しいインタフェース定義 を読みとったクライアント側かもしれません。 一つの例として、複数の同じようなWebサービスがある状況を考えます。 これらのWebサービスはインタフェースに多少の差がありますが、クライアントは あらかじめOntologyを使ってその差を吸収する実装によりアクセスできるとします。 ここで、あるWebサービスが他のWebサービスに追従してインタフェースの一部を変更 したとします。このとき、クライアントは新しいインタフェース定義を読み取り、 Ontologyを用いて新しいインタフェースでアクセスすることは可能ではないかと。 まあ今は無理ですけど、将来はそのような状況もありうるかなと。 プログラミング言語をがりがり書くのではなく、いくつかのWebサービスをGUIで結び 付け、指示にしたがって意味付けをちょっと与えると何かシステムができてしまう ような世界がいつか来るはずと妄想してます。 | ||||||||||||||||||||
|
投稿日時: 2002-05-13 13:42
ざっと見ましたが私は吉松さんの意見に賛成です。
Bloomberg氏の記事を読んだときは、「酷い内容だなぁ」と思いましたが馬鹿馬鹿しいので放置していました。吉松さんが、きちんと意見したのは良いことだと思います。 | ||||||||||||||||||||
|
投稿日時: 2002-05-13 16:20
はじめまして。
吉松様の記事は、大変興味深いものでしたが、原文ではなく、日本語訳に対して反論をされている部分が残念に思いました。原文を読むと、日本語訳に数多くの誤訳があり、誤訳により、Jason Bloomberg氏の意図が間違って伝えられている部分が多いように思えました。 第1の原則の部分をとってみても、原文では、「サービスの動的仕様」などという言葉は使われておりませんし、「「Webサービス」を利用するソフトウェアは、WSDLファイルだけで機能仕様を知ることができる』」というような訳もおかしいように思います。Jason Bloomberg氏の意見にすべて賛成というわけではないのですが、あの日本語訳がJason Bloomberg氏の意見であるとみなされているのではと危惧しております。 よろしければ、今一度、原文の方に対して、どの部分がJason Bloomberg氏の意見と対立するかをコメントしていただければ幸いです。 | ||||||||||||||||||||
|
投稿日時: 2002-05-13 22:43
うーん、批判というか、彼のいう原則を守ってもソフト開発に変革はもたらさないのではないか？という意見です。Webサービスというものはずいぶん誤解されているのではないか、ということを常日頃から考えておりまして、私が考える「誤解」の代表選手のような原則が並んでいたものですから、いい機会なので私の意見も述べさせていただいたという次第です。
まず第一に、これを読んでもBloomberg氏が言っていることが「未来」だとは私にはどうしても思えないです。むしろBloomberg氏の主張は過去にすでに議論されたものだと思います。ただし、「未来のWebサービス」についての定義がおそらく一致していないので、「そうではありません」と断言できないです。
私はやはり反対します。その実現可能性もさることながら、Webサービスってそういうものの実現が目的ではないと思うのです。
まずお断りしなければならないのですが、Ontologyって何なのかが私にはわかっていません。その上で。 インターフェイスには2つの側面があります。SyntaxとSemanticsです。これはオブジェクト指向プログラミングの考え方ですが、Webサービスにも当てはまると考えます。Syntaxは現状ではXML Schemaで与えられます。Semanticsはドキュメンテーションで与えられます。この考え方に基づくと「似たようなインターフェイス」というものはありません。同じか違うか2つに1つです。 出張手続きを考えます。航空会社はどこも似たり寄ったり（あくまで例です。他意はありませんm(._.)m）ですが、Webサービスのインターフェイスが似ているからといって、機械が急にいつも使っている航空会社を変えていいのでしょうか？Webサービスのインターフェイスが似ているということが、ビジネスパートナーの選択のファクターにはなりえないと思います。 社内システムの統合ということならどうでしょう。せっかく（プログラム的には）簡単な手続きで統合できるのに「ゆらがせる」理由があるでしょうか？
WebサービスをGUIで結ぶと新しいシステムが完成するという夢には同意します。ですが、そのとき重要なのはやはり「堅いインターフェイスの定義」だと思います。インターフェイス（SyntaxとSemantics）は堅く、実装は柔軟に行うことが、よりよいサービスの選択のキーとなるはずです。 さらに言えば、GUIであるサービスと結ぶか結ばないかを選択するときには、実はWebサービスのインターフェイスなど問題にならないとも思います。ビジネスの相手を選択するときに考えなければならないのはプログラムのことだけではないからです。Webサービスによって、システムのつなぎやすさのようなことが選択のファクターでなくなり、（たとえば航空会社のような）顧客を獲得したいサービスベンダーは、システム的な何かではなく提供できるサービスの内容で勝負しなければならなくなる、それが将来のWebサービスの役割なのではないかな、と漠然と考えています。 | ||||||||||||||||||||
|
投稿日時: 2002-05-13 23:07
こんにちは。コメントいただきありがとうございます。
読みました。確かにかなり意訳があると思います。ですが、意味的に反対であるとか、正確な意図を伝えていない訳であるとは思いませんでした。次の部分がご指摘の原文だと思います。
descriptionを記述と仕様という2通りに訳していますが、この文脈で意味がずれているとは思いませんでした。また最後の文ですが、たしかに「WSDLファイルだけで」という訳はどうかな？と思います。ですが、最後の「at runtime」という言葉に注目してください。結局Bloomberg氏はWSDLを実行時に取得することを「dynamic」であると捕らえており、クライアントはrutimeにdescriptionを取得するのだから、descriptionをdynamicに変化させてもいいのだ、という風に受け取れます。したがって、ご指摘の箇所については原文を読んでも私の考えは変わりません。 それ以前に上記の文章、意味わかります？ 「サービスは指定されたとおりの機能セット(?)を持つように構築するだけでは十分ではない。そうではなく、Webサービスは（図1に示すように）その機能の動的記述によって定義されなければならない。ここでいう動的記述は、現状ではWebサービスのWSDLファイルとして表現される。したがって、開発者はWSDLファイルのありかを示せばいいだけだし、Webサービスを起動しようとするソフトウェアは実行時に機能に関する記述を発見することができる。」 私にはまったく意味不明の文章です。 | ||||||||||||||||||||
|
投稿日時: 2002-05-14 10:47
お返事ありがとうございます。原文を読んだ上での、私の第一の原則への感想を述べさせていただきます。
Bloomberg氏の第一の原則は、インターフェース指向からサービス指向へ、ということを述べているのだと感じました。 Object指向による開発者にとって、インターフェースは神聖不可侵なものとして考えられていると思います。一度公開されたインターフェースを変更することは許されません。そのため、設計者は、細心の注意を払ってインターフェースを設計します。上手に設計されたインターフェースは、モジュールの強度が強く、モジュール間の結合が疎なシステムを構築することを可能にします。また、外部に影響を与えずに内部の老朽化した個所を修理したり、インターフェースの意味を変更しない限りにおいて、内部の実装を自由に変更することを可能にします。 しかし、これは同時に、従来のObject指向は、インターフェースの変更にもろいということを意味していると思います。インターフェースが変更されると、インターフェースを公開しているサーバだけでなく、それを使用するクライアントもシステムを構築し直す必要があります。インターフェースが変更されるのだから、それは当たり前だと考える向きもありますが、同じサービスを提供するのに、サーバ側だけでなく、クライアント側も変更しなければいけないのはおかしい、というのがサービス指向の考え方だと思います。 現実世界においてチケットの購入というサービスを考えたとき、システムが刷新されて、チケットの購入方式が変更されたからといって、それを利用する側は、係員に使い方を聞くなどして、柔軟に新しいシステムでチケットを購入できると思います。購入方式の変更（インターフェースの変更）は係員の対応（WSDL？）により利用者側に影響を与えないというのがサービス指向なのではないかと考えます。 私自身、Webサービスについて、勉強を始めたばかりで、上記のことがWebサービスで実現可能なことなのかどうかまではわからないのですが、Bloomberg氏の第一の原則は、そのようなことを述べているのだと感じました。 最後になりますが、吉松様は、インターフェースは絶対に変更されてはならない、と述べていらっしゃいますが、Javaなどの言語においては、一度公開したメソッド（インターフェース）が変更できないという現状があります。このようなインターフェースは、その意味を変えない限りにおいて変更可能であっても良いと思うのですが、いかがでしょうか？ | ||||||||||||||||||||
スキルアップ／キャリアアップ（JOB@IT）
Copyright © ITmedia, Inc. All Rights Reserved.
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。
著作権はアイティメディア株式会社またはその記事の筆者に属します。
当サイトに掲載されている記事や画像などの無断転載を禁止します。