=========================================================================== セッションE2:IPA未踏ソフトウェア創造事業成果発表 会場 :約120席 参加者:約50名 =========================================================================== ---------------------------------------------------------------------- IPA未踏ソフトウェア創造事業について。(高田広章(豊橋技科大)) IPA未踏ソフトウェア開発ポイント:  1.補助対象は個人。  2.審査、評価はIPAでなく選出されたプロジェクトマネージャが行う。  3.成果は開発者の権利になる。 実施方法: 公募から年6,7件の研究を選び、プロジェクトを進めている。 今回はその成果発表である。。 ----------------------------------------------------------------------- ====================================================================== 「情報家電に向けた、ソフトウェア部品の開発」 邑中雅樹(もなみソフトウェア) ====================================================================== (註)発表は開発成果物の説明でなく、なぜ作ったかに焦点を当てた発表で    ある。 組み込みの未来予想:  マスコミいわくハードウェアの高速化、記憶容量の大容量化がつづく。  ユビキタスや組み込み対象が多様化していく。 未来に必要なもの:  分散組み込みに向く「何か」 では「何か」とはなに? ⇒分散オブジェクト  ITRONの可能性:組み込みOS(API) の標準であるが、分散組み込み環境への  対応は不十分 ⇒それでは組み込みUNIXにしてみたらどうか?  組み込みUNIXの特徴:   ネットワークとの心和製がある。豊富なミドルウェア(CORBA,.NET,SOAP)   がある。    問題点: シリコン頼みハードウェアのコストパフォーマンスがずっと向上する ことを前提にしている ⇒それではシリコンはユビキタスを救うか? 今後、ハードウェアのコストパフォーマンスが高くなると予想する。 同時に組み込み製品によってはターゲット単価はひくくしなければな らない。 ⇒結果利用可能なパフォーマンスは低くなる IPブームの牽引者は?:  IPv6?IPv4?いや本当は別にIPではない。  HTTP/SMTP/POP(アプリケーション層)がユーザにFITしたからである。 IPv6ではAPIはどうするの?:ソケットプログラミングでは大変。 ⇒未来に必要なものは分散オブジェクトである。 HORB:世界初のJAVAnativeORB 独自プロトコルで高速。 HORBのアプローチ: オブジェクト間通信機構 HORBプログラムとソケットプログラム: ソケットで手間をとるものがHORBでは簡単に書けることができる では、本当にHORBはユビキタスを救うのか?:  現在のところJAVAで実装しているので重い。  小規模組み込み用途としては重い。  ⇒このままでは救わない。  そこで今回、低スペックでも高速に動作する分散オブジェクトコンピューテ  ィング用の部品をつくった 今後は:  軽量化(WAVAVMの削除、TCP/IPスタックの改良: 目標はTOPPERS/JSP+TCP+HORB<=40KB)  より強力なHORBのサポート まとめ:  低ハードウェアスペックでも動作する分散コンピューティング用の部品を作  った。 課題:  性能評価と実運用、改良  仕様・実装の最適化を行っている Q:組み込みはプラットフォームが多様でコンパイラ依存性やプロセッサ依存性  などがあるが? A:バイトオーダに対応しているくらい、公開していってみんなでコミュニティ  をつくっていこう ====================================================================== 「サービス統合メタミドルウェア」 倉橋誠○、徳永栄治、石川広男、森元靖庸(早稲田大学) (○:発表者) ====================================================================== 背景:  組み込みは生活のさまざまな場面に浸透している ホームコンピューティング問題:  それぞれに特徴のある環境でのソフトウェアの開発(プロトコルの増加)  ミドルウェアやフレームワークがあるがミドルウェア間に差異が残る。  ⇒すべてを統合するようなミドルウェアが必要になる。 サービス統合メタミドルウェアとは:  今までつながらなかった家電サービス同士を連携させることで新たなサービ  スを提供する。  あるネットワークに対応していない家電(サービス)でもそのネットワーク  につなぎたい要求に答える 設計:  VirtualServiceGateway: 異種のミドルウェア間のゲートウェイ ローカルなネットワークに設置し、このゲートウェイの間で通信を行う  ProtocolConversionManager: ローカルプロトコルとVSGの間の変換を行う ServerProxyModuleとClientProxyModule  VirtualService Repository: 異なるディレクトリサービスの統合 サービス名、サービスの内容などの情報を扱う アプリケーション例: x10リモコンでネットワークにつながっているほかの機器を操作する。 x10機器だけでなくJini機器も動かせる。 まとめ: ホームコンピューティングミドルウェアを統合するフレームワークを 提案SOAPを使用したプロトタイプ実装を行った Q:プロトコルは今後増えるといったがなぜ? A:統合されないので増えていくことになるのではないか? Q:プロトコルが増えていくとVSGプロトコルが爆発するのでは? A:プロトコルの数には制限をかけている。 Q:仮想サービスレポジトリはいらないのでは?VSGがプロトコル変換を行うなら  ば、たとえばjiniであればすべてをjiniのネットワークサーバなどでやれば  VSRはいらないのでは? A:そのとおりですね。