Remote Procedure Invocation †
一言要約 †
Remote Procedure Invocationは、アプリケーションを統合するためにカプセル化して情報のやりとりをする。そのため、インターフェース意識しておけば内部で閉じたデータ構造の変更に強くなる。
要約 †
- 企業では、異なる言語、プラットフォームで独立して構築された複数のアプリケーションを持っている。
複数のアプリケーションが一緒に動作し、情報交換できるようにどう統合していばいいか？
- File Transfer や、Shared Database は、アプリケーションのデータの共有を可能にしてくれる
アプリケーションの統合の重要な部分である。しかし、データを共有するだけでは、不十分な場合がある。
データの交換には、異なるアプリケーションを横断するためのアクションがよく必要とされる。
たとえば、住所の変更は、データでのシンプルな変更かもしれない、もしくは、
異なるなる法域での異なるルールを考慮するための登録かつ法的な処理の引き金になっているかもしれない。
- 他のアプリケーションがアプリケーションの内部構造についてあまりにも多くのことを知っている必要がある中で、１つのアプリケーションが、直接的にそのような処理を起動している。この問題は、アプリケーション設計における昔ながらのジレンマに似ている。
- アプリケーション設計で強力な構造のメカニズムの１つは、カプセル化である。
モジュールがファンクションがインターフェースを呼び出すことことで、それらのデータを隠蔽する。
- このように、データが変わった時にそれらが機能しなければない様々なアクションを
実行できるようにするためのデータの変更を防ぐことができる。
- Shared Databaseは、大きなカプセル化されていないデータを構造を提供する。
そしてこれを変更するのは難しい。
- File Transferは、ファイルの処理として変更のために動作するようにしているので処理は遅れてしまう。
- Shared Databaseは、カプセル化していないデータを持っており、また、
統合したアプリケーションの一部として維持することを難しくしている。
- いくつかのアプリケーション多くの変更は、データベースの変更を引き起こす。データベースの変更は、すべてのアプリケーションにかなりの連鎖反応を起こす。実際のところ、Shared Database を使う組織は、データベースを変更することに対してとても気乗りしない。
- このことは、アプリケーション開発の作業がビジネスのニーズの変化に反応しづらくなっていくことを意味している。
- 何が必要とされているかというと、他のアプリケーションでファンクションを起動するためのアプリケーションのメカニズムである。
- そのメカニズムは次の通りである。
- 共有することが必要とされていてるデータを受け渡すこと
- 受け手のアプリケーションにデータの処理方法を教えるファンクションを起動すること
- データをカプセル化してある大規模なオブジェクトもしくはコンポーネントとして各アプリケーションを開発する。
- 他のアプリケーションが、動作しているアプリケーションと一緒に反応するインターフェースを提供する。
- Remote Procedure Invocation は、統合アプリケーションにカプセル化の原理を適用している。もし１つのアプリケーションが、他のアプリケーションがもっているいくつかの情報を必要とするなら、直接、アプリケーションに依頼するのである。
- 他のアプリケーションを呼び出して対応することで、各アプリケーションが自身のデータの完全性を維持することを可能にしている。さらに、各アプリケーションは、他のアプリケーション毎に影響を与えることなく、
内部データのフォーマットを変更することができる。
- CORBA，COM, .NET Remoting, Java RMI のような多くのテクノロジーは、Remote Procedure Invocationを実装している。(Remote Procedure Call もしくは、RPCともよばれる）
- 最近のお気に入りは、SOAP,XMLのような標準を使っているWebサービスである。Webサービスの特に価値のある特徴は、HTTPで簡単に動作することである。
- 実際にはデータをラップすることで、意味の不一致(semantic dissonance)を簡単に扱えるようになるメソッドがある。
- アプリケーションは、複数のインターフェースを同じデータのために提供することができ、いくつかのクライアントが、１つの形式と他の異なる形式をみなせる。
- 更新でさえ、複数のインターフェースを使うことができる。これは、関連している見方によって達成できることよりもより多くの見方に対応するための能力を提供している。(?)
- しかし、統合する人たちにとって、変換コンポーネントを追加することはぎこちないことだ。それで各アプリケーションは、その近辺のインターフェースを交渉しなければならない。
- ソフトウェア開発者は、プロシージャコールをかつて使っていたためRemote Procedure Invocationは、すでに使ったことの人たちとうまく合う。実際には、これはメリットというよりもデメリットである。
- 大きな違いは、パフォーマンスとリモートとローカルプロシージャコールの間の信頼性である。
- もし開発者ががこれらをわかっていなかったら、そのときは、Remote Procedure Invocationが遅くて、信頼性のないシステムへと導くことになる。(See Waldo, EAA)
- カプセル化は、大きな共有されたデータ構造を除外することによって、アプリケーションの結合を減らしてくれるのに役立つのだが、アプリケーションがほとんど一緒に密結合となっている。
- リモートの呼び出しは、各システムが、異なるシステムとを密な強まりにすることを後押ししてしまい、
特に、優先順位付け(特定の順番であることを行うこと)では、独立してシステムを変更していことを難しくしていく。
- この手の問題はよく挙がる話で、なぜかというと単体のアプリケーションの中では重要ではない問題でアプリケーションを統合するときに問題となってしまうからである。
- 人々は、よく劇的な変更が約束されたルールに気づかないで、彼らが単体のアプリケーションを設計する方法で統合について設計してしまう。
- 上記のことを踏まえると、より疎結合にアプリケーションを統合するためには、非同期な方式であるMessagingを使うことで、小さなデータ量の交換を流暢に行うことができるようになる。
担当者のコメント †
- ほぼ全訳してしまいました。
- Messagingが1番いいよというための布石のように思った。
- 訳をひと通り見直して修正しました(8/19)
みんなの突っ込み †
