特表 2024-529584 オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置および方法

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-08-08

(54)【発明の名称】オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置および方法

(51)【国際特許分類】

   H04L 67/125 20220101AFI20240801BHJP

   H04L 67/51 20220101ALI20240801BHJP

【ＦＩ】

H04L67/125

H04L67/51

【審査請求】有

【予備審査請求】未請求

(21)【出願番号】P 2022572625

(86)(22)【出願日】2021-09-29

(85)【翻訳文提出日】2022-12-12

(86)【国際出願番号】 KR2021013396

(87)【国際公開番号】W WO2023013814

(87)【国際公開日】2023-02-09

(31)【優先権主張番号】10-2021-0103816

(32)【優先日】2021-08-06

(33)【優先権主張国・地域又は機関】KR

(81)【指定国・地域】

(71)【出願人】

【識別番号】522459362

【氏名又は名称】ポップコーンザー カンパニー リミテッド

(74)【代理人】

【識別番号】110003801

【氏名又は名称】ＫＥＹ弁理士法人

(72)【発明者】

【氏名】チェ ユンキ

(72)【発明者】

【氏名】イ ヨンホ

(72)【発明者】

【氏名】チェ ウォンソク

(72)【発明者】

【氏名】キム カプヒョン

(57)【要約】

本発明はオートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置および方法に関する。ＰＯＳＩＸ ＯＳが移植されたＥＣＵで構成され、オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現するマシンは、前記プラットフォーム上でサービスを提供するアプリケーションであるスケルトン；前記プラットフォーム上でサービスを使うアプリケーションであるプロキシ；および前記プラットフォーム上で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者を含む。

【特許請求の範囲】

【請求項1】

ＰＯＳＩＸ ＯＳが移植されたＥＣＵで構成され、オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現するマシンであって、
前記プラットフォーム上でサービスを提供するアプリケーションであるスケルトン；
前記プラットフォーム上でサービスを使うアプリケーションであるプロキシ；および
前記プラットフォーム上で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者；を含む、マシン。

【請求項2】

前記サービス通信管理者は
前記スケルトンが提供するサービスの情報と前記プロキシが使うサービスの情報を保存するサービスレジストリ；
前記サービスレジストリに登録されたサービスが他のＥＣＵの車両アプリケーションに提供されるか他のＥＣＵの車両アプリケーションを使わなければならない場合、前記サービス提供開始通報や前記サービスの使用のための検索要請メッセージ（サービスディスカバリメッセージ）をイーサネットマルチキャストを通じて送信するサービスディスカバリ；および
他のＥＣＵが提供・使うサービスによるデータ通信を担当するＳＯＭＥ／ＩＰブリッジ；を含むものである、請求項１に記載のマシン。

【請求項3】

前記サービス通信管理者は
前記スケルトンと前記プロキシとの通信に使われるＩＰＣポート；
前記サービスディスカバリで生成したサービスディスカバリメッセージをイーサネットマルチキャストを通じて他のＥＣＵに送信し、他のＥＣＵが送信したサービスディスカバリメッセージをイーサネットマルチキャストを通じて受信して前記サービスディスカバリに伝達するサービスディスカバリマルチキャストポート；および
前記ＳＯＭＥ／ＩＰブリッジと他のＥＣＵ間のデータ通信に使われるサービスエンドポイントポート；をさらに含むものである、請求項２に記載のマシン。

【請求項4】

前記サービスエンドポイントポートはＴＣＰプロトコルまたはＵＤＰプロトコルに従うものである、請求項３に記載のマシン。

【請求項5】

前記サービス通信管理者は
前記マシンに一つのみ存在することを特徴とする、請求項１に記載のマシン。

【請求項6】

前記スケルトンと前記プロキシは互いに直接連結されず、前記スケルトンまたは前記プロキシは前記サービス通信管理者とＩＰＣ（Ｉｎｔｅｒ－Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を通じて通信することを特徴とする、請求項１に記載のマシン。

【請求項7】

車両アプリケーション間ダイナミックサービス指向通信を実現するシステムであって、請求項１～請求項６のいずれか一項に記載されたマシンを含む、システム。

【請求項8】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートにサービス提供開始通報メッセージが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；
前記メッセージに関するサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関するサービス情報を前記サービスレジストリに登録する段階；
前記サービス情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰによりサービス提供開始を通報するメッセージを生成して他のＥＣＵに送信する段階；および
所定のＴＴＬ（Ｔｉｍｅ－ｔｏ－Ｌｉｖｅ）が満了する場合、ＳＯＭＥ／ＩＰによりサービス提供中断を通報するメッセージを生成して前記他のＥＣＵに送信する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項9】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートにサービス提供中断通報メッセージが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；
前記メッセージに関するサービス情報が前記サービスレジストリに登録されている場合、前記メッセージに関するサービス情報を前記サービスレジストリから除去する段階；および
前記サービス情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰによりサービス提供中断を通報するメッセージを生成して他のＥＣＵに送信する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項10】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートにサービス使用のための検索要請メッセージが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；
前記メッセージに関するサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関するサービス情報を前記サービスレジストリに登録する段階；および
前記サービス情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰによりサービス使用のための検索要請メッセージを生成して他のＥＣＵに送信する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項11】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートに実際のサービスの提供や使用のためのメッセージのうちいずれか一つが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；
前記サービスのＩＤがサービスレジストリに存在する場合、前記メッセージに含まれているデータの前にＳＯＭＥ／ＩＰヘッダーを追加する段階；および
前記ＳＯＭＥ／ＩＰヘッダーが追加されたメッセージを他のＥＣＵに送信する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項12】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰプロトコルに従うサービス提供開始通報メッセージが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；および
前記メッセージに関連したサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関連したサービス情報を前記サービスレジストリに登録する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項13】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰプロトコルに従うサービス使用のための検索要請メッセージが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；および
前記メッセージに関連したサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関連したサービス情報を前記サービスレジストリに登録する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項14】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰプロトコルに従うサービス提供中断通報メッセージが入力された場合の処理方法であって、
前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；および
前記メッセージに関連したサービス情報が前記サービスレジストリに登録されている場合、前記メッセージに関連したサービス情報を前記サービスレジストリから除去する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項15】

車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスエンドポイントポートに他のＥＣＵのサービスインスタンスが送信したＳＯＭＥ／ＩＰメッセージが入力された場合の処理方法であって、
前記メッセージが、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに登録されたサービスにマッチングされるかどうかを検索する段階；
前記メッセージが前記サービスレジストリに登録されたサービスにマッチングされる場合、前記サービスレジストリから前記マッチングされるサービスに該当するアプリケーションのエンドポイントアドレスを受信する段階；
前記メッセージと前記アプリケーションのエンドポイントアドレスを前記サービス通信管理者のＩＰＣポートに伝達する段階；および
前記ＩＰＣポートが自身と連結されている車両アプリケーションに前記メッセージを送信する段階；を含む、サービス通信管理者の入力メッセージ処理方法。

【請求項16】

オートサーアダプティブプラットフォーム上でサービスを提供するアプリケーションであるスケルトンのサービス指向通信方法であって、
前記スケルトンと同一のマシン内で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者にサービス提供開始通報メッセージを送信する段階；
前記サービス通信管理者からサービス要請メッセージを受信する段階；
前記サービス要請メッセージのパーシング結果によりメッセージをメソッド呼び出しメッセージ（Ｒｅｑｕｅｓｔメッセージ）またはイベントメッセージに対する購読要請メッセージ（ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージ）に区分する段階；
前記区分の結果、前記サービス要請メッセージが前記Ｒｅｑｕｅｓｔメッセージである場合、該当メソッドを呼び出してその結果として生成された応答メッセージを前記サービス通信管理者に送信する段階；
前記区分の結果、前記サービス要請メッセージが前記ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージである場合、購読者レジストリにメッセージの内容を登録し、前記イベントメッセージの送信条件が到来する時にイベントメッセージを生成して前記サービス通信管理者に送信する段階；および
サービスインスタンス終了条件が満たされる場合、サービス提供中断通報メッセージを生成して前記サービス通信管理者に送信する段階；を含む、スケルトンのサービス指向通信方法。

【請求項17】

オートサーアダプティブプラットフォーム上でサービスを使うアプリケーションであるプロキシのサービス指向通信方法であって、
前記プロキシと同一のマシン内で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者にサービス使用のための検索要請メッセージを送信する段階；
前記サービス通信管理者から前記メッセージに対する応答を受信する段階；
現在使用可能なサービスリストから一つのサービスを選択する段階；
サービスの提供を受ける方法を決定する段階；
前記サービスの提供を受ける方法がメソッドを明示して呼び出す方法の場合、メソッド呼び出しメッセージ（Ｒｅｑｕｅｓｔメッセージ）を生成して前記サービス通信管理者に送信する段階；
前記サービスの提供を受ける方法がイベントメッセージに対する購読である場合、イベントメッセージに対する購読要請メッセージ（ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージ）を生成して前記サービス通信管理者に送信する段階；
前記サービス通信管理者からサービスを提供するメッセージを受信する段階；
前記サービスを提供するメッセージをパーシングして区分する段階；
前記区分の結果、前記サービスを提供するメッセージがメソッド実行結果メッセージ（Ｒｅｓｐｏｎｓｅメッセージ）である場合、メソッド呼び出し元（ｍｅｔｈｏｄ ｃａｌｌｅｒ）を経てユーザ（ｕｓｅｒ）具現部分に結果を伝達する段階；
前記区分の結果、前記サービスを提供するメッセージがイベントメッセージ（Ｅｖｅｎｔメッセージ）である場合、前記イベントメッセージをイベントバッファに保存する段階；および
サービスインスタンス終了条件が満たされる場合、サービス使用中断通報メッセージを生成して前記サービス通信管理者に送信する段階；を含む、プロキシのサービス指向通信方法。

【発明の詳細な説明】

【技術分野】

【0001】

本発明はオートサーアダプティブプラットフォーム（ＡＵＴＯＳＡＲ Ａｄａｐｔｉｖｅ Ｐｌａｔｆｏｒｍ）で車両アプリケーション間ダイナミックサービス指向通信を実現する装置および方法に関する。さらに詳細には、車両アプリケーションが提供するか使うサービスの登録・発見および前記サービスの提供と使用のための通信を総合的に掌るプラットフォーム水準のアプリケーションで構成された、オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置とその装置を活用した車両アプリケーション間ダイナミックサービス指向通信方法に関する。

【背景技術】

【0002】

自動車分野でのソフトウェア再使用のために、２００５年主要自動車メーカーおよび開発会社によってオートサー（ＡＵＴＯＳＡＲ）標準が制定された。

【0003】

その後、自動車産業における３つの大きな話題であるネットワークの連結・自律走行・電気化のために、ＥＣＵの統合などの新しい電気・電子アーキテクチャの必要性が提起され、これに伴い高性能ＣＰＵ基盤のＥＣＵソフトウェアプラットフォーム標準であるオートサーアダプティブプラットフォーム（ＡＵＴＯＳＡＲ Ａｄａｐｔｉｖｅ Ｐｌａｔｆｏｒｍ、以下ＡＰ）標準が２０１７年新設されて２０１９年から量産に適用されている。

【0004】

ＡＰを基盤として車両をスマートフォンのような一つのプラットフォームで運用する動きが速やかに進行されており、グローバルの主要ＯＥＭだけでなく、ローカルＯＥＭもＡＰを適用した新規のＥＣＵ開発を準備中である。

【0005】

信号指向通信（ｓｉｇｎａｌ－ｏｒｉｅｎｔｅｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ）に基づいたオートサークラシックプラットフォーム（ＡＵＴＯＳＡＲ ｃｌａｓｓｉｃ ｐｌａｔｆｏｒｍ）とは異なってＡＰはサービス指向通信（ｓｅｒｖｉｃｅ－ｏｒｉｅｎｔｅｄ ｃｏｍｍｕｎｉｃａｔｉｏｎ）に基づいているが、これはサービス提供者であるスケルトン（ｓｋｅｌｅｔｏｎ）とサービス使用者であるプロキシ（ｐｒｏｘｙ）がサービスディスカバリ（ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ）およびＳＯＭＥ／ＩＰ（Ｓｃａｌａｂｌｅ ｓｅｒｖｉｃｅ－Ｏｒｉｅｎｔｅｄ ＭｉｄｄｌｅｗａｒＥ ｏｖｅｒ ＩＰ）を通じて動的に連結される通信方式である。このようなＡＰアプリケーション間サービス指向通信を担当する機能クラスタはサービス通信管理者（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ、以下、ＣＭ）である。

【0006】

ところが、オートサー標準にＣＭに対する仕様書があるものの、細部的には規定されていないため、開発者により具現の形態が相当に異なり得る。ＣＭ仕様書はポートを通じてアプリケーション双方が連結される構造を提示しているが、ポート一個当たり一つのＳＯＭＥ／ＩＰエンドポイント（ｅｎｄｐｏｉｎｔ）を配置するがポートの個数には制限がない。したがって、開発者の設計方法によりアプリケーションの規模が大きいほどポート数が急激に増加し得、これは資源の浪費を招く。また、スケルトンとプロキシが直接的に通信をする場合、それぞれバッファとレジストリ構造を備えなければならないため、アプリケーションの規模が大きくなって負荷の問題が深刻とならざるを得ない問題点がある。

【発明の概要】

【発明が解決しようとする課題】

【0007】

本発明は前記のような問題点を解決するためのもので、スケルトンとプロキシ間の直接的な連結を排除し、内・外部通信機能をＣＭで一元化したマシン（ＰＯＳＩＸ ＯＳがポーティングされたＥＣＵ）で構成された車両アプリケーション間ダイナミックサービス指向通信を実現する装置とその装置を活用したサービス指向通信方法を提供することにその目的がある。

【0008】

本発明の目的は以上で言及した目的に制限されず、言及されていないさらに他の目的は下記の記載から当業者に明確に理解され得るであろう。

【課題を解決するための手段】

【0009】

前記目的を達成するための本発明の一実施例に係るマシンは、ＰＯＳＩＸ ＯＳが移植されたＥＣＵで構成され、オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現するマシンであって、前記プラットフォーム上でサービスを提供するアプリケーションであるスケルトン；前記プラットフォーム上でサービスを使うアプリケーションであるプロキシ；および前記プラットフォーム上で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者；を含む。

【0010】

前記サービス通信管理者は、前記スケルトンが提供するサービスの情報と前記プロキシが使うサービスの情報を保存するサービスレジストリ；前記サービスレジストリに登録されたサービスが他のＥＣＵの車両アプリケーションに提供されるか他のＥＣＵの車両アプリケーションを使わなければならない場合、前記サービス提供開始通報や前記サービスの使用のための検索要請メッセージ（サービスディスカバリメッセージ）をイーサネットマルチキャストを通じて送信するサービスディスカバリ；および他のＥＣＵが提供・使うサービスによるデータ通信を担当するＳＯＭＥ／ＩＰブリッジ；を含むことができる。

【0011】

また、前記サービス通信管理者は、前記スケルトンと前記プロキシとの通信に使われるＩＰＣポート；前記サービスディスカバリで生成したサービスディスカバリメッセージをイーサネットマルチキャストを通じて他のＥＣＵに送信し、他のＥＣＵが送信したサービスディスカバリメッセージをイーサネットマルチキャストを通じて受信して前記サービスディスカバリに伝達するサービスディスカバリマルチキャストポート；および前記ＳＯＭＥ／ＩＰブリッジと他のＥＣＵ間のデータ通信に使われるサービスエンドポイントポート；をさらに含むことができる。

【0012】

一方、前記サービスエンドポイントポートはＴＣＰプロトコルまたはＵＤＰプロトコルに従うものであり得る。

【0013】

また、前記サービス通信管理者は前記マシンに一つのみ存在することができる。

【0014】

一方、前記スケルトンと前記プロキシは互いに直接連結されず、前記スケルトンまたは前記プロキシは前記サービス通信管理者とＩＰＣ（Ｉｎｔｅｒ－Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を通じて通信することができる。

【0015】

一方、本発明の一実施例に係る車両アプリケーション間ダイナミックサービス指向通信を実現するシステムは前記マシンを含む。

【0016】

一方、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートにサービス提供開始通報メッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記メッセージに関するサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関するサービス情報を前記サービスレジストリに登録する段階；前記サービス情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰによりサービス提供開始を通報するメッセージを生成して他のＥＣＵに送信する段階；および所定のＴＴＬ（Ｔｉｍｅ－ｔｏ－Ｌｉｖｅ）が満了する場合、ＳＯＭＥ／ＩＰによりサービス提供中断を通報するメッセージを生成して前記他のＥＣＵに送信する段階；を含む。

【0017】

また、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートにサービス提供中断通報メッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記メッセージに関するサービス情報が前記サービスレジストリに登録されている場合、前記メッセージに関するサービス情報を前記サービスレジストリから除去する段階；および前記サービス情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰによりサービス提供中断を通報するメッセージを生成して他のＥＣＵに送信する段階；を含む。

【0018】

また、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートにサービス使用のための検索要請メッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記メッセージに関するサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関するサービス情報を前記サービスレジストリに登録する段階；および前記サービス情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰによりサービス使用のための検索要請メッセージを生成して他のＥＣＵに送信する段階；を含む。

【0019】

また、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のＩＰＣポートに実際のサービスの提供や使用のためのメッセージのうちいずれか一つが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記サービスのＩＤがサービスレジストリに存在する場合、前記メッセージに含まれているデータの前にＳＯＭＥ／ＩＰヘッダーを追加する段階；および前記ＳＯＭＥ／ＩＰヘッダーが追加されたメッセージを他のＥＣＵに送信する段階；を含む。

【0020】

一方、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰプロトコルに従うサービス提供開始通報メッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記メッセージに関連したサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関連したサービス情報を前記サービスレジストリに登録する段階；を含む。

【0021】

また、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰプロトコルに従うサービス使用のための検索要請メッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記メッセージに関連したサービス情報が前記サービスレジストリに登録されていない場合、前記メッセージに関連したサービス情報を前記サービスレジストリに登録する段階；を含む。

【0022】

また、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰプロトコルに従うサービス提供中断通報メッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージを、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに伝達する段階；前記メッセージに関連したサービス情報が前記サービスレジストリに登録されている場合、前記メッセージに関連したサービス情報を前記サービスレジストリから除去する段階；を含む。

【0023】

一方、本発明の一実施例に係る車両アプリケーション間サービス指向通信を仲介するサービス通信管理者のサービスエンドポイントポートに他のＥＣＵのサービスインスタンスが送信したＳＯＭＥ／ＩＰメッセージが入力された場合のサービス通信管理者の入力メッセージ処理方法は、前記メッセージが、同一のマシン内で提供されるか使われるサービスの情報を保存するサービスレジストリに登録されたサービスにマッチングされるかどうかを検索する段階；前記メッセージが前記サービスレジストリに登録されたサービスにマッチングされる場合、前記サービスレジストリから前記マッチングされるサービスに該当するアプリケーションのエンドポイントアドレスを受信する段階；前記メッセージと前記アプリケーションのエンドポイントアドレスを前記サービス通信管理者のＩＰＣポートに伝達する段階；および前記ＩＰＣポートが自身と連結されている車両アプリケーションに前記メッセージを送信する段階；を含む。

【0024】

一方、本発明の一実施例に係るオートサーアダプティブプラットフォーム上でサービスを提供するアプリケーションであるスケルトンのサービス指向通信方法は、前記スケルトンと同一のマシン内で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者にサービス提供開始通報メッセージを送信する段階；前記サービス通信管理者からサービス要請メッセージを受信する段階；前記サービス要請メッセージのパーシング結果によりメッセージをメソッド呼び出しメッセージ（Ｒｅｑｕｅｓｔメッセージ）またはイベントメッセージに対する購読要請メッセージ（ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージ）に区分する段階；前記区分の結果、前記サービス要請メッセージが前記Ｒｅｑｕｅｓｔメッセージである場合、該当メソッドを呼び出してその結果として生成された応答メッセージを前記サービス通信管理者に送信する段階；前記区分の結果、前記サービス要請メッセージが前記ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージである場合、購読者レジストリにメッセージの内容を登録し、前記イベントメッセージの送信条件が到来する時にイベントメッセージを生成して前記サービス通信管理者に送信する段階；およびサービスインスタンス終了条件となる場合、サービス提供中断通報メッセージを生成して前記サービス通信管理者に送信する段階；を含む。

【0025】

一方、本発明の一実施例に係るオートサーアダプティブプラットフォーム上でサービスを使うアプリケーションであるプロキシのサービス指向通信方法は、前記プロキシと同一のマシン内で車両アプリケーション間サービス指向通信を仲介するアプリケーションであるサービス通信管理者にサービス使用のための検索要請メッセージを送信する段階；前記サービス通信管理者から前記メッセージに対する応答を受信する段階；現在使用可能なサービスリストから一つのサービスを選択する段階；サービスの提供を受ける方法を決定する段階；前記サービスの提供を受ける方法がメソッドを明示して呼び出す方法の場合、メソッド呼び出しメッセージ（Ｒｅｑｕｅｓｔメッセージ）を生成して前記サービス通信管理者に送信する段階；前記サービスの提供を受ける方法がイベントメッセージに対する購読である場合、イベントメッセージに対する購読要請メッセージ（ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージ）を生成して前記サービス通信管理者に送信する段階；前記サービス通信管理者からサービスを提供するメッセージを受信する段階；前記サービスを提供するメッセージをパーシングして区分する段階；前記区分の結果、前記サービスを提供するメッセージがメソッド実行結果メッセージ（Ｒｅｓｐｏｎｓｅメッセージ）である場合、メソッド呼び出し元（ｍｅｔｈｏｄ ｃａｌｌｅｒ）を経てユーザ（ｕｓｅｒ）具現部分に結果を伝達する段階；前記区分の結果、前記サービスを提供するメッセージがイベントメッセージ（Ｅｖｅｎｔメッセージ）である場合、前記イベントメッセージをイベントバッファに保存する段階；およびサービスインスタンス終了条件となる場合、サービス使用中断通報メッセージを生成して前記サービス通信管理者に送信する段階；を含む。

【発明の効果】

【0026】

本発明の一実施例によると、サービス仲介に必要なサービスレジストリ、サービスディスカバリをＣＭで一元化することによって、スケルトンとプロキシそれぞれがバッファとレジストリを管理する場合に比べてメモリと通信負荷などのアプリケーションの負荷が減少し、スケルトンとプロキシ間に適切なサービスマッチングが速かになされ得る。

【0027】

また、本発明の一実施例によると、他のＥＣＵとの通信機能をＣＭで一元化してアプリケーションが保有するポート数が減少することによって、ポート一個当たりに占有するバッファ、スレッド（ｔｈｒｅａｄ）等のＰＯＳＩＸ ＯＳの占有するリソースが減少するため、安定性が増大する効果がある。

【0028】

また、本発明の一実施例によると、多数のアプリケーションでそれぞれ具現されるサービスレジストリ、サービスディスカバリを一つのプロセスで取り扱うため、コンパイルする時にプログラムの大きさが減少する効果がある。

【図面の簡単な説明】

【0029】

【図1】オートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置の構成およびその連結構造を示した図面である。

【図2】サービス通信管理者の構成図である。

【図3a】サービス通信管理者のＩＰＣポートにサービスディスカバリメッセージのうちＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図3b】サービス通信管理者のＩＰＣポートにサービスディスカバリメッセージのうちＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図3c】サービス通信管理者のＩＰＣポートにサービスディスカバリメッセージのうちＦｉｎｄＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図4】サービス通信管理者のＩＰＣポートにサービスメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図5a】サービス通信管理者のＳＯＭＥ／ＩＰサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰサービスディスカバリＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図5b】サービス通信管理者のＳＯＭＥ／ＩＰサービスディスカバリマルチキャストポートにＳＯＭＥ／ＩＰサービスディスカバリＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図6】サービス通信管理者のＳＯＭＥ／ＩＰサービスエンドポイントポートにメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【図7】スケルトンのサービス指向通信方法を説明するためのフローチャートである。

【図8】プロキシのサービス指向通信方法を説明するためのフローチャートである。

【発明を実施するための形態】

【0030】

本発明の利点および特徴、そしてそれらを達成する方法は、添付される図面と共に詳細に後述されている実施例を参照すると明確になるであろう。しかし、本発明は以下で開示される実施例に限定されるものではなく互いに異なる多様な形態で具現され得、ただし、本実施例は本発明の開示を完全なものとし、本発明が属する技術分野で通常の知識を有する者に発明の範疇を完全に知らせるために提供されるものであり、本発明は請求項の範疇によって定義されるのみである。一方、本明細書で使われた用語は実施例を説明するためのものであり本発明を制限しようとするものではない。本明細書で、単数型は文面で特に言及しない限り複数型も含む。明細書で使われる「含む（ｃｏｍｐｒｉｓｅｓ）」および／または「含む（ｃｏｍｐｒｉｓｉｎｇ）」は言及された構成素子、段階、動作および／または素子は一つ以上の他の構成素子、段階、動作および／または素子の存在または追加を排除しない。以下、本発明に係るオートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置および方法を説明する。

【0031】

図１は、本発明の一実施例に係るオートサーアダプティブプラットフォームで車両アプリケーション間ダイナミックサービス指向通信を実現する装置の構成およびその連結構造を示した図面である。

【0032】

基本的に車両アプリケーション間ダイナミックサービス指向通信を実現するシステムは、一つの車両１００に複数のマシン１１０－１～１１０－ｎがポート１７２、１８２と車両のイーサネット１９０を通じて連結される構造を有する。マシン（ｍａｃｈｉｎｅ、１１０－１～１１０－ｎ）はＡＰの用語であって、一つのＰＯＳＩＸ ＯＳがポーティングされた（移植された）一つのＥＣＵを意味する。ただし、前記システムには少なくとも一つのマシンが含まれるが、マシンではないＥＣＵが前記システムに含まれ得、前記マシンではないＥＣＵ内のアプリケーションが前記システムのマシンにあるアプリケーションにサービスを提供するか前記システムのマシンのアプリケーションのサービスを使うことができる。マシンそれぞれ（１１０－１～１１０－ｎのうち一つ、以下、１１０で表記）は、スケルトン（ｓｋｅｌｅｔｏｎ、１２０）、プロキシ（ｐｒｏｘｙ、１４０）、サービス通信管理者（Ｃｏｍｍｕｎｉｃａｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ、以下、ＣＭ、１５０）を含む。スケルトン１２０はサービスを提供する車両アプリケーションであり、サービス提供者の役割を具現したサービスプロバイダインスタンス（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ ｉｎｓｔａｎｃｅ）を有するＰＯＳＩＸプロセスである。プロキシ１４０はサービスを使う車両アプリケーションであり、サービス使用者役割を具現したサービスコンシューマインスタンス（ｓｅｒｖｉｃｅ ｃｏｎｓｕｍｅｒ ｉｎｓｔａｎｃｅ）を有するＰＯＳＩＸプロセスである。スケルトン１２０やプロキシ１４０は一つのマシン１１０に複数個で存在することができる。また、一つのアプリケーションがスケルトン１２０であるとともに、プロキシ１４０となり得る。ＣＭ１５０は車両アプリケーションのサービス指向通信を仲介するプラットフォームアプリケーションである。ＣＭ１５０は一つのマシン１１０に一つのみ存在するものと制限される。一つのマシン１１０に含まれているスケルトン１２０またはプロキシ１４０は、同一のマシン１１０に含まれているＣＭ１５０とＩＰＣ（Ｉｎｔｅｒ－Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ）を通じて通信する。同一のマシン１１０に含まれたスケルトン１２０とプロキシ１４０は互いに直接的に連結されない。

【0033】

スケルトン１２０はサービスを提供するための通信ポートであるサービスプロバイダポート（ｓｅｒｖｉｃｅ ｐｒｏｖｉｄｅｒ ｐｏｒｔ、１２２）を有する。スケルトン１２０はサービスプロバイダポート１２２を通じて提供するサービスに対する通信設定命令と前記サービスと関連して使われるデータをＣＭ１５０に送信する。

【0034】

プロキシ１４０はサービスを使うための通信ポートであるサービスコンシューマポート（ｓｅｒｖｉｃｅ ｃｏｎｓｕｍｅｒ ｐｏｒｔ、１４２）を有する。プロキシ１４０はサービスコンシューマポート１４２を通じて使うサービスに対する通信設定命令と前記サービスと関連して使われるデータをＣＭ１５０に送信する。

【0035】

ＣＭ１５０は各車両アプリケーションから入ってくる要請を処理するためにＩＰＣポート（Ｉｎｔｅｒ－Ｐｒｏｃｅｓｓ Ｃｏｍｍｕｎｉｃａｔｉｏｎ ｐｏｒｔ、１５２）を有する。ＣＭ１５０はＩＰＣポート１５２を通じて車両アプリケーションから送信したデータを受信し、受信したデータを処理して目標アプリケーションに送信する。

【0036】

ＣＭ１５０は他のＥＣＵ（同一車両内で物理的に分離された他のＥＣＵ）と通信するためにＳＯＭＥ／ＩＰ ＳＤマルチキャストポート（ＳＯＭＥ／ＩＰ ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ ｍｕｌｔｉｃａｓｔ ｐｏｒｔ、以下ＳＤマルチキャストポート、１７２）とＳＯＭＥ／ＩＰサービスエンドポイントポート（ＳＯＭＥ／ＩＰ ｓｅｒｖｉｃｅ ｅｎｄｐｏｉｎｔ ｐｏｒｔ、以下サービスエンドポイントポート、１８２）を有する。前記ポート１７２、１８２は車両のイーサネット１９０に連結される。

【0037】

図２は、本発明の一実施例に係るＣＭ１５０の構成図である。ＣＭ１５０は図２に図示された通り、サービスレジストリ（ｓｅｒｖｉｃｅ ｒｅｇｉｓｔｒｙ、１６０）、サービスディスカバリ（ｓｅｒｖｉｃｅ ｄｉｓｃｏｖｅｒｙ、１７０）、ＳＯＭＥ／ＩＰブリッジ（ＳＯＭＥ／ＩＰ ｂｒｉｄｇｅ、１８０）、ＩＰＣポート１５２、ＳＤマルチキャストポート１７２、ＳＯＭＥ／ＩＰリモートＴＣＰポート（ＳＯＭＥ／ＩＰ ｒｅｍｏｔｅ ＴＣＰ ｐｏｒｔ、以下、ＴＣＰポート、１８２ａ）およびＳＯＭＥ／ＩＰリモートＵＤＰポート（ＳＯＭＥ／ＩＰ ｒｅｍｏｔｅ ＵＤＰ ｐｏｒｔ、以下、ＵＤＰポート、１８２ｂ）を含む。ＴＣＰポート１８２ａとＵＤＰポート１８２ｂはサービスエンドポイントポート１８２に該当する。

【0038】

ＣＭ１５０は同一のマシン１１０に存在するスケルトン１２０とプロキシ１４０との通信のためのＩＰＣポート１５２を有する。

【0039】

ＩＰＣポート１５２は同一のマシン１１０に存在するスケルトン１２０とプロキシ１４０との通信のためのポートであり、受信したメッセージの類型がサービスディスカバリメッセージであればこのメッセージをサービスレジストリ１６０に伝達し、サービスメッセージであればサービスレジストリ１６０にサービスＩＤが存在する場合に該当メッセージをＳＯＭＥ／ＩＰブリッジ１８０に伝達する。

【0040】

サービスレジストリ１６０はマシン１１０内のスケルトン１２０が提供するサービスまたはプロキシ１４０が使うサービスの情報を保存するデータ構造である。

【0041】

サービスレジストリ１６０がサービスに対する提供開始通報メッセージ（ＯｆｆｅｒＳｅｒｖｉｃｅメッセージ、以下では「サービス提供開始通報メッセージ」ともいう。）またはサービス使用のための検索要請メッセージ（ＦｉｎｄＳｅｒｖｉｃｅメッセージ）をＩＰＣポート１５２やＳＤマルチキャストポート１７２から伝達を受ける場合、該当サービス情報がサービスレジストリ１６０に登録されているかどうかを確認し、既存のテーブルに登録されていないサービスの場合、テーブルに該当サービスに対する情報を登録する。また、サービスレジストリ１６０は新しく登録されたサービス情報の類型を判断して、ＩＰＣタイプであればサービス登録情報をサービスディスカバリ１７０に伝達せず、ＳＯＭＥ／ＩＰタイプであればサービス登録情報をサービスディスカバリ１７０に伝達する。

【0042】

サービスレジストリ１６０はサービス提供中断通報メッセージ（ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージ）を受信する場合、該当サービス情報がサービスレジストリ１６０に登録されているかどうかを確認し、サービスレジストリ１６０に登録されていればサービスレジストリ１６０はこの情報をテーブルから除去し、サービスレジストリ１６０に登録されていなければ、サービスレジストリ１６０は前記サービス情報の類型を判断して、ＩＰＣタイプであればサービス情報をサービスディスカバリ１７０に伝達せず、ＳＯＭＥ／ＩＰタイプであれば前記サービス情報をサービスディスカバリ１７０に伝達する。

【0043】

サービスディスカバリ１７０は、サービスレジストリ１６０に登録されたサービスが他のＥＣＵの車両アプリケーションに提供されるか他のＥＣＵの車両アプリケーションを使わなければならない場合、このようなサービス提供／使用に対するメッセージをイーサネットマルチキャスト（ｅｔｈｅｒｎｅｔ ｍｕｌｔｉｃａｓｔ）を通じて送信する。また、サービスディスカバリ１７０は他のＥＣＵに登録されたサービスに関するサービス提供および検索要請メッセージを受信する。このために、サービスディスカバリ１７０はイーサネットマルチキャストでバインディングされたＳＤマルチキャストポート１７２を有する。ＡＰのサービス指向通信は多くのサービスが共通のイーサネットマルチキャストにジョイン（ｊｏｉｎ）してなされる。ＳＤマルチキャストポート１７２はサービスディスカバリ１７０で生成したサービスディスカバリメッセージを自身と連結されたイーサネットマルチキャストを通じて他のＥＣＵに送信し、他のＥＣＵが送信したＳＯＭＥ／ＩＰサービスディスカバリメッセージを自身と連結されたイーサネットマルチキャストを通じて受信してサービスディスカバリ１７０に伝達する。

【0044】

サービスディスカバリ１７０はＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージを生成して送信した後にＴＴＬが満了したか、ＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅメッセージを生成して送信した後にＴＴＬが満了した場合、該当するサービスのインスタンスを中断する。また、ＴＴＬが満了する前であっても、スケルトン１２０でＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅを要請したのであれば、サービスディスカバリ１７０は該当サービス情報に基づいてＳＯＭＥ／ＩＰ ＳＤのＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージを作り、前記メッセージをイーサネットマルチキャストに送信した後、該当サービスのインスタンスを中断する。

【0045】

ＳＯＭＥ／ＩＰブリッジ１８０は登録されたサービスがＳＯＭＥ／ＩＰプロトコルを使ってサービス処理に必要なデータを送受信することを要求する場合、サービスディスカバリ１７０によって動的に生成されるインスタンスである。ＳＯＭＥ／ＩＰブリッジ１８０は単数はもちろん複数個生成され得る。ＳＯＭＥ／ＩＰブリッジ１８０は他のＥＣＵが提供するか他のＥＣＵで使うサービスによるデータ通信を担当する。このために一つのＳＯＭＥ／ＩＰブリッジ１８０はＴＣＰポート１８２ａとＵＤＰポート１８２ｂを有する。ＳＯＭＥ／ＩＰブリッジ１８０はサービスディスカバリ１７０からネットワークエンドポイント情報の伝達を受けると、この情報に基づいてＰＯＳＩＸのイーサネットソケットであるＴＣＰポート１８２ａとＵＤＰポート１８２ｂをオープンする。この時、必要なネットワークエンドポイント情報はＳＯＭＥ／ＩＰ基盤のサービスインスタンスが使うＩＰアドレス、ポート番号、プロトコルの情報である。プロトコルはＴＣＰまたはＵＤＰのみ許容される。

【0046】

またＳＯＭＥ／ＩＰブリッジ１８０はＩＰＣポート１５２からサービスメッセージが伝達されると、データの前にＳＯＭＥ／ＩＰヘッダーを追加した後にＳＯＭＥ／ＩＰメッセージをＴＣＰポート１８２ａまたはＵＤＰポート１８２ｂに伝達して、前記ポートを通じてＳＯＭＥ／ＩＰメッセージが送信されるようにする。

【0047】

またＳＯＭＥ／ＩＰブリッジ１８０はＴＣＰポート１８２ａまたはＵＤＰポート１８２ｂから他のＥＣＵのサービスインスタンスが送信したＳＯＭＥ／ＩＰメッセージの伝達を受けると、伝達されたＳＯＭＥ／ＩＰメッセージがサービスレジストリ１６０に登録されたサービスにマッチングされるかどうかを検索する。前記メッセージがサービスレジストリ１６０に登録されたサービスにマッチングされる場合、ＳＯＭＥ／ＩＰブリッジ１８０はサービスレジストリ１６０からマッチングされるサービスに該当するアプリケーションのエンドポイントアドレスを受信する。ＳＯＭＥ／ＩＰブリッジ１８０は前記メッセージとアプリケーションのエンドポイントアドレスをＩＰＣポート１５２に伝達することによって、ＩＰＣポート１５２が自身と連結されているスケルトン１２０やプロキシ１４０に前記メッセージを送信することができるようにする。

【0048】

図３ａ、図３ｂ、図３ｃ、図４はＣＭ１５０のＩＰＣポート１５２にメッセージが入力された場合の各メッセージの類型と内容によるＣＭ１５０の処理方法を説明するためのフローチャートである。前記図面の説明に先立ち、ＩＰＣポート１５２で受信するメッセージ類型について説明する。

【0049】

ＩＰＣポート１５２が受信するメッセージ類型は、（１）サービスディスカバリメッセージと（２）サービスメッセージに区分される。（１）サービスディスカバリメッセージは車両アプリケーションがサービスの提供を開始・中断するメッセージであるかまたはサービス使用のために検索を要請するメッセージである。（２）サービスメッセージはサービスが登録された以後、連結されたサービスインスタンスの間で実際のサービスの提供と使用のために送受信するメッセージである。ＩＰＣポート１５２はプロトコルヘッダーを利用して（１）と（２）を区分する。

【0050】

スケルトン１２０がサービス提供ＡＰＩを使ってサービスの提供を開始するかまたはサービスの提供を中断する場合、スケルトン１２０はサービスディスカバリメッセージを生成してＣＭ１５０に送信する。スケルトン１２０がサービスの提供を開始する場合はＯｆｆｅｒＳｅｒｖｉｃｅメッセージを生成してＣＭ１５０に送信し、サービスの提供を中断する場合はＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージを生成してＣＭ１５０に送信する。

【0051】

プロキシ１４０がサービス検索ＡＰＩを使ってサービス検索を開始する場合、プロキシ１４０はサービスディスカバリメッセージのうちの一つであるＦｉｎｄＳｅｒｖｉｃｅメッセージを生成してＣＭ１５０に送信する。

【0052】

ＩＰＣポート１５２はサービスディスカバリメッセージを受信した場合、このメッセージをサービスレジストリ１６０に伝達する。

【0053】

ＩＰＣポート１５２はサービスメッセージを受信した場合、前記サービスメッセージのサービスＩＤがサービスレジストリ１６０にあるかどうかを検索する。もし存在すればＳＯＭＥ／ＩＰブリッジ１８０に前記サービスメッセージを伝達する。

【0054】

図３ａは、本発明の一実施例に係るＣＭ１５０のＩＰＣポート１５２にサービスディスカバリメッセージのうちＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【0055】

Ｓ１１０段階で、ＯｆｆｅｒＳｅｒｖｉｃｅメッセージはサービスディスカバリメッセージであるので、ＩＰＣポート１５２はこのメッセージをサービスレジストリ１６０に伝達する。

【0056】

Ｓ１１２段階で、サービスレジストリ１６０はＯｆｆｅｒＳｅｒｖｉｃｅメッセージに関するサービス情報が登録されているかどうかを確認する。

【0057】

Ｓ１１４段階で、ＯｆｆｅｒＳｅｒｖｉｃｅメッセージに関するサービス情報がすでにサービスレジストリ１６０に登録されていれば、このサービスを登録せずに無視する。もしＯｆｆｅｒＳｅｒｖｉｃｅメッセージに関するサービス情報がサービスレジストリ１６０に登録されていなければ、Ｓ１１６段階を遂行する。

【0058】

Ｓ１１６段階で、サービスレジストリ１６０はＯｆｆｅｒＳｅｒｖｉｃｅメッセージに関するサービス情報を登録する。提供するサービスのインスタンス明示子、サービスＩＤ、インスタンスＩＤ、バージョン情報、アプリケーションのネットワークエンドポイント情報をテーブルのタプル（ｔｕｐｌｅ）として登録する。

【0059】

Ｓ１１８段階で、サービスレジストリ１６０は前記登録されたサービス情報の類型を判断して、ＩＰＣタイプであれば登録情報をサービスディスカバリ１７０に伝達しない。ＳＯＭＥ／ＩＰタイプであればＳ１２０段階を遂行する。

【0060】

Ｓ１２０段階で、サービスレジストリ１６０は登録情報をサービスディスカバリ１７０に伝達する。

【0061】

Ｓ１２２段階で、サービスディスカバリ１７０が伝達を受けた情報はＯｆｆｅｒＳｅｒｖｉｃｅメッセージから派生したものであるので、サービスディスカバリ１７０はＳＯＭＥ／ＩＰサービスディスカバリＯｆｆｅｒＳｅｒｖｉｃｅメッセージ（以下、ＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージ）を生成する。

【0062】

Ｓ１２４段階で、前記メッセージを処理するために、サービスディスカバリ１７０はＳＯＭＥ／ＩＰブリッジ１８０インスタンスを生成する。

【0063】

Ｓ１２６段階で、サービスディスカバリ１７０はサービスレジストリ１６０から受けたネットワークエンドポイント情報をＳＯＭＥ／ＩＰブリッジ１８０に伝達する。

【0064】

Ｓ１２８段階で、ＳＯＭＥ／ＩＰブリッジ１８０は前記ネットワークエンドポイント情報に基づいてＰＯＳＩＸのイーサネットソケットであるＴＣＰポート１８２ａとＵＤＰポート１８２ｂをオープンする。この時、必要なネットワークエンドポイント情報はＳＯＭＥ／ＩＰ基盤のサービスインスタンスが使うＩＰアドレス、ポート番号、プロトコルの情報である。プロトコルはＴＣＰまたはＵＤＰのみ許容される。

【0065】

生成されたＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージの送信／待機は、初期段階（ｉｎｉｔｉａｌ ｗａｉｔ ｐｈａｓｅ、Ｓ１３０）、繰り返し段階（ｒｅｐｅｔｉｔｉｏｎ ｐｈａｓｅ、Ｓ１３２）、主段階（ｍａｉｎ ｐｈａｓｅ、Ｓ１３４）に分かれて進行される。

【0066】

Ｓ１３０段階で、サービスディスカバリ１７０はサービスレジストリ１６０から伝達された情報に明示された時間の間待機した後、ＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージをＳＤマルチキャストポート１７２を通じて連結されたイーサネットマルチキャストに送信する。

【0067】

Ｓ１３２段階で、サービスディスカバリ１７０はサービスレジストリ１６０から伝達された情報に明示された時間の間待機した後、ＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージをＳＤマルチキャストポート１７２を通じて連結されたイーサネットマルチキャストに送信する。

【0068】

Ｓ１３４段階で、サービスディスカバリ１７０はサービスレジストリ１６０から伝達された情報に明示された周期によりＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージをＳＤマルチキャストポート１７２を通じて連結されたイーサネットマルチキャストに送信する。

【0069】

Ｓ１３６段階では、明示されたＴＴＬが満了したかどうかを確認して、満了していなければＳ１３４段階が引き続き進行される。もし明示されたＴＴＬが満了したのであればＳ１３８段階を遂行する。

【0070】

Ｓ１３８段階で、サービスディスカバリ１７０は、該当サービス情報に基づいてＳＯＭＥ／ＩＰサービスディスカバリＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージ（以下、ＳＯＭＥ／ＩＰ ＳＤ ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージ）を生成し、前記メッセージをＳＤマルチキャストポート１７２を通じて連結されたイーサネットマルチキャストに送信する（Ｓ１４０）。

【0071】

Ｓ１４２段階でサービスディスカバリ１７０は該当するサービスのインスタンスを中断する。

【0072】

前記明示されたＴＴＬが満了する前であっても、スケルトン１２０でＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅを要請した場合は図３ｂに関する説明に従う（Ｓ１５０～Ｓ１６６）。

【0073】

図３ｂは、本発明の一実施例に係るＣＭ１５０のＩＰＣポート１５２にサービスディスカバリメッセージのうちＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【0074】

Ｓ１５０段階で、ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージはサービスディスカバリメッセージであるので、ＩＰＣポート１５２はこのメッセージをサービスレジストリ１６０に伝達する。

【0075】

Ｓ１５２段階でサービスレジストリ１６０はこの情報をテーブルから除去する。

【0076】

Ｓ１５４段階で、サービスレジストリ１６０は前記サービス情報の類型を判断して、ＩＰＣタイプであればサービス情報をサービスディスカバリ１７０に伝達しない。ＳＯＭＥ／ＩＰタイプであればＳ１５６段階を遂行する。

【0077】

Ｓ１５６段階で、サービスレジストリ１６０は前記サービス情報をサービスディスカバリ１７０に伝達する。

【0078】

Ｓ１５８段階で、サービスディスカバリ１７０が伝達を受けた情報はＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージから派生したものであるので、サービスディスカバリ１７０はＳＯＭＥ／ＩＰ ＳＤ ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージを生成する。

【0079】

Ｓ１６０段階で、サービスディスカバリ１７０は前記メッセージをＳＤマルチキャストポート１７２を通じてイーサネットマルチキャストに送信する。

【0080】

Ｓ１６２段階で、サービスディスカバリ１７０は該当するサービスのインスタンスを中断する。

【0081】

図３ｃは、本発明の一実施例に係るＣＭ１５０のＩＰＣポート１５２にサービスディスカバリメッセージのうちＦｉｎｄＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【0082】

Ｓ１７０段階で、ＦｉｎｄＳｅｒｖｉｃｅメッセージはサービスディスカバリメッセージであるので、ＩＰＣポート１５２はこのメッセージをサービスレジストリ１６０に伝達する。

【0083】

Ｓ１７２段階で、サービスレジストリ１６０はＦｉｎｄＳｅｒｖｉｃｅメッセージに関するサービス情報が登録されているかどうかを確認する。

【0084】

Ｓ１７４段階で、ＦｉｎｄＳｅｒｖｉｃｅメッセージに関するサービス情報がすでにサービスレジストリ１６０に登録されていれば、このサービスを登録せずに無視する。もしＦｉｎｄＳｅｒｖｉｃｅメッセージに関するサービス情報がサービスレジストリ１６０に登録されていなければ、Ｓ１７６段階を遂行する。

【0085】

Ｓ１７６段階で、サービスレジストリ１６０はＦｉｎｄＳｅｒｖｉｃｅメッセージに関するサービス情報を登録する。検索対象サービスのインスタンス明示子、サービスＩＤ、要求インスタンスＩＤ、要求バージョン情報、アプリケーションのネットワークエンドポイント情報をテーブルのタプルとして登録する。

【0086】

Ｓ１７８段階で、サービスレジストリ１６０は前記登録されたサービス情報の類型を判断して、ＩＰＣタイプであれば登録情報をサービスディスカバリ１７０に伝達しない。ＳＯＭＥ／ＩＰタイプであればＳ１８０段階を遂行する。

【0087】

Ｓ１８０段階で、サービスレジストリ１６０は登録情報をサービスディスカバリ１７０に伝達する。

【0088】

Ｓ１８２段階で、サービスディスカバリ１７０が伝達を受けた情報はＦｉｎｄＳｅｒｖｉｃｅメッセージから派生したものであるので、サービスディスカバリ１７０はＳＯＭＥ／ＩＰサービスディスカバリＦｉｎｄＳｅｒｖｉｃｅメッセージ（以下、ＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅメッセージ）を生成する。

【0089】

Ｓ１８４段階で、前記メッセージを処理するために、サービスディスカバリ１７０はＳＯＭＥ／ＩＰブリッジ１８０インスタンスを生成する。この時、サービスディスカバリ１７０はサービスレジストリ１６０から受けたネットワークエンドポイント情報をＳＯＭＥ／ＩＰブリッジ１８０に伝達する（Ｓ１８６）。

【0090】

Ｓ１８８段階で、ＳＯＭＥ／ＩＰブリッジ１８０は前記ネットワークエンドポイント情報に基づいてＰＯＳＩＸのイーサネットソケットであるＴＣＰポート１８２ａとＵＤＰポート１８２ｂをオープンする。この時、必要なネットワークエンドポイント情報はＳＯＭＥ／ＩＰ基盤のサービスインスタンスが使うＩＰアドレス、ポート番号、プロトコルの情報である。プロトコルはＴＣＰまたはＵＤＰのみ許容される。

【0091】

生成されたＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅメッセージの送信／待機は初期段階（ｉｎｉｔｉａｌ ｗａｉｔ ｐｈａｓｅ、Ｓ１９０）、繰り返し段階（ｒｅｐｅｔｉｔｉｏｎ ｐｈａｓｅ、Ｓ１９２）、主段階（ｍａｉｎ ｐｈａｓｅ、Ｓ１９４）に分かれて進行される。

【0092】

Ｓ１９０段階で、サービスディスカバリ１７０はサービスレジストリ１６０から伝達された情報に明示された時間の間待機した後、ＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅメッセージをＳＤマルチキャストポート１７２を通じて連結されたイーサネットマルチキャストに送信する。

【0093】

Ｓ１９２段階で、サービスディスカバリ１７０はサービスレジストリ１６０から伝達された情報に明示された時間の間待機した後、ＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅメッセージをＳＤマルチキャストポート１７２を通じて連結されたイーサネットマルチキャストに送信する。

【0094】

Ｓ１９４段階で、サービスディスカバリ１７０はＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅメッセージを送信せずに待機する。

【0095】

Ｓ１９６段階では、明示されたＴＴＬが満了したかどうかを確認して、満了していなければＳ１９４段階が引き続き進行される。もし明示されたＴＴＬが満了したのであればＳ１９８段階を遂行する。

【0096】

Ｓ１９８段階で、サービスディスカバリ１７０は該当するサービスのインスタンスを中断する。

【0097】

図４は本発明の一実施例に係るＣＭ１５０のＩＰＣポート１５２にサービスメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【0098】

Ｓ２１０段階で、ＩＰＣポート１５２は受信されたメッセージがサービスメッセージであればサービスＩＤがサービスレジストリ１６０にあるかどうかを検索する。

【0099】

Ｓ２２０段階で、サービスＩＤがサービスレジストリ１６０に存在するのであれば、ＳＯＭＥ／ＩＰブリッジ１８０が生成されているはずであるので、Ｓ２３０段階を遂行する。

【0100】

Ｓ２３０段階で、ＩＰＣポート１５２はサービスメッセージをＳＯＭＥ／ＩＰブリッジ１８０に伝達する。

【0101】

Ｓ２４０段階で、ＳＯＭＥ／ＩＰブリッジ１８０は伝達されたデータの前にＳＯＭＥ／ＩＰヘッダーを追加する。

【0102】

Ｓ２５０段階で、ＳＯＭＥ／ＩＰブリッジ１８０はＳＯＭＥ／ＩＰメッセージをＴＣＰポート１８２ａまたはＵＤＰポート１８２ｂに伝達し、前記ポートを通じて他のＥＣＵにＳＯＭＥ／ＩＰメッセージを送信する（Ｓ２６０）。

【0103】

図５ａは、本発明の一実施例に係るＣＭ１５０のＳＤマルチキャストポート１７２にＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【0104】

Ｓ３１０段階で、ＳＤマルチキャストポート１７２は連結されたイーサネットマルチキャストを通じて他のＥＣＵに送信するＳＯＭＥ／ＩＰサービスディスカバリメッセージ（以下ＳＯＭＥ／ＩＰ ＳＤメッセージ）を受信してサービスディスカバリ１７０に伝達する。

【0105】

Ｓ３１２段階で、サービスディスカバリ１７０は受信されたメッセージがＳＯＭＥ／ＩＰ ＳＤ ＯｆｆｅｒＳｅｒｖｉｃｅであればこのメッセージをサービスレジストリ１６０に伝達する。

【0106】

Ｓ３１４段階で、サービスレジストリ１６０は前記メッセージに関連したサービス情報が登録されているかどうかを確認する。

【0107】

Ｓ３１６段階で、前記メッセージに関連したサービス情報がサービスレジストリにすでに登録されていれば、このサービスを登録せずに無視する。もし登録されていなければＳ３１８段階を遂行する。

【0108】

Ｓ３１８段階で、サービスレジストリ１６０は前記メッセージに関連したサービス情報を新しく提供されるサービス情報として取り扱ってタプルを作って登録する。

【0109】

以上のＳ３１０～Ｓ３１８のメッセージ処理方法は、ＳＤマルチキャストポート１７２に入力されたメッセージがＳＯＭＥ／ＩＰ ＳＤ ＦｉｎｄＳｅｒｖｉｃｅの場合にも同様に適用される。

【0110】

図５ｂは、本発明の一実施例に係るＣＭ１５０のＳＤマルチキャストポート１７２にＳＯＭＥ／ＩＰ ＳＤ ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージが入力された場合の処理方法を説明するためのフローチャートである。

【0111】

Ｓ３３０段階で、ＳＤマルチキャストポート１７２は連結されたイーサネットマルチキャストを通じて他のＥＣＵに送信するＳＯＭＥ／ＩＰサービスディスカバリメッセージ（以下ＳＯＭＥ／ＩＰ ＳＤメッセージ）を受信してサービスディスカバリ１７０に伝達する。

【0112】

Ｓ３３２段階で、サービスディスカバリ１７０は受信されたメッセージがＳＯＭＥ／ＩＰ ＳＤ ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅであればこのメッセージをサービスレジストリ１６０に伝達する。

【0113】

Ｓ３３４段階で、サービスレジストリ１６０は前記メッセージに関連したサービス情報が登録されているかどうかを確認する。

【0114】

Ｓ３３６段階で、前記メッセージに関連したサービス情報がサービスレジストリに登録されていなければこの情報を無視する。もし登録されていればＳ３３８段階を遂行する。

【0115】

Ｓ３３８段階で、サービスレジストリ１６０は前記メッセージに関連した登録されたサービス情報タプルを除去する。

【0116】

図６は、本発明の一実施例に係るＣＭ１５０のサービスエンドポイントポート１８２にメッセージが入力された場合の処理方法を説明するためのフローチャートである。ＴＣＰポート１８２ａとＵＤＰポート１８２ｂはサービスエンドポイントポート１８２に該当する。

【0117】

Ｓ４１０段階で、サービスエンドポイントポート１８２は連結されたイーサネットを通じて他のＥＣＵのサービスインスタンスが送信したＳＯＭＥ／ＩＰメッセージを受信してＳＯＭＥ／ＩＰブリッジ１８０に伝達する。

【0118】

Ｓ４２０段階で、ＳＯＭＥ／ＩＰブリッジ１８０は受信したＳＯＭＥ／ＩＰメッセージがサービスレジストリ１６０に登録されたサービスにマッチングされるかどうかを検索する。前記メッセージがサービスレジストリ１６０に登録されたサービスにマッチングされる場合、Ｓ４３０段階を遂行する。

【0119】

Ｓ４３０段階で、サービスレジストリ１６０はマッチングされるサービスに該当するアプリケーションのエンドポイントアドレスをＳＯＭＥ／ＩＰブリッジ１８０に通報する。

【0120】

Ｓ４４０段階で、ＳＯＭＥ／ＩＰブリッジ１８０は受信したメッセージとアプリケーションのエンドポイントアドレスをＩＰＣポート１５２に伝達する。

【0121】

Ｓ４５０段階で、ＩＰＣポート１５２は自身と連結されているスケルトン１２０やプロキシ１４０に前記メッセージを送信する。

【0122】

図７は、本発明の一実施例に係るスケルトン１２０のサービス指向通信方法を説明するためのフローチャートである。サービスプロバイダインスタンスを初期化する「初期化」部分、サービス登録と検索が完了した後にサービスデータ通信を処理する「サービス提供」部分およびサービスプロバイダインスタンスの終了を遂行する「終了」部分に大別され得る。

【0123】

「初期化」部分はサービスインスタンスを初期化する部分である。

【0124】

Ｓ５１０段階で、サービスの設定ファイルであるマニフェスト（ｍａｎｉｆｅｓｔ）を解読する。これを通じて提供するサービスのＩＤ、インスタンスのＩＤ、サービスのバージョン、サービス情報の類型がＩＰＣであるかＳＯＭＥ／ＩＰであるかを把握することができる。

【0125】

Ｓ５１２段階で、ＣＭ１５０に伝達するＯｆｆｅｒＳｅｒｖｉｃｅメッセージを生成する。

【0126】

Ｓ５１４段階で、スケルトン１２０がＣＭ１５０と通信するエンドポイントを設定してオープンする。

【0127】

Ｓ５１６段階で、スケルトン１２０のサービスプロバイダポート１２２を通じてＯｆｆｅｒＳｅｒｖｉｃｅメッセージをＣＭ１５０に送信する。ＯｆｆｅｒＳｅｒｖｉｃｅメッセージはサービスディスカバリメッセージであって、アプリケーションがサービスを提供するという意味である。

【0128】

「サービス提供」部分は、ＣＭ１５０がサービス提供に関連したサービスレジストリ１６０、サービスディスカバリ１７０が初期化を完了すれば始まる。ただし、提供するサービスの情報の類型がＳＯＭＥ／ＩＰである場合、ＳＯＭＥ／ＩＰブリッジ１８０まで初期化を完了しないと始まらない。サービス提供部分ではＣＭ１５０からメッセージを受信してプロキシ１４０が要請したサービスを処理し、結果メッセージをＣＭ１５０に送信する作業が遂行される。

【0129】

Ｓ５３０段階で、ＣＭからサービスメッセージ（サービスを要請するメッセージ）を受信する。

【0130】

Ｓ５３２段階では受信したメッセージをパーシングする。

【0131】

Ｓ５３４段階で、受信したメッセージはパーシング結果により二つに区分される。最初はメソッド（サービスが提供する関数）を呼び出すＲｅｑｕｅｓｔメッセージであり、二番目はサービスが一方的に生成して送信するＥｖｅｎｔメッセージを購読しようとするＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージである。受信したメッセージがＲｅｑｕｅｓｔメッセージである場合はＳ５４０を遂行し、ＳｕｂｓｃｒｉｂｅＥｖｅｎｔＧｒｏｕｐメッセージである場合はＳ５５０を遂行する。

【0132】

Ｓ５４０段階で、受信したメッセージを逆直列化する。これを通じてメソッドが提供する機能を使うためのパラメータを分離する。

【0133】

Ｓ５４２段階で、前記パラメータを入力してメソッドを呼び出す。サービスを要請したプロキシ１４０に対する応答が要求される場合、呼び出されたメソッドはＲｅｓｐｏｎｓｅメッセージを生成する。

【0134】

Ｓ５４４段階で、生成されたＲｅｓｐｏｎｓｅメッセージを直列化する。

【0135】

Ｓ５４６段階で、前記直列化されたＲｅｓｐｏｎｓｅメッセージはスケルトン１２０のサービスプロバイダポート１２２を通じてＣＭ１５０に送信される。

【0136】

Ｓ５５０段階で、購読者レジストリ（ｓｕｂｓｃｒｉｂｅｒ ｒｅｇｉｓｔｒｙ）にメッセージの内容を登録する。登録される内容はサービスが提供するＥｖｅｎｔメッセージを受信できる購読者（ｓｕｂｓｃｒｉｂｅｒ）の情報である。

【0137】

Ｓ５５２段階で、Ｅｖｅｎｔメッセージを送信できるかどうかを判断し、Ｅｖｅｎｔメッセージを送信できればＳ５５４段階を遂行し、Ｅｖｅｎｔメッセージを送信できなければＳ５６４段階を遂行する。

【0138】

Ｓ５５４段階で、サービスディスカバリメッセージであるＳｕｂｓｃｒｉｂｅＥｖｅｎｔｇｒｏｕｐＡｃｋメッセージを送信する。

【0139】

Ｓ５５６段階で、購読者にＥｖｅｎｔメッセージを送信できる条件が到来したかどうかを確認する。前記条件が到来すればＳ５５８段階を進行する。

【0140】

Ｓ５５８段階で、Ｅｖｅｎｔメッセージを生成する。Ｅｖｅｎｔメッセージはユーザ（ｕｓｅｒ）が具現したデータを含むことができる。ユーザ（ｕｓｅｒ）は本発明の装置（例えばマシン）を利用する主体を指し、以後にも同じ意味で解釈されるべきである。

【0141】

Ｓ５６０段階で、前記Ｅｖｅｎｔメッセージを直列化する。

【0142】

Ｓ５６２段階で、前記直列化されたＥｖｅｎｔメッセージをスケルトン１２０のサービスプロバイダポート１２２を通じてＣＭ１５０に送信する。

【0143】

Ｓ５６４段階で、サービスディスカバリメッセージであるＳｕｂｓｃｒｉｂｅＥｖｅｎｔｇｒｏｕｐＮａｃｋメッセージを送信し、該当購読者にＥｖｅｎｔメッセージをそれ以上送信しない。

【0144】

「終了」部分は、サービスインスタンスを終了する部分である。

【0145】

Ｓ５７０段階で、サービスインスタンスを終了する条件が満たされる場合、ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージを生成する。ＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージはサービスディスカバリメッセージであって、サービスの提供を終了するという意味である。

【0146】

Ｓ５７２段階で、スケルトン１２０のサービスプロバイダポート１２２を通じてＳｔｏｐＯｆｆｅｒＳｅｒｖｉｃｅメッセージをＣＭ１５０に送信する。

【0147】

図８は、本発明の一実施例に係るプロキシ１４０サービス指向通信方法を説明するためのフローチャートである。サービスコンシューマインスタンスを初期化する「初期化」部分、サービス検索が完了した後にサービスデータ通信を処理する「サービス使用」部分およびサービスコンシューマインスタンスの終了を遂行する「終了」部分に大別され得る。

【0148】

「初期化」部分は、サービスインスタンスを初期化する部分である。

【0149】

Ｓ６１０段階で、サービスの設定ファイルであるマニフェスト（ｍａｎｉｆｅｓｔ）を解読する。これを通じて検索するサービスのＩＤ、要求するインスタンスのＩＤ、要求するサービスのバージョン、サービス情報の類型がＩＰＣであるかＳＯＭＥ／ＩＰであるかを把握することができる。

【0150】

Ｓ６１２段階で、ＣＭ１５０に伝達するＦｉｎｄＳｅｒｖｉｃｅメッセージを生成する。

【0151】

Ｓ６１４段階で、プロキシ１４０がＣＭ１５０と通信するエンドポイントを設定してオープンする。

【0152】

Ｓ６１６段階で、プロキシ１４０のサービスコンシューマポート１４２を通じてＦｉｎｄＳｅｒｖｉｃｅメッセージをＣＭ１５０に送信する。ＦｉｎｄＳｅｒｖｉｃｅメッセージはサービスディスカバリメッセージであって、アプリケーションが使おうとするサービスが提供中であるかどうかを検索するという意味である。ＦｉｎｄＳｅｒｖｉｃｅメッセージをＣＭ１５０に送信した以後、ＣＭ１５０から応答がくるまで待機する。

【0153】

ＣＭ１５０から応答（検索結果）を受信すれば（Ｓ６１８）、Ｓ６２０段階でプロキシハンドラ（ｐｒｏｘｙ ｈａｎｄｌｅｒ）は現在使用可能なサービスのリストを整理した後、アプリケーションにサービスの検索の有無と検索されたサービスの項目を伝達する。

【0154】

Ｓ６２２段階で、アプリケーションは使用可能なサービスのうち一つを選択する。

【0155】

「サービス使用」部分は、ＣＭ１５０でのサービス検索とプロキシ１４０とＣＭ１５０との連結が完了した状態でサービスレジストリ１６０、サービスディスカバリ１７０が初期化を完了すれば始まる。ただし、プロキシ１４０が使うサービスの類型がＳＯＭＥ／ＩＰの場合、ＳＯＭＥ／ＩＰブリッジ１８０まで初期化を完了しないと始まらない。「サービス使用」部分ではＣＭ１５０にプロキシ１４０が必要なサービスを要請するメッセージを送信し、ＣＭ１５０から結果メッセージを受信して処理する作業が遂行される。

【0156】

Ｓ６３０段階では、プロキシ１４０がサービスの提供を受ける方法によってＳ６４０段階やＳ６５０段階に分岐する。プロキシ１４０はメソッド呼び出し元（ｍｅｔｈｏｄ ｃａｌｌｅｒ）を通じてＣＭ１５０を経由してスケルトン１２０のメソッドを使うが、二つの方法がある。（１）スケルトン１２０のメソッドを明示して該当メソッドを呼び出す方法と（２）スケルトン１２０の特定イベントに対して購読する方法である。（１）、（２）の選択はユーザ（ｕｓｅｒ）がアプリケーションに具現したロジックに従う。（１）を選択する場合はＳ６４０段階が遂行され、（２）を選択する場合はＳ６５０段階が遂行される。

【0157】

Ｓ６４０段階で、メソッド呼び出し元を通じて呼び出すメソッドの入力パラメータを含ませてＲｅｑｕｅｓｔメッセージを生成する。

【0158】

Ｓ６４２段階で、生成した前記Ｒｅｑｕｅｓｔメッセージを直列化する。

【0159】

Ｓ６４４段階で、前記直列化されたＲｅｑｕｅｓｔメッセージをプロキシ１４０のサービスコンシューマポートを通じてＣＭ１５０に送信する。送信後、メソッド呼び出し元はＣＭからＲｅｓｐｏｎｓｅメッセージが受信されるまで待機する。

【0160】

Ｓ６５０段階で、イベント購読者（ｅｖｅｎｔ ｓｕｂｓｃｒｉｂｅｒ）を通じて購読しようとするイベントを指定してサービスディスカバリメッセージであるＳｕｂｓｃｒｉｂｅＥｖｅｎｔｇｒｏｕｐメッセージを生成する。

【0161】

Ｓ６５２段階で、前記メッセージをプロキシ１４０のサービスコンシューマポート１４２を通じてＣＭ１５０に送信する。

【0162】

Ｓ６６０段階で、ＣＭからサービスメッセージを受信する。

【0163】

Ｓ６６２段階で、受信したメッセージをパーシングする。

【0164】

Ｓ６６４段階で、パーシングしたメッセージを二つに区分してそれにより分岐する。最初は以前にプロキシ１４０でメソッドに対するリクエストメッセージを送信し、メソッド実行結果であるＲｅｓｐｏｎｓｅメッセージを受信する場合である。二番目は購読が設定されたイベントのＥｖｅｎｔメッセージを受信する場合である。最初の場合はＳ６７０を遂行し、二番目の場合はＳ６８０を遂行する。

【0165】

Ｓ６７０段階で、Ｒｅｓｐｏｎｓｅメッセージを待機中であるメソッド呼び出し元に伝達する。

【0166】

Ｓ６７２段階で、メソッド呼び出し元はプロキシ１４０のユーザ具現部分に結果を伝達する。

【0167】

Ｓ６８０段階で、イベントバッファ（ｅｖｅｎｔ ｂｕｆｆｅｒ）にＥｖｅｎｔメッセージをそのまま保存する。

【0168】

Ｓ６８２段階では保存されたＥｖｅｎｔメッセージを使う。前記Ｅｖｅｎｔメッセージは次の二つの方式でプロキシ１４０で使われ得る。最初はプロキシ１４０の具現者が特定時点でイベントバッファに保存されたＥｖｅｎｔメッセージを抽出して使うことである。イベントバッファは先入先出のデータ構造を有し、Ｅｖｅｎｔメッセージを抽出すれば空きとなる。二番目はプロキシ１４０の具現者がコールバック関数をバインドすることである。このようにすれば、イベントバッファにＥｖｅｎｔメッセージが保存されるたびにバインドされたコールバック関数が呼び出され、具現者はこの時点で保存されたイベントメッセージの抽出の有無を決定することができる。

【0169】

「終了」部分は、サービスインスタンスを終了する部分である。

【0170】

Ｓ６９０段階で、サービスインスタンスを終了する条件が満たされる場合、ＳｔｏｐＦｉｎｄＳｅｒｖｉｃｅメッセージを生成する。ＳｔｏｐＦｉｎｄＳｅｒｖｉｃｅメッセージはプロキシ１４０がサービス使用を中断するという意味である。

【0171】

Ｓ６９２段階で、プロキシ１４０のサービスコンシューマポート１４２を通じてＳｔｏｐＦｉｎｄＳｅｒｖｉｃｅメッセージをＣＭ１５０に送信する。ＣＭ１５０がＳｔｏｐＦｉｎｄＳｅｒｖｉｃｅメッセージを受信すれば、サービスレジストリ１６０、サービスディスカバリ１７０およびＳＯＭＥ／ＩＰブリッジ１８０（ＳＯＭＥ／ＩＰサービスの場合）に登録されて活性化された関連情報およびインスタンスを解除する。

【0172】

因みに、本発明の実施例に係る構成要素はソフトウェアまたはＦＰＧＡ（Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙ）またはＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）のようなハードウェアの形態で具現され得、所定の役割を遂行できる。

【0173】

しかし、「構成要素」はソフトウェアまたはハードウェアに限定される意味ではなく、各構成要素はアドレッシングできる保存媒体にあるように構成されてもよく、一つまたはそれ以上のプロセッサを再生させるように構成されてもよい。

【0174】

したがって、一例として構成要素はソフトウェア構成要素、オブジェクト指向ソフトウェア構成要素、クラス構成要素およびタスク構成要素のような構成要素と、プロセス、関数、属性、プロシージャ、サブルーチン、プログラムコードのセグメント、ドライバ、ファームウェア、マイクロコード、回路、データ、データベース、データ構造、テーブル、アレイおよび変数を含む。

【0175】

構成要素と該当構成要素内で提供される機能は、さらに小さい数の構成要素で結合されたり追加的な構成要素にさらに分離され得る。

【0176】

この時、処理フローチャート図面の各ブロックとフローチャート図面の組み合わせは、コンピュータプログラムのインストラクションによって遂行され得ることが理解できるであろう。これらコンピュータプログラムのインストラクションは汎用コンピュータ、特殊用コンピュータまたはその他のプログラム可能なデータプロセシング装備のプロセッサに搭載され得るので、コンピュータまたはその他プログラム可能なデータプロセシング装備のプロセッサを通じて遂行されるそのインストラクションが１つまたは複数のフローチャートブロックで説明された機能を遂行する手段を生成することになる。これらコンピュータプログラムインストラクションは特定の方式で機能を具現するために、コンピュータまたはその他プログラム可能なデータプロセシング装備を指向できるコンピュータを利用するか、またはコンピュータ読み取り可能メモリに保存されることも可能であるのでそのコンピュータを利用するか、コンピュータ読み取り可能メモリに保存されたインストラクションは１つまたは複数のフローチャートブロックで説明された機能を遂行するインストラクション手段を内包する製造品目を生産することも可能である。コンピュータプログラムインストラクションはコンピュータまたはその他プログラム可能なデータプロセシング装備上に搭載されることも可能であるので、コンピュータまたはその他プログラム可能なデータプロセシング装備上で一連の動作段階が遂行されてコンピュータで実行されるプロセスを生成して、コンピュータまたはその他プログラム可能なデータプロセシング装備を遂行するインストラクションは、１つまたは複数のフローチャートブロックで説明された機能を実行するための段階を提供することも可能である。

【0177】

また、各ブロックは特定された１つまたは複数の論理的機能を実行するための一つ以上の実行可能なインストラクションを含むモジュール、セグメントまたはコードの一部を表しうる。また、いくつかの代替実行例では、ブロックで言及された機能が異なる順序で発生することも可能であることにも留意されたい。例えば、連続して図示されている二つのブロックは実質的に同時に遂行されてもよく、またはそのブロックが時々該当する機能により逆順で遂行されてもよい。

【0178】

前述したＣＭ１５０のポートにメッセージが入力された場合の処理方法、スケルトン１２０のサービス指向通信方法およびプロキシ１４０のサービス指向通信方法は、図面に提示されたフローチャートを参照して説明された。簡単に説明するために前記方法は一連のブロックで図示されて説明されたが、本発明は前記ブロックの順序に限定されず、いくつかのブロックは他のブロックと本明細書で図示され記述されたものと異なる順序でまたは同時に起きることもあり、同一または類似する結果を達成する多様な他の分岐、流れの経路、およびブロックの順序で具現され得る。また、本明細書で記述される方法の具現のために図示されたすべてのブロックが要求されない場合もある。

【0179】

以上、本発明の構成について添付図面を参照して詳細に説明したが、これは例示に過ぎず、本発明が属する技術分野の通常の知識を有する者であれば、本発明の技術的思想の範囲内で多様な変形と変更が可能であることは言うまでもない。したがって、本発明の保護範囲は前述した実施例に限定されてはならず、以下の特許請求の範囲の記載によって定められるべきである。

【図1】

【図2】

【図3a】

【図3b】

【図3c】

【図4】

【図5a】

【図5b】

【図6】

【図7】

【図8】

【国際調査報告】