連載

スキルアップのための分散オブジェクト入門

第6回　現実モデルはWebサービスとの共存

Webサービスと分散オブジェクト技術が 共存する分散環境

　ここでは少し難しい話をしなければならないのですが、その前にこれからの分散システムのイメージを絵にしてみましょう（図4）。

図4　これからの分散環境SCMの役割

■自律システムと疎結合が鍵

　 図4では、在庫管理システムや決済システムなどの各サブシステムが独立した自律システムとして設計されており、それらがWebサービスを通じて結合されています。ここでいう自律システムとは、次のような特性を備えたシステムです。

• 明確に定義されたインターフェイスのみを通して外界と相互作用する
  
• 外界とは疎結合で相互作用する

　各サブシステムをこのような自律システムとして設計することが、将来にわたって陳腐化しない分散システムを構築していくための鍵です。特性の1つ目、「明確に定義されたインターフェイス」は、この連載で繰り返し強調してきた点です。2つ目の「疎結合」性には、システム要求によって例えば次のようなさまざまな側面が考えられます。

• 互いに相手のプラットフォームや内部実装を意識しない
  
• ほかのサブシステムがダウンしていても非同期にメッセージをキューイングすることで、処理を継続できる
  
• 外部からの干渉を受けずに、自システム内のリソースを自分の判断で制御する

　単一の技術でこうした多様な要求のすべてを簡単にはカバーできないのはいうまでもなく、要求に応じて、分散オブジェクト技術をはじめとする既存技術とWebサービスを使い分けていくことが求められます。上の3つは、疎結合性のさまざまな側面の一部にすぎませんが、以下ではこれらについてもう少し詳しく見ていくことにします。

■プラットフォームと内部実装からの独立性

　 プラットフォームと内部実装からの独立性という点では、多くのケースでWebサービスが最適です。しかし、Webサービスが常に万能であるというアプローチではなく、要求実現のために最適な技術を冷静に選択することが必要です。例えば、性能を重視する場合にはIIOPを使用するという選択も十分にあり得ます。

■非同期メッセージング

　システムをより緩やかに結合するためには、パブリッシュ・サブスクライブや永続的なメッセージ・キューイングといった機能が必要になります。これらに関しては、Webサービスの標準化がまだ追いついていないため、現時点ではJMSやメッセージング・ミドルウェアといった従来の技術を使用するか、SOAP over JMSのようにWebサービスと従来技術を組み合わせて使用することになります。SOAP over JMSの場合、SOAPエンベロープのJMSへのマッピング方式やJMS自身の通信プロトコルが標準化されていませんが、ゲートウェイを経由して異なる製品同士をブリッジしたり、SOAP over HTTPに変換することが可能です。

■ロング・トランザクション

　3つ目のリソースの管理も疎結合実現のための重要な要素です。疎結合システムでは、自律システム内のリソース制御を、信頼性に乏しい外部の第三者に委ねてしまうようなことがないようにします。例えば、インターネットなどの外部からの要求によってデータベースが長時間ロックされてしまわないようにします。このため、自律システムにまたがってデータの一貫性が要求される場合には、ACID*2 トランザクションではなく、ロング・トランザクションを使用します。この場合、短時間であればデータの一貫性が厳密に保たれなくてもよいように設計する必要があります。Webサービスにおけるロング・トランザクションの分野では、OASISによるBTP（Business Transaction Protocol）の標準化や、マイクロソフトとIBMによるWS-Transactionの提案がなされています。

*2 ACID：古典的なトランザクションの特徴を表す4つの特性。原子性（Atomicity）、一貫性（Consistency）、隔離性（Isolation）、耐久性（Durability）。

■自律システムの内部実装

　ここまでは自律システム間の相互作用について議論してきましたが、最後に自律システム自身の内部実装を見てみましょう。自律システム間の相互作用は疎結合でしたが、自律システム内部の機能単位の相互作用は密結合でも構いません。逆に、性能を向上させたり、機能単位間でのデータの厳密な一貫性を保証するために、密結合が必要になる場合が多いでしょう。

　このような自律システム内部の実装には従来と同様に、分散オブジェクト技術、TPモニタ、データベース管理システム、あるいはERPなどのパッケージ・ソフトを引き続き利用することになるでしょう。ただし、あくまでも外部に対しては疎結合インターフェイスでサービスを公開する必要があります。

◆

　本連載では、分散オブジェクト技術の仕組みと、CORBA、JavaRMI、EJB、COM+、HORB、そしてWebサービスのそれぞれの技術的な特徴を解説してきました。連載を通じて繰り返し強調してきたのは次の2点です。

• いずれの技術を使う場合でも、アプリケーションのインターフェイス設計が重要である。
  
• Webサービスも含めて、各技術にはそれぞれ得手と不得手があるので、それぞれの技術の特徴を踏まえて適材適所の選択を行う。

　技術トレンドが次々と移り変わる中で、常に追い立てられるような不安感に駆られながら仕事をしている技術者が多くなっています。しかし、技術の本質やアプリケーション設計の本質は大きく変わるものではありません。また、これまでどんなにベンダやメディアが流行を作り上げたとしても、1つの技術が万能だったということはありませんでした。最終的には、本質を見極めて技術を使い分けていく基礎体力が技術者１人ひとりに求められています。本連載では、分散オブジェクト技術やWebサービスのさわりしかご紹介できませんでしたが、これをきっかけにこの分野での基礎体力を身に付けていっていただければ幸いです。

2/2

第6回 現実モデルはWebサービスとの共存
	Page1 Webサービスと分散オブジェクト技術のかかわり
	Page2 Webサービスと分散オブジェクト技術が共存する分散環境

INDEX
スキルアップのための分散オブジェクト入門
	第1回　分散オブジェクト技術が必要なわけ（2002/3/19)
	第2回　分散オブジェクトのしくみを理解する（2002/4/4）
	第3回　開発手順からCORBAを理解する（2002/4/25）
	第4回　開発手順から分かるEJBとJavaRMI（2002/6/25）
	第5回　分散オブジェクト技術としてのHORBとCOM+（2002/8/21）
	第6回　現実モデルはWebサービスとの共存（2002/10/4）

筆者プロフィール

小野沢 博文（おのざわ ひろふみ） 現在、日本アイオナテクノロジーズ株式会社にて分散オブジェクト・システムの技術コンサルタントを務める。 1991年まで富士通株式会社にてプラズマ実験データ処理システムの開発やシステム運用に携わった後、1996年以前は日本DECにてCORBA準拠のObjectBrokerおよびDCEの開発を担当。また、MIA、NMF SPIRITなどの標準化活動にも参加する。 1997年1月から1999年8月までは、TCSIにて分散オブジェクト技術を適用したテレコム向けの大規模ネットワーク管理システムの開発に携わる。 [著書一覧] 『CORBA完全解説 基礎編』（ソフト・リサーチ・センター）、『CORBA完全解説 応用編』（ソフト・リサーチ・センター）、『分散オブジェクト指向技術CORBA』（ソフト・リサーチ・センター）、『イントラネットのためのオブジェクト指向データベース技術』（共著、ソフト・リサーチ・センター）、『分散コンピューティング環境 DCE』 （監著、共立出版）、『トランザクション処理システム入門』（共訳、日経BP）

Java Solution全記事一覧

＠ITメールマガジン　新着情報やスタッフのコラムがメールで届きます（無料）