[openrtm-users 00829] Re: Port 関連の実装に関して

2009年 6月 10日 (水) 00:24:37 JST

清水様

安藤です

Port周りに関しては、後付けでいろいろと機能をつけたしていった
関係で、いろいろ汚くなっているのですが、doilの導入やその他
いろいろ考えるところがあって、そのまま放置しています。

先ほどのメールにも書きましたが、RTCの基本的な考え方は、
仕様に基づきコンポーネントを設計し、ほとんどのコードをジェネレータ
で生成することで、実装するのが面倒でバグが入りやすいが、
大半は同じコードになうような、通信部分や状態遷移部分に関して、
バグの少ないプログラムを書けるようにすることで、コアロジック部分の
実装に集中できるようにすることを主眼においています。

ですので、Portを単体で使用したりすることは特に想定していません。
また、PortBase自体はRTObjectやPortAdminには依存して
なかったように思いますので、コンストラクタで暗黙のインスタンス化を
行っている以外は、単なるCORBAオブジェクトの実装であるように
思います。

余談ですが、PortBase自体はコンストラクタで_this()を呼んでいるので、
デフォルトPOAでactivateされてしまいますが、PortBaseが継承している
RefCountServantBaseを独自のRefCountServantBaseの派生クラスとし、
_default_POA() だったか、そのような関数をオーバーライドして、
希望のPOAを返すようにすれば、_this()で暗黙にactivateされる対象POA
をRootPOAではない任意のPOAに挿げ替えることはできます。

で、以前話題に上がったような気がするのですが、
サービスポートのサーバントが、RTCがInactiveの時に応答するのは
おかしいという意見がありまして、そのために今回1.0ではポートの
サービスインターフェースをRTCがInactive時にに非アクティブ化、
RTCがActiveの時にアクティブ化するように変更いたしました。

ただし、サービスポートを使用している方には申し訳ないのですが、
サービスポート同士を接続後にRTCをInactive状態にし、非アクティブ化
されたサービスポートのサーバントに、再度active化後にコンシューマから
アクセスしようとすると、IORが変わってしまっているのでアクセスできない
というかなり致命的な問題が発覚しました。

activate/deactivateを繰り返してもIORが変わらないようにするには、POA
のポリシーをPERSISTENTかつUSER_IDにしなくてはいけなかったのですが、
RootPOAをそのまま使用していたのが問題でした。

そういうわけですので、Portのみならず、CORBAオブジェクトの
POA周りの問題はRELEASEに向けて少々手を入れざるを得ない
状況ですので、清水さんのご指摘を参考に変更したいと思います。

ちなみに、上記のRTCの状態に応じてポートのサーバントが
非アクティブ・アクティブになるという仕様はどう思いますか？
相手がアクティブでないと、サービスが利用できないというのは、
ある場面では適当かもしれませんが、別の場面ではうっとうしい
だけのような気もします。

これについても、何かご意見をいただければと思います。
＃清水さんだけでなく、ほかの皆様にも。。。


では、


> OpenRTM-aist開発者の皆様
>
> Port関連の実装に関して気づいた点です。
>
> PortのCORBAオブジェクトは
> PortBaseクラスでimplicit activationされていますが、
> 同じクラス内でdeactivationされていません。
> なぜか、PortAdminクラスでdeactivateされています。
> （PortAdminで管理されない場合はどうするのでしょうか）
>
> オブジェクト指向的には、クラス単位で完結していることが
> 望ましいので、PortBaseでactivationしたのであれば、
> そのクラスでdeactivateもすべきと考えるのですが、
> どうでしょうか。
> （同じことは他のCOBRAオブジェクトにも言えます）
>
> これに関連するのですが、PortAdminの仕事の範囲は、
> (activate済みの）Portオブジェクトを管理するだけでなく、
> Portオブジェクトのactivate/deactivateまで
> もカバーする、という設計でしょうか。
> （その場合でも、Portオブジェクトのactivate処理
> はないので、完備性の観点からは問題があると思いますが）
> 私としては、PortAdminクラスは、
> activate済みのPortオブジェクトを管理するだけに
> 絞った方がわかりやすいと感じます。
>
> 上述のPortオブジェクトのactivate/deactivate管理の
> 役割分担があいまいなために、RTObjectでのPortの操作も
> わかりにくいと感じました。
> 具体的には、Data PortをRTCに登録するときは、
> registerInPort/registerOutPortを呼ぶのに、
> この逆の操作はdeletePortとなっている点です。
> unregiterInPort/unregisterOutPortの方が
> わかりやすいのではないでしょうか。
>
> さらに、PortをRTCに登録する場合は
> Portオブジェクトはactivationされないのに、
> 登録解除の際は自動的にdeactivateされてしまうのは、
> ユーザからはわかりにくいし不便な場合もあるかと思います。
> （稀なケースとは思いますが、Portオブジェクトを
> 他のRTCに移譲する場合とか。）
> また、確か、RTC仕様上はPortオブジェクト単独で存在する
> ことも可能だったと思うので、RTCまたはPortAdminに
> 依存する現在のPort実装は少し問題があるのではと感じます。
>
> 以上、気づいた点です。
> ご検討頂ければ幸いです。
>
> 静岡大　清水
>
> --------------------
> Masayuki Shimizu
> Assistant Professor
> Dept. of Mechanical Engineering, Shizuoka Univ.
> 3-5-1, Johoku, Naka-ku, Hamamatsu 432-8561, JAPAN
> TEL/FAX: +81-53-478-1061
> Email: tmsimiz ＠ ipc.shizuoka.ac.jp
>
>


-- 
安藤慶昭＠独立行政法人産業技術総合研究所 研究員
                  知能システム研究部門 統合知能研究グループ
                  〒305-8568 茨城県つくば市梅園1-1-1 中央第2
                  TEL: 029-861-5981 FAX: 029-862-6631
                  n-ando ＠ aist.go.jp, n-ando ＠ ieee.org