Stanford InfoBusは クライアントに分散した異種の (heterogeneous) 情報資源やサービスへの 統一したアクセスができるようにするアーキテクチャである。 コレクションやサービスをInfoBusの上にのせるには、 InfoBusプロトコルの一つを利用するか、 そのサービス用のInfoBusプロクシ (Proxy) を利用する（図1）。
InfoBusプロクシはサービス自身または他のサービス提供者により運用される wrapperである。 このやり方が相互運用性を実現するための柔軟性を与えている。 例えば、WebサーチエンジンのAltavistaへのサービスを提供する場合、 誰かがInfoBusへのwrapperを稼働させれば良く、 DEC社自身がサービスをする必要はない。
もちろんサービス提供者自身が直接InfoBusプロクシを運用することもできる。 そうすれば、より良いサービスの機能を直に利用できるので、 サービスの質が保証されることとなる。 このように、 プロクシを利用してサービスを標準化しなくても良いことが InfoBusの接続性の良さとなっている。
InfoBusはクライアントやサービスの増加にともなって、 wrapperを提供するのが容易なように設計されている。 ちょうどハードウェア機器が線 (bus) に繋げられるように、 単にシステム自体に組み込むだけで、 クライアントやサービスは自由にやりとりできる。
クライアントは論文執筆・回覧の発行・製品開発の確認といった 複雑な仕事を行なうためにInfoBusの資源を利用する。 情報資源はオンライン目録・株価情報・国勢調査のデータ・新聞記事などの 情報の集積を含んでいる。 さらに、情報資源は情報に関する操作を行なうサービス --文書翻訳・文書要約・遠隔索引作業・課金サービス・著作権の認可などを 含んでいる。
実装のレベルでは、InfoBusの構造はCORBAやDCOMのような分散環境でのオブジェクト指向設計を支援する技術とうまく融合している。 我々の試験台となるInfoBusシステムのプロトタイプの開発では、 CORBA（特にXerox PARCのILUシステム）を利用した。 CORBAの利用により、 異なるプラットフォーム上に異なるプログラミング言語でプロクシを構築することが可能となった。 実際には様々なオブジェクトはPython・Java・C++を利用している。
InfoBusのプロクシとしてTelnetやZ39.50、HTTPなどのプロトコルでの サービスとやりとりできるものも可能で、 InfoBusクライアントはこのようなプロクシにアクセスしても その違いを意識せずにやりとりできる。 我々がこのようなプロクシを介してInfoBusでアクセスできるようにしたサービスには、 Dialogサービス、Webのサーチエンジン、自動文書要約サービス、書誌変換ツール、 OCRサービスなどがある。
