[openrtm-users 00498] 質問:サービスポートのIDLにおいて、複数のIDL間で、共通に利用する型を参照する方法

3 個の投稿 / 0 new
最終投稿
root
オフライン
Last seen: 5日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00498] 質問:サービスポートのIDLにおいて、複数のIDL間で、共通に利用する型を参照する方法

皆様
九州工業大学 小田と申します。

Open-RTM 0.4.2 C++、Ubuntu 7、omniORB 4.0.7にて開
発を行っています。
そこで質問なのですが、サービスポートのIDL定義において、複数の
IDL間で、共通に利用する型を参照する方法を知りたくメールしてお
ります。

例えば、デザインパターンでいうSubject-Observerパターン
において、Subjectの更新にともなって、複数のObserver
に更新の通知を行うような
コンポーネントSubjectObserverEngineを実装することを想定
します。(最後に具体的なrtc-templateコマンドを挙げています)
そこで、
監視の対象:Subject型、
Subjectの通知の対象:Observer型、
通知を行う主体:Notifier型
として宣言します。

このとき、Observer型とNotifier型は、メソッドの引数に
Subjectが必要なので、共にSubject型の宣言を必要とします
が、これを素直を行う方法が分からなくて困っています。

より詳細には、

未定義
root
オフライン
Last seen: 5日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00500] 質問:サービスポートのIDLにおいて、複数のIDL間で、共通に利用する型を参照する

小田様

産総研 安藤です

方法は3つ位あります。

一番簡単な方法は、以下のように一つのIDLに記述することです。
Observer と Notifier は Subject で相互に依存してますので、
それほど変なやり方じゃないと思います。

好みの問題になりますが、IDLはあまり分割しないのが一般的です。
OpenRTMに付属のIDLを見ていただければわかると思いますが、
ある機能を提供するインターフェースのセットをまとめてIDLで定義しています。
CORBAのその他のIDL定義も、それほど細かく分割されていません。

原理的には分割しても、ちゃんとコンパイルできなければならないのですが、
rtc-templateはファイル間の依存関係まで調べてコードを生成しているわけでは
ありませんので、複雑依存関係のあるIDLの場合、Makefileやコードなどに
いろいろ手直しが必要になります。

-------------------------Observer.idl---------------------------
interface Subject {
void foo();
};

interface Observer {
void listenUpdate(in Subject aSubject);
};

interface Notifier {
void notifyUpdate(in Subject aSubject);
};
-------------------------Observer.idl---------------------------

rtc-template -bcxx \
--module-name=SubjectObserverEngine --module-type='DataFlowComponent' \
--module-desc='Subject Observer Engine test' \
--module-version=1.0 --module-vendor='Kyushu Institute of Technology' \
--module-category=Consumer \
--module-comp-type=DataFlowComponent --module-act-type=SPORADIC \
--module-max-inst=1 \
--service=Notifier:notifier:Notifier \
--consumer=Observer:observer0:Observer \
--consumer=Observer:observer1:Observer \
--consumer=Observer:observer2:Observer \
--service-idl=Observer.idl

2番目のやり方は、面倒ですがMakefileを修正するやり方です。
以下の修正を施したMakefileでビルドできました。

root
オフライン
Last seen: 5日 11時間 前
登録日: 2009-06-23 14:31
[openrtm-users 00501] 質問:サービスポートのIDLにおいて、複数のIDL間で、共通に利用する型を参照する

産総研 安藤様
九工大 小田です。

早速の詳細なご回答ありがとうございます。

複数のIDLを一つのIDLに統合してしまうという最初の
方法が、一番シンプルですね。

rtc-templateのhelp
>> " --consumer-idl=[IDL filename]:
>> Specify IDL file of service consumer.
>> For simplicity, please define one interface in one IDL file,
>> although
>> this IDL file can include two or more interface definition,"
は、「お互いに依存関係がない間は」という条件つきということですね。

実は今まで、私は3番目の方法に近い方法で乗り切っていまし
たが、手動のpatchでは追いつかず、システマティックな
方法が必要だと考えてきました。

一方で私は、IDLを依存関係があるにせよ一番の方法のように
統合して扱うのも制約がきついと考えております。
#というのも、複数の組織から提出される複数のIDLを取り扱
う場合、インターフェースの数が増えることや内容に変更が多くな
されることが考えられ、
#これらに素早く対応するためには、適切な粒度で分割したIDL
を用意する必要があると考えています。

そこでいまは、自動的に複数のIDLを一つに統合するようなプ
リプロセッサ的な仕組みが必要かなと考えています。

丁寧なご回答、ありがとうございました。

On 2008/07/01, at 18:42, Ando Noriaki wrote:

> 小田様
>
> 産総研 安藤です
>
> 方法は3つ位あります。
>
> 一番簡単な方法は、以下のように一つのIDLに記述すること
> です。
> Observer と Notifier は Subject で相互に依存し
> てますので、
> それほど変なやり方じゃないと思います。
>
> 好みの問題になりますが、IDLはあまり分割しないのが一般
> 的です。
> OpenRTMに付属のIDLを見ていただければわかると思いますが、
> ある機能を提供するインターフェースのセットをまとめてIDL
> で定義しています。
> CORBAのその他のIDL定義も、それほど細かく分割されてい
> ません。
>
> 原理的には分割しても、ちゃんとコンパイルできなければならな
> いのですが、
> rtc-templateはファイル間の依存関係まで調べてコードを生成し
> ているわけでは
> ありませんので、複雑依存関係のあるIDLの場
> 合、Makefileやコードなどに
> いろいろ手直しが必要になります。
>
> -------------------------Observer.idl---------------------------
> interface Subject {
> void foo();
> };
>
> interface Observer {
> void listenUpdate(in Subject aSubject);
> };
>
> interface Notifier {
> void notifyUpdate(in Subject aSubject);
> };
> -------------------------Observer.idl---------------------------

コメントを投稿するにはログインまたはユーザー登録を行ってください

ダウンロード

最新バージョン

初めての方へ

Windows msi(インストーラ) パッケージ (サンプルの実行ができます。)

C++,Python,Java,
Toolsを含む
1.2.1-RELEASE

RTコンポーネントを開発するためには開発環境のインストールが必要です。詳細はダウンロードページ

統計

Webサイト統計
ユーザ数:1840
プロジェクト統計
RTコンポーネント297
RTミドルウエア28
ツール22
文書・仕様書1

Choreonoid

モーションエディタ/シミュレータ

OpenHRP3

動力学シミュレータ

OpenRTP

統合開発プラットフォーム

産総研RTC集

産総研が提供するRTC集

TORK

東京オープンソースロボティクス協会

DAQ-Middleware

ネットワーク分散環境でデータ収集用ソフトウェアを容易に構築するためのソフトウェア・フレームワーク