情報処理装置、プラグイン連携方法、プラグイン連携プログラム、及びそのプログラムを記録した記録媒体
【課題】プラグインが有するＵＩ部とロジック部との独立性を保ち、プラグイン間の連携動作が可能な情報処理装置、プラグイン連携方法、プラグイン連携プログラム、及びそのプログラムを記録した記録媒体を提供する。
【解決手段】情報処理装置１００は、複数のプラグインＰを有するアプリケーションＡＰが動作する装置であって、プラグインＰが、プラグインＰの表示画面を生成するＵＩ（User Interface）部２０と、プラグインＰの機能を実現するための処理を行うロジック部１０と、を有し、プラグイン間において、連携元のプラグインＰ１が、ＵＩ部２０１により、連携先のプラグインＰ２のＵＩ部２０２に対して、ロジック部１０１による処理結果を通知し、連携先のプラグインＰ２が、ＵＩ部２０２により、通知手段２１１１が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成することを特徴とする。
【解決手段】情報処理装置１００は、複数のプラグインＰを有するアプリケーションＡＰが動作する装置であって、プラグインＰが、プラグインＰの表示画面を生成するＵＩ（User Interface）部２０と、プラグインＰの機能を実現するための処理を行うロジック部１０と、を有し、プラグイン間において、連携元のプラグインＰ１が、ＵＩ部２０１により、連携先のプラグインＰ２のＵＩ部２０２に対して、ロジック部１０１による処理結果を通知し、連携先のプラグインＰ２が、ＵＩ部２０２により、通知手段２１１１が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成することを特徴とする。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、情報処理装置に関し、特に、複数のプラグインを有するアプリケーションにおいて、プラグインが画面遷移し、連携動作する技術に関するものである。
【背景技術】
【０００２】
例えば、特許文献１には、プラグインごとの操作画面のカスタマイズ効率を高めることを目的とした表示画面カスタマイズプログラムに関する技術が開示されている。その中で、表示画面カスタマイズプログラムは、各プラグイン共通の画面構成情報と画面カスタマイズ情報を有し、これらの情報に基づき、各プラグインの表示画面を生成する。つまり、特許文献１に開示される技術では、表示画面の生成機能を複数のプラグインに対して共通化することで、プラグインごとの表示画面を統一し、カスタマイズ効率の向上を実現している。しかし、本来であれば、このようなプラグインの表示画面は、提供機能の利便性や利用者の操作性を考慮し、プラグインごとでカスタマイズしたい。
【０００３】
また、近年のプラグインは、迅速な機能提供や優れた拡張性を実現するために、他の開発部署や他のソフトウェアベンダーと言った複数の異なる組織により開発・提供される場合が多い。このような環境下では、開発を行った組織単位で、プラグインの表示画面をカスタマイズした方が、利便性や操作性を考慮したＵＩ（User Interface）の提供を実現するだけでなく、開発効率の面でも効果的である。
【０００４】
そこで、プラグインのソフトウェア構成には、プラグインの開発効率や表示画面のカスタマイズ性を考慮し、表示画面を生成するＵＩ部と、機能を実現するための処理を実行するロジック部と、を有する構成が考えられる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のプラグインには、他のプラグインと連携する際に次のような問題がある。従来のプラグインでは、ロジック部によりＵＩ部の画面表示を制御している。そのため、プラグイン連携時の画面遷移が、連携プラグインの各ロジック部により制御される。例えば、プラグインＡとプラグインＢとが連携動作し、プラグインＡの表示画面からプラグインＢの表示画面へと遷移する場合を例に説明する。まず、プラグインＡのロジック部がプラグインＡのＵＩ部から受け付けた利用者からの動作指示に従って所定の処理を実行する。その処理結果は、プラグインＡのロジック部からプラグインＢのロジック部へと通知され、画面遷移が指示される。プラグインＢのロジック部は、通知された処理結果を基にプラグインＢのＵＩ部へ画面表示を指示する。これにより、プラグインＡの表示画面からプラグインＢの表示画面へと遷移する。
【０００６】
上記動作例からも分かるように、従来のプラグインでは、動作連携時の画面遷移制御をロジック部が行っているため、ロジック部とＵＩ部との独立性が保たれない構成となってしまう。また、従来のプラグインでは、ロジック部が実現する機能をプラグイン間で共通化したい場合であっても、画面遷移制御までは共通化できないため、異なるロジック部に同一機能が重複して存在することになる。
【０００７】
このように、従来のプラグインでは、ソフトウェアの開発・保守を困難なものとし、リソースを無駄に消費してしまう可能性があった。
【０００８】
本発明は上記従来技術の問題点を鑑み提案されたものであり、その目的とするところは、プラグインが有するＵＩ部とロジック部との独立性を保ち、プラグイン間の連携動作が可能な情報処理装置、プラグイン連携方法、プラグイン連携プログラム、及びそのプログラムを記録した記録媒体を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明に係る情報処理装置は、複数のプラグインを有するアプリケーションが動作する情報処理装置であって、前記プラグインが、プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有し、前記ＵＩ部が、同プラグインのロジック部による処理結果を他のプラグインに通知する通知手段、及び／又は前記処理結果を他のプラグインから受信する受信手段、を有し、プラグイン間において、連携元のプラグインが、前記通知手段により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、前記連携先のプラグインが、前記受信手段により、前記通知手段が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインのＵＩ部により表示画面を生成することを特徴とする。
【００１０】
このような構成によって、本発明に係る情報処理装置は、連携元のプラグインのＵＩ部から連携先のプラグインのＵＩ部に対してロジック部の処理結果を通知し、遷移後の画面表示を指示する。
【００１１】
これによって、本発明に係る情報処理装置では、ロジック部でなくＵＩ部により、プラグイン連携時の画面遷移が制御され、ロジック部による処理結果がＵＩ部を介して連携先へと伝達される。その結果、プラグインが有するロジック部とＵＩ部との独立性が保たれた構成でプラグイン間の連携動作が行える。
【００１２】
上記目的を達成するため、本発明に係るプラグイン連携方法は、プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有する複数のプラグインで構成されるアプリケーションが動作する情報処理装置におけるプラグイン連携方法であって、プラグイン間において、連携元のプラグインが、同プラグインのＵＩ部により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、前記連携先のプラグインが、同プラグインのＵＩ部により、前記連携元のプラグインが通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成することを特徴とする。
【００１３】
このような手順によって、本発明に係るプラグイン連携方法では、連携元のプラグインのＵＩ部から連携先のプラグインのＵＩ部に対してロジック部の処理結果を通知し、遷移後の画面表示を指示すると言う動作を実現する。
【００１４】
これによって、本発明に係るプラグイン連携方法は、プラグインが有するＵＩ部とロジック部との独立性を保ち、プラグイン間の連携動作が可能な環境を提供できる。
【発明の効果】
【００１５】
本発明によれば、プラグインが有するＵＩ部により、プラグイン連携時の画面遷移を制御し、ロジック部による処理結果をＵＩ部が連携先へと伝達することで、ロジック部とＵＩ部との独立性を保ち、プラグイン間の連携動作が可能な情報処理装置、プラグイン連携方法、プラグイン連携プログラム、及びそのプログラムを記録した記録媒体を提供することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態に係る情報処理装置のハードウェア構成例を示す図である。
【図２】アプリケーションのソフトウェア構成例を示す図である。
【図３】従来のプラグイン連携の処理手順例を示すシーケンス図である。
【図４】従来のプラグイン連携を行うソフトウェア構成例を示す図である。
【図５】本発明の第１の実施形態に係るプラグイン連携を行うソフトウェア構成例を示す図である。
【図６】本発明の第１の実施形態に係るプラグイン連携の処理手順例を示すシーケンス図である。
【図７】本発明の第１の実施形態に係る情報処理装置が有する機能構成例を示す図である。
【図８】本発明の第１の実施形態に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。
【図９】本発明の変形例に係るプラグイン連携の動作例を示す図である。
【図１０】本発明の変形例に係る情報処理装置が有する機能構成例を示す図である。
【図１１】本発明の変形例に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。
【発明を実施するための形態】
【００１７】
以下、本発明の好適な実施の形態（以下「実施形態」と言う）について、図面を用いて詳細に説明する。
【００１８】
［第１の実施形態］
＜ハードウェア構成＞
本実施形態に係る情報処理装置のハードウェア構成について説明する。
図１は、本実施形態に係る情報処理装置１００のハードウェア構成例を示す図である。
図１に示すように、情報処理装置１００は、入力装置１０１、表示装置１０２、ドライブ装置１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、インタフェース装置１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
【００１９】
入力装置１０１は、キーボード及びマウスなどを含み、情報処理装置１００に各操作信号を入力するのに用いられる。表示装置１０２は、ディスプレイなどを含み、情報処理装置１００による処理結果を表示する。
【００２０】
インタフェース装置１０７は、情報処理装置１００を所定のデータ伝送路（例えば「ＬＡＮ：Local Area Network」）に接続するインタフェースである。よって、情報処理装置１００は、インタフェース装置１０７を介して、接続される周辺機器２００（例えば「プリンタ」や「ＰＣ：Personal Computer」）とデータ通信を行うことができる。
【００２１】
ＨＤＤ１０８は、各種プログラム及びデータを格納している不揮発性の記憶装置である。格納されるプログラム及びデータには、例えば、情報処理装置１００全体を制御する情報処理システム（「Ｗｉｎｄｏｗｓ（登録商標）」や「ＵＮＩＸ（登録商標）」などの基本ソフトウェアであるＯＳ：Operating System）、及び情報処理システム上において各種機能を提供するアプリケーションなどがある。また、ＨＤＤ１０８は、格納している上記プログラム及びデータを、所定のファイルシステム及び／又はＤＢ（Data Base）により管理している。
【００２２】
ドライブ装置１０３は、着脱可能な記録媒体１０３ａとのインタフェースである。これにより、情報処理装置１００は、ドライブ装置１０３を介して、記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。
【００２３】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、情報処理装置１００が起動されるときに実行されるＢＩＯＳ（Basic Input/Output System）や、情報処理装置１００のシステム設定及びネットワーク関連設定などのデータが格納されている。
【００２４】
ＲＡＭ１０４は、上記各種記憶装置から読み出されたプログラム及びデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、ＲＯＭ１０５やＨＤＤ１０８からＲＡＭ１０４上に読み出したプログラムを実行することにより、情報処理装置１００の全体制御及び各種搭載機能の動作を実現する。
【００２５】
情報処理装置１００では、上記ハードウェア構成により、情報処理サービス（情報処理機能）を提供することができる。
【００２６】
また、情報処理装置１００は、上記ハードウェア構成からも分かるようにＰＣ（Personal Computer）などと略同一の構成をしている。
【００２７】
＜ソフトウェア構成＞
次に、上記情報処理装置１００に搭載される（インストールされる）アプリケーションのソフトウェア構成について説明する。
図２は、アプリケーションＡＰのソフトウェア構成例を示す図である。
図２に示すように、アプリケーションＡＰは、複数のプラグインＰ１〜Ｐｎ（以下総称する場合は「プラグインＰ」と言う）と、プラグインＰの動作環境であるプラットフォームＰＦとを有する構成となっている。つまり、アプリケーションＡＰの機能は、各プラグインＰ１〜ＰｎがプラットフォームＰＦ上で連携動作することで実現・提供される。このようなソフトウェア構成とするメリットには、開発効率の向上や独立した開発部品（ソフトウェア部品）による迅速な機能提供、また優れた拡張性の実現などが挙げられる。
【００２８】
さらに、各プラグインＰ１〜Ｐｎは、各機能を実現するための処理を行うプラグインロジック（以下単に「ロジック部」と言う）１０１〜１０ｎ（以下総称する場合は「ロジック部１０」と言う）と、各表示画面を生成するプラグインＵＩ（以下単に「ＵＩ部」と言う）２０１〜２０ｎ（以下総称する場合は「ＵＩ部２０」と言う）とを有する構成となっている。このようなソフトウェア構成とするメリットには、プラグインＰの開発効率や表示画面のカスタマイズ性の向上がなど挙げられる。
【００２９】
また、ロジック部１０とＵＩ部２０との関係は、次の通りである。例えば、ロジック部１０１とＵＩ部２０１とは、同じプラグイン（同プラグイン）に属するソフトウェア部品である。一方、ロジック部１０２とＵＩ部２０１とは、異なるプラグインに属するソフトウェア部品である。つまり、ＵＩ部２０１から見たロジック部１０２は、他のプラグインに属するソフトウェア部品と言うことになる。この点については、ロジック部同士であってもＵＩ部同士であっても同じことが言える。よって、上記ソフトウェア構成におけるプラグイン連携とは、異なるプラグインＰに属するソフトウェア部品同士が連携することを意味する。
【００３０】
このようなソフトウェア構成において、従来のアプリケーションＡＰでは、画面遷移制御部１１１〜１１ｎ（以下総称する場合は「画面遷移制御部１１」と言う）を、プラグインＰのロジック部１０が有している。
【００３１】
＜プラグイン連携機能＞
まず、従来のアプリケーションＡＰにおけるプラグイン連携動作について説明する。
図３は、従来のプラグイン連携の処理手順例を示すシーケンス図である。図３には、４つのプラグインＰ１〜Ｐ４を有するアプリケーションＡＰにおけるプラグイン連携の処理手順例が示されている。また、このアプリケーションＡＰでは、プラグインＰ１からプラグインＰ２への画面遷移、プラグインＰ３からプラグインＰ４への画面遷移において、利用者認証が必要となる。このようなアプリケーションＡＰを搭載した情報処理装置１００では、アプリケーションＡＰ内のプラグイン連携が次のように行われる。
【００３２】
図３に示すように、まず、情報処理装置１００では、プラグインＰ１のロジック部１０１からＵＩ部２０１に対して、画面表示が指示される（ステップＳ１１）。その結果、表示装置１０２には、プラグインＰ１の操作画面（認証画面：画面１）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報（例えば「ユーザＩＤ」や「パスワード」）がＵＩ部２０１からロジック部１０１へと渡される。
【００３３】
情報処理装置１００では、ロジック部１０１により、認証情報に基づく利用者認証処理が行われ（ステップＳ１２）、その認証結果が、連携先であるプラグインＰ２のロジック部１０２へと通知され、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される（ステップＳ１３）。
【００３４】
続いて、情報処理装置１００では、プラグインＰ２のロジック部１０２からＵＩ部２０２に対して、画面表示が指示される（ステップＳ１４）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ２の操作画面（画面２）が表示される。情報処理装置１００では、利用者入力で受け付けた操作情報（例えば「次処理指定」）がＵＩ部２０２からロジック部１０２へと渡される。
【００３５】
情報処理装置１００では、ロジック部１０２により、必要に応じて所定の処理が行われ、その処理結果が、連携先であるプラグインＰ３のロジック部１０３へと通知され、プラグインＰ２からプラグインＰ３へと画面遷移（画面２→３）が指示される（ステップＳ１５）。
【００３６】
続いて、情報処理装置１００では、プラグインＰ３のロジック部１０３からＵＩ部２０３に対して、画面表示が指示される（ステップＳ１６）。その結果、表示装置１０２には、プラグインＰ３の操作画面（認証画面：画面３）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報がＵＩ部２０３からロジック部１０３へと渡される。
【００３７】
情報処理装置１００では、ロジック部１０３により、認証情報に基づく利用者認証処理が行われ（ステップＳ１７）、その認証結果が、連携先であるプラグインＰ４のロジック部１０４へと通知され、プラグインＰ３からプラグインＰ４へと画面遷移（画面３→４）が指示される（ステップＳ１８）。
【００３８】
続いて、情報処理装置１００では、プラグインＰ４のロジック部１０４からＵＩ部２０４に対して、画面表示が指示される（ステップＳ１９）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ４の操作画面（画面４）が表示される。
【００３９】
このように、従来のアプリケーションＡＰでは、プラグイン連携処理を行う場合、図４に示すようなソフトウェア構成となってしまう。
【００４０】
図４は、従来のプラグイン連携を行うソフトウェア構成例を示す図である。
図４に示すように、各プラグインＰ１〜Ｐ４が有するロジック部１０１〜１０４は、連携先への画面遷移を制御する画面遷移制御部１１１〜１１４を個々に有している。そのため、プラグインＰでは、ＵＩ部２０とロジック部１０との独立性が保たれず、連携先の変更を行う場合、ロジック部担当の開発者に必要以上の技術を要求することになる。つまり、ロジック部担当の開発者には、機能実現処理以外の画面処理に関する技術の理解も必要とされる。これは、開発者にとって煩雑であり、作業分担による高い開発効率を実現する上で弊害となる。
【００４１】
また、プラグインＰ１及びＰ３が有するロジック部１０１及び１０３は、利用者認証を行う同一の機能（認証部１２１及び１２３）を有している。これは、ロジック部１０１及び１０３が画面遷移制御部１１１及び１１３を有しているため、画面遷移制御部１１１及び１１３の動作時に利用者認証を行わなければならないからである。そのため、プラグインＰのロジック部１０では、共通化可能な機能が重複してしまい、無駄なリソースを消費することになる。また、ロジック部担当の開発者には、煩雑なソフトウェア開発・保守を強いることになる。
【００４２】
このように、従来のプラグインＰでは、ソフトウェアの開発・保守を困難なものとし、リソースを無駄に消費してしまう可能性があった。
【００４３】
そこで、本実施形態に係る情報処理装置１００では、連携元のプラグインＰ１のＵＩ部２０１から連携先のプラグインＰ２のＵＩ部２０２に対してロジック部１０１の処理結果を通知し、遷移後の画面表示を指示する。情報処理装置１００は、このようなプラグイン連携機能を有している。
【００４４】
図５は、本実施形態に係るプラグイン連携を行うソフトウェア構成例を示すである。図５には、上記に説明を行った図３と同じプラグイン連携を行う本実施形態に係るアプリケーションＡＰのソフトウェア構成例が示されている。
【００４５】
本実施形態に係るアプリケーションＡＰは、図４に示した従来のソフトウェア構成と次の点で異なる。本実施形態に係るアプリケーションＡＰでは、プラグインＰ１〜Ｐ４のロジック部１０１〜１０４ではなく、ＵＩ部２０１〜２０４が、連携時の画面遷移を制御する機能部（画面遷移制御部２１１〜２１４）を有している点である。これにより、プラグインＰでは、ロジック部１０とＵＩ部２０との独立性が保たれ、画面処理に関する技術に精通したＵＩ部担当の開発者による対応が可能となり、開発・保守作業の分担が明確となる。
【００４６】
また、プラグインＰ１及びＰ３のロジック部１０１及び１０３が有していた重複機能（認証部１２１及び１２３）を、１つの機能に共通化（プラグイン化）している点である。この機能の共通化は、上記構成（ＵＩ部が画面遷移機能を有する構成）としたことで、ロジック部１０の独立性が確保されたことによるものである。
【００４７】
以下に、本実施形態に係るアプリケーションＡＰにおけるプラグイン連携の処理手順例を示す。
【００４８】
図６は、本実施形態に係るプラグイン連携の処理手順例を示すシーケンス図である。
図６に示すように、情報処理装置１００では、プラグインＰ１のＵＩ部２０１により、表示画面が生成される（ステップＳ２１）。その結果、表示装置１０２には、プラグインＰ１の操作画面（認証画面：画面１）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報が、ＵＩ部２０１から共通化された認証プラグインＰａのロジック部１０ａへと渡される（ステップＳ２２）。
【００４９】
情報処理装置１００では、認証プラグインＰａのロジック部１０ａにより、認証情報に基づく利用者認証処理が行われ（ステップＳ２３）、その認証結果が、プラグインＰ１のＵＩ部２０１へと通知される。情報処理装置１００では、認証結果が、プラグインＰ１のＵＩ部２０１から連携先であるプラグインＰ２のＵＩ部２０２へと渡され、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される（ステップＳ２４）。
【００５０】
続いて、情報処理装置１００では、プラグインＰ２のＵＩ部２０２により、表示画面が生成される（ステップＳ２５）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ２の操作画面（画面２）が表示される。情報処理装置１００では、利用者入力で受け付けた操作情報が、プラグインＰ２のＵＩ部２０２から連携先であるプラグインＰ３のＵＩ部２０３へと渡され、プラグインＰ２からプラグインＰ３へと画面遷移（画面２→３）が指示される（ステップＳ２６）。
【００５１】
続いて、情報処理装置１００では、プラグインＰ３のＵＩ部２０３により、表示画面が生成される（ステップＳ２７）。その結果、表示装置１０２には、プラグインＰ３の操作画面（認証画面：画面３）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報が、ＵＩ部２０３から再び認証プラグインＰａのロジック部１０ａへと渡される（ステップＳ２８）。
【００５２】
情報処理装置１００では、認証プラグインＰａのロジック部１０ａにより、認証情報に基づく利用者認証処理が行われ（ステップＳ２９）、その認証結果が、プラグインＰ３のＵＩ部２０３へと通知される。情報処理装置１００では、認証結果が、プラグインＰ３のＵＩ部２０３から連携先であるプラグインＰ４のＵＩ部２０４へと渡され、プラグインＰ３からプラグインＰ４へと画面遷移（画面３→４）が指示される（ステップＳ３０）。
【００５３】
続いて、情報処理装置１００では、プラグインＰ４のＵＩ部２０４により、表示画面が生成される（ステップＳ３１）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ４の操作画面（画面４）が表示される。
【００５４】
このように、本実施形態に係る情報処理装置１００では、プラグインＰのロジック部１０でなくＵＩ部２０により、プラグイン連携時の画面遷移が制御され、ロジック部１０による処理結果がＵＩ部２０を介して連携先へと伝達される。これによって、本実施形態に係る情報処理装置１００では、ロジック部１０とＵＩ部２０との独立性が保たれた構成でプラグイン間の連携動作が行える。
【００５５】
以下に、本実施形態に係るプラグイン連携機能の構成とその動作について説明する。
図７は、本実施形態に係る情報処理装置１００が有する機能構成例を示す図である。図７には、情報処理装置１００に、プラグインＰ１及びプラグインＰ２を有するアプリケーションＡＰが搭載（インストール）されている場合の機能構成例が示されている。また、図７に示す機能構成例は、アプリケーションＡＰにおいて、プラグインＰ１の処理結果をプラグインＰ２に通知する連携動作を想定している。
【００５６】
図７に示すように、まず、プラグインＰ１及びプラグインＰ２は、処理部１３１，１３２（以下総称する場合「処理部１３」と言う）と入出力部２２１，２２２（以下総称する場合「入出力部２２」と言う）とを、プラグインＰに共通する機能部として有している。
【００５７】
処理部１３は、ロジック部１０が有し、プラグインＰの提供機能を実現するための処理を行う機能部である。また、入出力部２２は、ＵＩ部２０が有し、利用者からの操作入力受け付けや利用者への情報表示出力を行う機能部である。
【００５８】
ここで、上記機能部の具体的な動作について、プラグインＰが認証機能を提供する場合を例に簡単に説明する。まず、入出力部２２は、利用者に対して認証情報（「ユーザＩＤ」や「パスワード」）の入力を促す認証画面（ログイン画面）を表示する。続いて、入出力部２２は、利用者により入力された認証情報を受け付け、処理部１３に認証情報を渡す。処理部１３は、認証情報に基づき利用者認証を行い、入出力部２２に認証結果を渡す。入出力部２２は、認証結果を反映した画面を表示する。
【００５９】
一方、プラグインＰ１は通知部２１１１を、プラグインＰ２は受信部２１２２を、プラグイン連携時の画面遷移を制御する機能部（画面遷移制御部）として有している。
【００６０】
通知部２１１１は、プラグインＰ１のＵＩ部２０１が有する画面遷移制御部２１１の一機能部ある。通知部２１１１は、入出力部２２１及び／又は処理部１３１からの情報をイベントとしてプラグインＰ２へと通知し、連携先のプラグインＰ２に対して画面遷移を指示する。このとき、通知部２１１１は、連携先のプラグインＰ２に渡す情報を基に、プラグインＰ２（受信部）が参照可能なイベントクラスを生成することで、イベントを通知する。なお、入出力部２２１からの情報には、例えば、利用者からの処理要求指示や入力値などがある。また、処理部１３１からの情報には、例えば、処理結果などがある。
【００６１】
受信部２１２２は、プラグインＰ２のＵＩ部２０２が有する画面遷移制御部２１２の一機能部である。受信部２１２２は、プラグインＰ１から通知されたイベントを受信する。このとき、受信部２１２２は、通知部２２１により生成されたイベントクラスを参照することで、イベントを受信する。受信部２１２２は、受信イベントから得た情報を、入出力部２２２及び／又は処理部１３２に渡し、連携後の処理を指示する。なお、連携後の処理には、画面遷移処理が含まれる。
【００６２】
ここで、上記機能部の具体的な動作について、プラグイン連携（プラグインＰ１からプラグインＰ２への連携）において利用者認証が必要な場合を例に簡単に説明する。まず、プラグインＰ１の通知部２１１１は、利用者により入力された認証情報を基に、プラグインＰ２が参照可能なイベントクラスを生成し、イベントを通知する。プラグインＰ２の受信部２１２２は、受信イベントから認証情報を得て、プラグインＰ２の処理部１３２に認証情報を渡す。処理部１３２は、認証情報に基づき利用者認証を行い、入出力部２２２に認証結果を渡す。入出力部２２２は、認証結果を反映したプラグインＰ２の画面を表示する。その結果、表示装置１０２の表示画面が、プラグインＰ１の表示画面からプラグインＰ２の表示画面へと遷移する。
【００６３】
このように、本実施形態に係る情報処理装置１００では、連携元のプラグインＰ１のＵＩ部２０１から連携先のプラグインＰ２のＵＩ部２０２に対してロジック部１０１の処理結果を通知し、遷移後の画面表示を指示する。
【００６４】
次に、本実施形態に係るプラグイン連携機能の詳細な動作（機能部群の連係動作）について、処理手順を示すシーケンス図を用いて説明する。
【００６５】
プラグイン連携機能は、情報処理装置１００に搭載（インストール）されるプログラム（プラグイン連携機能を実現するソフトウェア部品）が、ＣＰＵ１０６により、格納先（例えば「ＲＯＭ」や「ＨＤＤ」）からＲＡＭ１０４上に読み出され、以下の処理が実行されることで実現される。
【００６６】
図８は、本実施形態に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。図８には、図６で示した利用者認証を伴うプラグインＰ１からプラグインＰ２へのプラグイン連携（ステップＳ２１〜Ｓ２５）の詳細な処理手順例が示されている。
【００６７】
図８に示すように、情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する入出力部２２１より、表示画面から入力された利用者の認証情報（「ユーザＩＤ」や「パスワード」）を付け付ける（ステップＳ１０１）。入出力部２２１は、受け付けた認証情報を認証プラグインＰａのロジック部１０ａが有する処理部１３ａ（認証部に該当）へと渡し、利用者の認証許可判定を指示する（ステップＳ１０２）。
【００６８】
情報処理装置１００では、認証プラグインＰａのロジック部１０ａが有する処理部１３ａにより、認証情報に基づき、利用者の認証許可判定が行われる（ステップＳ２０１）。処理部１３ａは、認証結果をプラグインＰ１のＵＩ部２０１が有する通知部２１１１へと渡す（ステップＳ２０２）。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにより、認証結果をイベントとして通知する（ステップＳ２０３）。
【００６９】
通知部２１１１は、具体的に次のような処理を行う。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにイベントオブジェクト（ｌｏｇｉｎＥｖｅｎｔ）を指定し呼び出す。その結果、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドは、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたリスナー（イベント受信先）に対して、指定イベントオブジェクトをブロードキャストする。このとき、メモリ上には、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたプラグインＰ２（連携先）が参照可能なライブラリ形式で、認証結果が定義されたイベントクラス（ｌｏｇｉｎＥｖｅｎｔ｛認証ＯＫ｝）が生成される。
【００７０】
なお、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドでは、ブロードキャスト時の受信イベントに対応するイベントオブジェクト（ｅｖｅｎｔＯｂｊ）と、イベント受信時の実行処理（ａｃｔｉｏｎ）とを指定することで、リスナーを登録できる。よって、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドにより、連携先のプラグインＰ２を、プラグインＰ１の指定イベントオブジェクト（ｌｏｇｉｎＥｖｅｎｔ）と、プラグインＰ１からのイベント受信時の実行処理（ｄｉｓｐａｌｙ）とを指定して登録しておけば、プラグイン連携時の画面遷移が可能となる。具体的には、次のように処理され画面遷移する。
【００７１】
情報処理装置１００では、プラグインＰ２のＵＩ部２０２が有する受信部２１２２により、プラグインＰ１からの認証結果通知を受信する（ステップＳ３０１）。このとき、受信部２１２２は、イベントクラスから定義された認証結果を取得する。
【００７２】
続いて、受信部２１２２は、イベント受信時の実行処理（ｄｉｓｐｌａｙ）に従って、同ＵＩ部２０２が有する入出力部２２２に認証結果を渡し、認証結果を反映した画面表示を指示する（ステップＳ３０２）。これにより、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される。
【００７３】
情報処理装置１００では、プラグインＰ２のＵＩ部２０２が有する入出力部２２２により、表示画面が生成される（ステップＳ３０３）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ２の操作画面（画面２）が表示される。
【００７４】
以上のように、本実施形態に係る情報処理装置１００では、プラグインＰのロジック部１０でなくＵＩ部２０により、プラグイン連携時の画面遷移が制御され、ロジック部１０による処理結果がＵＩ部２０を介して連携先へと伝達されることで、画面遷移を伴うプラグイン連携が実現される。
【００７５】
《変形例》
図７に示した機能構成では、連携元のプラグインＰ１が有するＵＩ部２０１から連携先のプラグインＰ２が有するＵＩ部２０２に対して情報を通知する（一方向に情報伝達を行う）ことでプラグイン連携を実現している。
【００７６】
しかし、プラグイン連携機能には、プラグイン間において双方向に情報伝達を行うことで連携動作する構成も考えられる。つまり、連携先と連携元とが入れ替わる構成も考えられる。
【００７７】
以下には、変形例として、プラグイン間において双方向の情報伝達を行うプラグイン連携機能について説明する。
【００７８】
図９は、本変形例に係るプラグイン連携の動作例を示す図である。
本変形例に示すプラグイン連携機能では、例えば、図９に示すような、プラグイン間において双方向に情報伝達を行う連携動作を実現することができる。
【００７９】
まず、プラグインＰ１の画面Ｗ１には、プラグインＰ１のＵＩ部２０１により、識別子（ＩＤ）によりグループ化された３つの設定値（値１，値２，値３）が一覧表示されている。プラグインＰ１は、利用者による画面Ｗ１上の［追加］ボタン押下を受けて、新たな設定値を保存領域（データエリア）に追加する追加イベントを、ＵＩ部２０１からプラグインＰ２のＵＩ部２０２に通知する（図中の（１））。
【００８０】
プラグインＰ２は、追加イベントの通知を受けて、設定値を入力する画面Ｗ２を表示し、プラグインＰ１からプラグインＰ２へと画面が遷移する。プラグインＰ２は、利用者による画面Ｗ２上の識別子及び設定値（ＩＤ：００３，値１：Ｇ，値２：Ｈ，値３：Ｉ）入力と、［保存］ボタン押下とを受けて、ＵＩ部２０２から保存処理の指示を受け付けたロジック部１０２により、設定値を保存領域に追加・保存する（図中の（２））。その保存結果［成功／失敗］は、ロジック部１０２からＵＩ部２０２へと渡される（図中の（３））。その結果、ＵＩ部２０２は、保存結果［成功／失敗］及び保存内容［００３，Ｇ，Ｈ，Ｉ］を、保存結果イベントとして、プラグインＰ１のＵＩ部２０１に通知する（図中の（４））。
【００８１】
プラグインＰ１は、保存結果イベントの通知を受けて、追加された設定値を含む一覧画面Ｗ３を表示し、プラグインＰ２からプラグインＰ１へと画面が遷移する。これにより、プラグインＰ１の表示画面が更新される（画面Ｗ１→画面Ｗ３）。
【００８２】
図１０は、本変形例に係る情報処理装置１００が有する機能構成例を示す図である。
本変形例に係るプラグイン連携機能は、図７と図１０との比較からも分かるように、ＵＩ部２０の画面遷移制御部２１が、通知部２１１及び受信部２１２の両方を有している。本変形では、このような機能構成により、プラグイン間において双方向に情報伝達を行うことができる。
【００８３】
本変形例に係るプラグイン連携機能の処理手順は、次の通りである。
図１１は、本変形例に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。なお、図１１には、図９に示した連携動作時の処理手順例が示されている。
【００８４】
図１１に示すように、情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する入出力部２２１より、新たな設定値（データ）の追加命令（［追加］ボタン押下）を受け付ける（ステップＳ４０１）。入出力部２２１は、受け付けたデータ追加の通知をＵＩ部２０１が有する通知部２１１１に指示する（ステップＳ４０２）。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにより、データ追加イベントを通知する（ステップＳ４０３）。
【００８５】
通知部２１１１は、具体的に次のような処理を行う。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにイベントオブジェクト（ａｄｄＥｖｅｎｔ）を指定し呼び出す。その結果、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドは、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたリスナー（プラグイン２）に対して、指定イベントオブジェクトをブロードキャストする。このとき、メモリ上には、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたプラグインＰ２（連携先）が参照可能なライブラリ形式で、データ追加命令が定義されたイベントクラス（ａｄｄＥｖｅｎｔ｛ｘ｝）が生成される。
【００８６】
情報処理装置１００では、プラグインＰ２のＵＩ部２０２が有する受信部２１２２により、プラグインＰ１からのデータ追加通知を受信する（ステップＳ５０１）。このとき、受信部２１２２は、イベントクラスから定義されたデータ追加命令を取得する。
【００８７】
続いて、受信部２１２２は、イベント受信時の実行処理（ｉｎｐｕｔ）に従って、同ＵＩ部２０２が有する入出力部２２２に、識別子及び設定値の入力を受け付ける画面表示を指示する（ステップＳ５０２）。これにより、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される。
【００８８】
入出力部２２２は、表示画面を介して入力された識別子及び設定値（入力情報）を受け付け（ステップＳ５０３）、受け付けた入力情報［００３，Ｇ，Ｈ，Ｉ］をプラグインＰ２のロジック部１０２が有する処理部１３２に渡し、保存処理の実行を指示する（ステップＳ５０４）。
【００８９】
処理部１３２は、受け取った入力情報を保存領域に保存し（ステップＳ５０５）、保存結果［成功］及び保存内容［ＩＤ：００３，値１：Ｇ，値２：Ｈ，値３：Ｉ］を、ＵＩ部２０２が有する通知部２１１２に渡し、実行結果の通知を指示する（ステップＳ５０６）。通知部２１１２は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにより、実行結果イベントを通知する（ステップＳ５０７）。
【００９０】
通知部２１１２は、具体的に次のような処理を行う。通知部２１１２は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにイベントオブジェクト（ｓａｖｅＥｖｅｎｔ）を指定し呼び出す。その結果、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドは、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたリスナー（プラグイン１）に対して、指定イベントオブジェクトをブロードキャストする。このとき、メモリ上には、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたプラグインＰ１（連携先）が参照可能なライブラリ形式で、実行結果（結果［成功］の場合は保存内容）が定義されたイベントクラス（ｓａｖｅＥｖｅｎｔ｛００３，Ｇ，Ｈ，Ｉ｝）が生成される。
【００９１】
情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する受信部２１２１により、プラグインＰ２からの実行結果通知を受信する（ステップＳ６０１）。このとき、受信部２１２１は、イベントクラスから定義された実行結果を取得する。
【００９２】
続いて、受信部２１２１は、イベント受信時の実行処理（ｄｉｓｐｌａｙ）に従って、同ＵＩ部２０１が有する入出力部２２１に実行結果を渡し、実行結果を反映した画面表示を指示する（ステップＳ６０２）。これにより、プラグインＰ２からプラグインＰ１へと画面遷移（画面２→１）が指示される。
【００９３】
情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する入出力部２２１により、表示画面（設定値の一覧画面）が生成される（ステップＳ６０３）。その結果、表示装置１０２には、新たに追加された設定値を含む実行結果が反映されたプラグインＰ１の操作画面（画面１）が表示される。
【００９４】
＜まとめ＞
以上のように、本実施形態に係る情報処理装置１００によれば、連携元のプラグインＰ１のＵＩ部２０１から連携先のプラグインＰ２のＵＩ部２０２に対してロジック部１０２の処理結果を通知し、遷移後の画面表示を指示する。
【００９５】
これによって、本実施形態に係る情報処理装置１００では、ロジック部１０でなくＵＩ部２０により、プラグイン連携時の画面遷移が制御され、ロジック部１０による処理結果がＵＩ部２０を介して連携先へと伝達される。また、プラグイン連携時の情報伝達は、プラグイン間において、連携元から連携先への一方向だけでなく双方向でも行われる。
【００９６】
このように、本実施形態に係る情報処理装置１００では、プラグインＰが有するロジック部１０とＵＩ部２０との独立性が保たれた構成でプラグイン間の連携動作が行える。
【００９７】
ここまで、上記実施形態の説明を行ってきたが、上記実施形態に係る情報処理装置１００が有する「プラグイン連携機能」は、図を用いて説明を行った各処理手順を、動作環境（プラットフォーム）にあったプログラミング言語でコード化したプログラムが、ＣＰＵ１０６により実行されることで実現される。
【００９８】
上記プログラムは、コンピュータが読み取り可能な記録媒体１０３ａに格納することができる。上記記録媒体１０３ａには、例えば、フロッピー（登録商標）ディスク、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびにＳＤメモリカード（SD Memory Card）及びＵＳＢ（Universal Serial Bus）メモリなどがある。
【００９９】
よって、上記プログラムは、上記記録媒体１０３ａに記憶させることで、記録媒体１０３ａを読み取り可能なドライブ装置１０３などを介して情報処理装置１００にインストールすることができる。また、情報処理装置１００は、インタフェース装置１０７を備えていることから、インターネットなどの電気通信回線を用いて上記プログラムをダウンロードし、インストールすることもできる。
【０１００】
また、上記実施形態では、プラグインＰが有するＵＩ部２０の間で行うプラグイン連携時のイベント処理に、ＡｃｔｉｏｎＳｃｒｉｐｔ（Ｆｌａｓｈに使用されるプログラミング言語）のＥｖｅｎｔＤｉｓｐａｔｃｈｅｒクラスに属するメソッドを用いた場合について説明を行ったが、この限りでない。
【０１０１】
最後に、上記実施形態に挙げた形状や構成に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。
【符号の説明】
【０１０２】
１０ ロジック部（プラグインロジック）
１１ 画面遷移制御部（ロジック部側）
１２ 認証部
１３ 処理部
２０ ＵＩ部（プラグインＵＩ）
２１ 画面遷移制御部（ＵＩ部側）
２１１ 通知部（１：プラグイン１，２：プラグイン２）
２１２ 受信部（１：プラグイン１，２：プラグイン２）
２２ 入出力部（１：プラグイン１，２：プラグイン２）
１００ 情報処理装置
１０１ 入力装置
１０２ 表示装置
１０３ ドライブ装置（ａ：記録媒体）
１０４ ＲＡＭ（揮発性の半導体メモリ）
１０５ ＲＯＭ（不揮発性の半導体メモリ）
１０６ ＣＰＵ（中央処理装置）
１０７ インタフェース装置（ＮＩＣ：Network I/F Card）
１０８ ＨＤＤ（不揮発性の記憶装置）
ＡＰ アプリケーション
Ｐｎ プラグイン
ＰＦ プラットフォーム
【先行技術文献】
【特許文献】
【０１０３】
【特許文献１】特開２００９−５４０２７号公報
【技術分野】
【０００１】
本発明は、情報処理装置に関し、特に、複数のプラグインを有するアプリケーションにおいて、プラグインが画面遷移し、連携動作する技術に関するものである。
【背景技術】
【０００２】
例えば、特許文献１には、プラグインごとの操作画面のカスタマイズ効率を高めることを目的とした表示画面カスタマイズプログラムに関する技術が開示されている。その中で、表示画面カスタマイズプログラムは、各プラグイン共通の画面構成情報と画面カスタマイズ情報を有し、これらの情報に基づき、各プラグインの表示画面を生成する。つまり、特許文献１に開示される技術では、表示画面の生成機能を複数のプラグインに対して共通化することで、プラグインごとの表示画面を統一し、カスタマイズ効率の向上を実現している。しかし、本来であれば、このようなプラグインの表示画面は、提供機能の利便性や利用者の操作性を考慮し、プラグインごとでカスタマイズしたい。
【０００３】
また、近年のプラグインは、迅速な機能提供や優れた拡張性を実現するために、他の開発部署や他のソフトウェアベンダーと言った複数の異なる組織により開発・提供される場合が多い。このような環境下では、開発を行った組織単位で、プラグインの表示画面をカスタマイズした方が、利便性や操作性を考慮したＵＩ（User Interface）の提供を実現するだけでなく、開発効率の面でも効果的である。
【０００４】
そこで、プラグインのソフトウェア構成には、プラグインの開発効率や表示画面のカスタマイズ性を考慮し、表示画面を生成するＵＩ部と、機能を実現するための処理を実行するロジック部と、を有する構成が考えられる。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、従来のプラグインには、他のプラグインと連携する際に次のような問題がある。従来のプラグインでは、ロジック部によりＵＩ部の画面表示を制御している。そのため、プラグイン連携時の画面遷移が、連携プラグインの各ロジック部により制御される。例えば、プラグインＡとプラグインＢとが連携動作し、プラグインＡの表示画面からプラグインＢの表示画面へと遷移する場合を例に説明する。まず、プラグインＡのロジック部がプラグインＡのＵＩ部から受け付けた利用者からの動作指示に従って所定の処理を実行する。その処理結果は、プラグインＡのロジック部からプラグインＢのロジック部へと通知され、画面遷移が指示される。プラグインＢのロジック部は、通知された処理結果を基にプラグインＢのＵＩ部へ画面表示を指示する。これにより、プラグインＡの表示画面からプラグインＢの表示画面へと遷移する。
【０００６】
上記動作例からも分かるように、従来のプラグインでは、動作連携時の画面遷移制御をロジック部が行っているため、ロジック部とＵＩ部との独立性が保たれない構成となってしまう。また、従来のプラグインでは、ロジック部が実現する機能をプラグイン間で共通化したい場合であっても、画面遷移制御までは共通化できないため、異なるロジック部に同一機能が重複して存在することになる。
【０００７】
このように、従来のプラグインでは、ソフトウェアの開発・保守を困難なものとし、リソースを無駄に消費してしまう可能性があった。
【０００８】
本発明は上記従来技術の問題点を鑑み提案されたものであり、その目的とするところは、プラグインが有するＵＩ部とロジック部との独立性を保ち、プラグイン間の連携動作が可能な情報処理装置、プラグイン連携方法、プラグイン連携プログラム、及びそのプログラムを記録した記録媒体を提供することにある。
【課題を解決するための手段】
【０００９】
上記目的を達成するため、本発明に係る情報処理装置は、複数のプラグインを有するアプリケーションが動作する情報処理装置であって、前記プラグインが、プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有し、前記ＵＩ部が、同プラグインのロジック部による処理結果を他のプラグインに通知する通知手段、及び／又は前記処理結果を他のプラグインから受信する受信手段、を有し、プラグイン間において、連携元のプラグインが、前記通知手段により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、前記連携先のプラグインが、前記受信手段により、前記通知手段が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインのＵＩ部により表示画面を生成することを特徴とする。
【００１０】
このような構成によって、本発明に係る情報処理装置は、連携元のプラグインのＵＩ部から連携先のプラグインのＵＩ部に対してロジック部の処理結果を通知し、遷移後の画面表示を指示する。
【００１１】
これによって、本発明に係る情報処理装置では、ロジック部でなくＵＩ部により、プラグイン連携時の画面遷移が制御され、ロジック部による処理結果がＵＩ部を介して連携先へと伝達される。その結果、プラグインが有するロジック部とＵＩ部との独立性が保たれた構成でプラグイン間の連携動作が行える。
【００１２】
上記目的を達成するため、本発明に係るプラグイン連携方法は、プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有する複数のプラグインで構成されるアプリケーションが動作する情報処理装置におけるプラグイン連携方法であって、プラグイン間において、連携元のプラグインが、同プラグインのＵＩ部により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、前記連携先のプラグインが、同プラグインのＵＩ部により、前記連携元のプラグインが通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成することを特徴とする。
【００１３】
このような手順によって、本発明に係るプラグイン連携方法では、連携元のプラグインのＵＩ部から連携先のプラグインのＵＩ部に対してロジック部の処理結果を通知し、遷移後の画面表示を指示すると言う動作を実現する。
【００１４】
これによって、本発明に係るプラグイン連携方法は、プラグインが有するＵＩ部とロジック部との独立性を保ち、プラグイン間の連携動作が可能な環境を提供できる。
【発明の効果】
【００１５】
本発明によれば、プラグインが有するＵＩ部により、プラグイン連携時の画面遷移を制御し、ロジック部による処理結果をＵＩ部が連携先へと伝達することで、ロジック部とＵＩ部との独立性を保ち、プラグイン間の連携動作が可能な情報処理装置、プラグイン連携方法、プラグイン連携プログラム、及びそのプログラムを記録した記録媒体を提供することができる。
【図面の簡単な説明】
【００１６】
【図１】本発明の第１の実施形態に係る情報処理装置のハードウェア構成例を示す図である。
【図２】アプリケーションのソフトウェア構成例を示す図である。
【図３】従来のプラグイン連携の処理手順例を示すシーケンス図である。
【図４】従来のプラグイン連携を行うソフトウェア構成例を示す図である。
【図５】本発明の第１の実施形態に係るプラグイン連携を行うソフトウェア構成例を示す図である。
【図６】本発明の第１の実施形態に係るプラグイン連携の処理手順例を示すシーケンス図である。
【図７】本発明の第１の実施形態に係る情報処理装置が有する機能構成例を示す図である。
【図８】本発明の第１の実施形態に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。
【図９】本発明の変形例に係るプラグイン連携の動作例を示す図である。
【図１０】本発明の変形例に係る情報処理装置が有する機能構成例を示す図である。
【図１１】本発明の変形例に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。
【発明を実施するための形態】
【００１７】
以下、本発明の好適な実施の形態（以下「実施形態」と言う）について、図面を用いて詳細に説明する。
【００１８】
［第１の実施形態］
＜ハードウェア構成＞
本実施形態に係る情報処理装置のハードウェア構成について説明する。
図１は、本実施形態に係る情報処理装置１００のハードウェア構成例を示す図である。
図１に示すように、情報処理装置１００は、入力装置１０１、表示装置１０２、ドライブ装置１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、インタフェース装置１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
【００１９】
入力装置１０１は、キーボード及びマウスなどを含み、情報処理装置１００に各操作信号を入力するのに用いられる。表示装置１０２は、ディスプレイなどを含み、情報処理装置１００による処理結果を表示する。
【００２０】
インタフェース装置１０７は、情報処理装置１００を所定のデータ伝送路（例えば「ＬＡＮ：Local Area Network」）に接続するインタフェースである。よって、情報処理装置１００は、インタフェース装置１０７を介して、接続される周辺機器２００（例えば「プリンタ」や「ＰＣ：Personal Computer」）とデータ通信を行うことができる。
【００２１】
ＨＤＤ１０８は、各種プログラム及びデータを格納している不揮発性の記憶装置である。格納されるプログラム及びデータには、例えば、情報処理装置１００全体を制御する情報処理システム（「Ｗｉｎｄｏｗｓ（登録商標）」や「ＵＮＩＸ（登録商標）」などの基本ソフトウェアであるＯＳ：Operating System）、及び情報処理システム上において各種機能を提供するアプリケーションなどがある。また、ＨＤＤ１０８は、格納している上記プログラム及びデータを、所定のファイルシステム及び／又はＤＢ（Data Base）により管理している。
【００２２】
ドライブ装置１０３は、着脱可能な記録媒体１０３ａとのインタフェースである。これにより、情報処理装置１００は、ドライブ装置１０３を介して、記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。
【００２３】
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、情報処理装置１００が起動されるときに実行されるＢＩＯＳ（Basic Input/Output System）や、情報処理装置１００のシステム設定及びネットワーク関連設定などのデータが格納されている。
【００２４】
ＲＡＭ１０４は、上記各種記憶装置から読み出されたプログラム及びデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、ＲＯＭ１０５やＨＤＤ１０８からＲＡＭ１０４上に読み出したプログラムを実行することにより、情報処理装置１００の全体制御及び各種搭載機能の動作を実現する。
【００２５】
情報処理装置１００では、上記ハードウェア構成により、情報処理サービス（情報処理機能）を提供することができる。
【００２６】
また、情報処理装置１００は、上記ハードウェア構成からも分かるようにＰＣ（Personal Computer）などと略同一の構成をしている。
【００２７】
＜ソフトウェア構成＞
次に、上記情報処理装置１００に搭載される（インストールされる）アプリケーションのソフトウェア構成について説明する。
図２は、アプリケーションＡＰのソフトウェア構成例を示す図である。
図２に示すように、アプリケーションＡＰは、複数のプラグインＰ１〜Ｐｎ（以下総称する場合は「プラグインＰ」と言う）と、プラグインＰの動作環境であるプラットフォームＰＦとを有する構成となっている。つまり、アプリケーションＡＰの機能は、各プラグインＰ１〜ＰｎがプラットフォームＰＦ上で連携動作することで実現・提供される。このようなソフトウェア構成とするメリットには、開発効率の向上や独立した開発部品（ソフトウェア部品）による迅速な機能提供、また優れた拡張性の実現などが挙げられる。
【００２８】
さらに、各プラグインＰ１〜Ｐｎは、各機能を実現するための処理を行うプラグインロジック（以下単に「ロジック部」と言う）１０１〜１０ｎ（以下総称する場合は「ロジック部１０」と言う）と、各表示画面を生成するプラグインＵＩ（以下単に「ＵＩ部」と言う）２０１〜２０ｎ（以下総称する場合は「ＵＩ部２０」と言う）とを有する構成となっている。このようなソフトウェア構成とするメリットには、プラグインＰの開発効率や表示画面のカスタマイズ性の向上がなど挙げられる。
【００２９】
また、ロジック部１０とＵＩ部２０との関係は、次の通りである。例えば、ロジック部１０１とＵＩ部２０１とは、同じプラグイン（同プラグイン）に属するソフトウェア部品である。一方、ロジック部１０２とＵＩ部２０１とは、異なるプラグインに属するソフトウェア部品である。つまり、ＵＩ部２０１から見たロジック部１０２は、他のプラグインに属するソフトウェア部品と言うことになる。この点については、ロジック部同士であってもＵＩ部同士であっても同じことが言える。よって、上記ソフトウェア構成におけるプラグイン連携とは、異なるプラグインＰに属するソフトウェア部品同士が連携することを意味する。
【００３０】
このようなソフトウェア構成において、従来のアプリケーションＡＰでは、画面遷移制御部１１１〜１１ｎ（以下総称する場合は「画面遷移制御部１１」と言う）を、プラグインＰのロジック部１０が有している。
【００３１】
＜プラグイン連携機能＞
まず、従来のアプリケーションＡＰにおけるプラグイン連携動作について説明する。
図３は、従来のプラグイン連携の処理手順例を示すシーケンス図である。図３には、４つのプラグインＰ１〜Ｐ４を有するアプリケーションＡＰにおけるプラグイン連携の処理手順例が示されている。また、このアプリケーションＡＰでは、プラグインＰ１からプラグインＰ２への画面遷移、プラグインＰ３からプラグインＰ４への画面遷移において、利用者認証が必要となる。このようなアプリケーションＡＰを搭載した情報処理装置１００では、アプリケーションＡＰ内のプラグイン連携が次のように行われる。
【００３２】
図３に示すように、まず、情報処理装置１００では、プラグインＰ１のロジック部１０１からＵＩ部２０１に対して、画面表示が指示される（ステップＳ１１）。その結果、表示装置１０２には、プラグインＰ１の操作画面（認証画面：画面１）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報（例えば「ユーザＩＤ」や「パスワード」）がＵＩ部２０１からロジック部１０１へと渡される。
【００３３】
情報処理装置１００では、ロジック部１０１により、認証情報に基づく利用者認証処理が行われ（ステップＳ１２）、その認証結果が、連携先であるプラグインＰ２のロジック部１０２へと通知され、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される（ステップＳ１３）。
【００３４】
続いて、情報処理装置１００では、プラグインＰ２のロジック部１０２からＵＩ部２０２に対して、画面表示が指示される（ステップＳ１４）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ２の操作画面（画面２）が表示される。情報処理装置１００では、利用者入力で受け付けた操作情報（例えば「次処理指定」）がＵＩ部２０２からロジック部１０２へと渡される。
【００３５】
情報処理装置１００では、ロジック部１０２により、必要に応じて所定の処理が行われ、その処理結果が、連携先であるプラグインＰ３のロジック部１０３へと通知され、プラグインＰ２からプラグインＰ３へと画面遷移（画面２→３）が指示される（ステップＳ１５）。
【００３６】
続いて、情報処理装置１００では、プラグインＰ３のロジック部１０３からＵＩ部２０３に対して、画面表示が指示される（ステップＳ１６）。その結果、表示装置１０２には、プラグインＰ３の操作画面（認証画面：画面３）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報がＵＩ部２０３からロジック部１０３へと渡される。
【００３７】
情報処理装置１００では、ロジック部１０３により、認証情報に基づく利用者認証処理が行われ（ステップＳ１７）、その認証結果が、連携先であるプラグインＰ４のロジック部１０４へと通知され、プラグインＰ３からプラグインＰ４へと画面遷移（画面３→４）が指示される（ステップＳ１８）。
【００３８】
続いて、情報処理装置１００では、プラグインＰ４のロジック部１０４からＵＩ部２０４に対して、画面表示が指示される（ステップＳ１９）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ４の操作画面（画面４）が表示される。
【００３９】
このように、従来のアプリケーションＡＰでは、プラグイン連携処理を行う場合、図４に示すようなソフトウェア構成となってしまう。
【００４０】
図４は、従来のプラグイン連携を行うソフトウェア構成例を示す図である。
図４に示すように、各プラグインＰ１〜Ｐ４が有するロジック部１０１〜１０４は、連携先への画面遷移を制御する画面遷移制御部１１１〜１１４を個々に有している。そのため、プラグインＰでは、ＵＩ部２０とロジック部１０との独立性が保たれず、連携先の変更を行う場合、ロジック部担当の開発者に必要以上の技術を要求することになる。つまり、ロジック部担当の開発者には、機能実現処理以外の画面処理に関する技術の理解も必要とされる。これは、開発者にとって煩雑であり、作業分担による高い開発効率を実現する上で弊害となる。
【００４１】
また、プラグインＰ１及びＰ３が有するロジック部１０１及び１０３は、利用者認証を行う同一の機能（認証部１２１及び１２３）を有している。これは、ロジック部１０１及び１０３が画面遷移制御部１１１及び１１３を有しているため、画面遷移制御部１１１及び１１３の動作時に利用者認証を行わなければならないからである。そのため、プラグインＰのロジック部１０では、共通化可能な機能が重複してしまい、無駄なリソースを消費することになる。また、ロジック部担当の開発者には、煩雑なソフトウェア開発・保守を強いることになる。
【００４２】
このように、従来のプラグインＰでは、ソフトウェアの開発・保守を困難なものとし、リソースを無駄に消費してしまう可能性があった。
【００４３】
そこで、本実施形態に係る情報処理装置１００では、連携元のプラグインＰ１のＵＩ部２０１から連携先のプラグインＰ２のＵＩ部２０２に対してロジック部１０１の処理結果を通知し、遷移後の画面表示を指示する。情報処理装置１００は、このようなプラグイン連携機能を有している。
【００４４】
図５は、本実施形態に係るプラグイン連携を行うソフトウェア構成例を示すである。図５には、上記に説明を行った図３と同じプラグイン連携を行う本実施形態に係るアプリケーションＡＰのソフトウェア構成例が示されている。
【００４５】
本実施形態に係るアプリケーションＡＰは、図４に示した従来のソフトウェア構成と次の点で異なる。本実施形態に係るアプリケーションＡＰでは、プラグインＰ１〜Ｐ４のロジック部１０１〜１０４ではなく、ＵＩ部２０１〜２０４が、連携時の画面遷移を制御する機能部（画面遷移制御部２１１〜２１４）を有している点である。これにより、プラグインＰでは、ロジック部１０とＵＩ部２０との独立性が保たれ、画面処理に関する技術に精通したＵＩ部担当の開発者による対応が可能となり、開発・保守作業の分担が明確となる。
【００４６】
また、プラグインＰ１及びＰ３のロジック部１０１及び１０３が有していた重複機能（認証部１２１及び１２３）を、１つの機能に共通化（プラグイン化）している点である。この機能の共通化は、上記構成（ＵＩ部が画面遷移機能を有する構成）としたことで、ロジック部１０の独立性が確保されたことによるものである。
【００４７】
以下に、本実施形態に係るアプリケーションＡＰにおけるプラグイン連携の処理手順例を示す。
【００４８】
図６は、本実施形態に係るプラグイン連携の処理手順例を示すシーケンス図である。
図６に示すように、情報処理装置１００では、プラグインＰ１のＵＩ部２０１により、表示画面が生成される（ステップＳ２１）。その結果、表示装置１０２には、プラグインＰ１の操作画面（認証画面：画面１）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報が、ＵＩ部２０１から共通化された認証プラグインＰａのロジック部１０ａへと渡される（ステップＳ２２）。
【００４９】
情報処理装置１００では、認証プラグインＰａのロジック部１０ａにより、認証情報に基づく利用者認証処理が行われ（ステップＳ２３）、その認証結果が、プラグインＰ１のＵＩ部２０１へと通知される。情報処理装置１００では、認証結果が、プラグインＰ１のＵＩ部２０１から連携先であるプラグインＰ２のＵＩ部２０２へと渡され、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される（ステップＳ２４）。
【００５０】
続いて、情報処理装置１００では、プラグインＰ２のＵＩ部２０２により、表示画面が生成される（ステップＳ２５）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ２の操作画面（画面２）が表示される。情報処理装置１００では、利用者入力で受け付けた操作情報が、プラグインＰ２のＵＩ部２０２から連携先であるプラグインＰ３のＵＩ部２０３へと渡され、プラグインＰ２からプラグインＰ３へと画面遷移（画面２→３）が指示される（ステップＳ２６）。
【００５１】
続いて、情報処理装置１００では、プラグインＰ３のＵＩ部２０３により、表示画面が生成される（ステップＳ２７）。その結果、表示装置１０２には、プラグインＰ３の操作画面（認証画面：画面３）が表示される。情報処理装置１００では、利用者入力で受け付けた認証情報が、ＵＩ部２０３から再び認証プラグインＰａのロジック部１０ａへと渡される（ステップＳ２８）。
【００５２】
情報処理装置１００では、認証プラグインＰａのロジック部１０ａにより、認証情報に基づく利用者認証処理が行われ（ステップＳ２９）、その認証結果が、プラグインＰ３のＵＩ部２０３へと通知される。情報処理装置１００では、認証結果が、プラグインＰ３のＵＩ部２０３から連携先であるプラグインＰ４のＵＩ部２０４へと渡され、プラグインＰ３からプラグインＰ４へと画面遷移（画面３→４）が指示される（ステップＳ３０）。
【００５３】
続いて、情報処理装置１００では、プラグインＰ４のＵＩ部２０４により、表示画面が生成される（ステップＳ３１）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ４の操作画面（画面４）が表示される。
【００５４】
このように、本実施形態に係る情報処理装置１００では、プラグインＰのロジック部１０でなくＵＩ部２０により、プラグイン連携時の画面遷移が制御され、ロジック部１０による処理結果がＵＩ部２０を介して連携先へと伝達される。これによって、本実施形態に係る情報処理装置１００では、ロジック部１０とＵＩ部２０との独立性が保たれた構成でプラグイン間の連携動作が行える。
【００５５】
以下に、本実施形態に係るプラグイン連携機能の構成とその動作について説明する。
図７は、本実施形態に係る情報処理装置１００が有する機能構成例を示す図である。図７には、情報処理装置１００に、プラグインＰ１及びプラグインＰ２を有するアプリケーションＡＰが搭載（インストール）されている場合の機能構成例が示されている。また、図７に示す機能構成例は、アプリケーションＡＰにおいて、プラグインＰ１の処理結果をプラグインＰ２に通知する連携動作を想定している。
【００５６】
図７に示すように、まず、プラグインＰ１及びプラグインＰ２は、処理部１３１，１３２（以下総称する場合「処理部１３」と言う）と入出力部２２１，２２２（以下総称する場合「入出力部２２」と言う）とを、プラグインＰに共通する機能部として有している。
【００５７】
処理部１３は、ロジック部１０が有し、プラグインＰの提供機能を実現するための処理を行う機能部である。また、入出力部２２は、ＵＩ部２０が有し、利用者からの操作入力受け付けや利用者への情報表示出力を行う機能部である。
【００５８】
ここで、上記機能部の具体的な動作について、プラグインＰが認証機能を提供する場合を例に簡単に説明する。まず、入出力部２２は、利用者に対して認証情報（「ユーザＩＤ」や「パスワード」）の入力を促す認証画面（ログイン画面）を表示する。続いて、入出力部２２は、利用者により入力された認証情報を受け付け、処理部１３に認証情報を渡す。処理部１３は、認証情報に基づき利用者認証を行い、入出力部２２に認証結果を渡す。入出力部２２は、認証結果を反映した画面を表示する。
【００５９】
一方、プラグインＰ１は通知部２１１１を、プラグインＰ２は受信部２１２２を、プラグイン連携時の画面遷移を制御する機能部（画面遷移制御部）として有している。
【００６０】
通知部２１１１は、プラグインＰ１のＵＩ部２０１が有する画面遷移制御部２１１の一機能部ある。通知部２１１１は、入出力部２２１及び／又は処理部１３１からの情報をイベントとしてプラグインＰ２へと通知し、連携先のプラグインＰ２に対して画面遷移を指示する。このとき、通知部２１１１は、連携先のプラグインＰ２に渡す情報を基に、プラグインＰ２（受信部）が参照可能なイベントクラスを生成することで、イベントを通知する。なお、入出力部２２１からの情報には、例えば、利用者からの処理要求指示や入力値などがある。また、処理部１３１からの情報には、例えば、処理結果などがある。
【００６１】
受信部２１２２は、プラグインＰ２のＵＩ部２０２が有する画面遷移制御部２１２の一機能部である。受信部２１２２は、プラグインＰ１から通知されたイベントを受信する。このとき、受信部２１２２は、通知部２２１により生成されたイベントクラスを参照することで、イベントを受信する。受信部２１２２は、受信イベントから得た情報を、入出力部２２２及び／又は処理部１３２に渡し、連携後の処理を指示する。なお、連携後の処理には、画面遷移処理が含まれる。
【００６２】
ここで、上記機能部の具体的な動作について、プラグイン連携（プラグインＰ１からプラグインＰ２への連携）において利用者認証が必要な場合を例に簡単に説明する。まず、プラグインＰ１の通知部２１１１は、利用者により入力された認証情報を基に、プラグインＰ２が参照可能なイベントクラスを生成し、イベントを通知する。プラグインＰ２の受信部２１２２は、受信イベントから認証情報を得て、プラグインＰ２の処理部１３２に認証情報を渡す。処理部１３２は、認証情報に基づき利用者認証を行い、入出力部２２２に認証結果を渡す。入出力部２２２は、認証結果を反映したプラグインＰ２の画面を表示する。その結果、表示装置１０２の表示画面が、プラグインＰ１の表示画面からプラグインＰ２の表示画面へと遷移する。
【００６３】
このように、本実施形態に係る情報処理装置１００では、連携元のプラグインＰ１のＵＩ部２０１から連携先のプラグインＰ２のＵＩ部２０２に対してロジック部１０１の処理結果を通知し、遷移後の画面表示を指示する。
【００６４】
次に、本実施形態に係るプラグイン連携機能の詳細な動作（機能部群の連係動作）について、処理手順を示すシーケンス図を用いて説明する。
【００６５】
プラグイン連携機能は、情報処理装置１００に搭載（インストール）されるプログラム（プラグイン連携機能を実現するソフトウェア部品）が、ＣＰＵ１０６により、格納先（例えば「ＲＯＭ」や「ＨＤＤ」）からＲＡＭ１０４上に読み出され、以下の処理が実行されることで実現される。
【００６６】
図８は、本実施形態に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。図８には、図６で示した利用者認証を伴うプラグインＰ１からプラグインＰ２へのプラグイン連携（ステップＳ２１〜Ｓ２５）の詳細な処理手順例が示されている。
【００６７】
図８に示すように、情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する入出力部２２１より、表示画面から入力された利用者の認証情報（「ユーザＩＤ」や「パスワード」）を付け付ける（ステップＳ１０１）。入出力部２２１は、受け付けた認証情報を認証プラグインＰａのロジック部１０ａが有する処理部１３ａ（認証部に該当）へと渡し、利用者の認証許可判定を指示する（ステップＳ１０２）。
【００６８】
情報処理装置１００では、認証プラグインＰａのロジック部１０ａが有する処理部１３ａにより、認証情報に基づき、利用者の認証許可判定が行われる（ステップＳ２０１）。処理部１３ａは、認証結果をプラグインＰ１のＵＩ部２０１が有する通知部２１１１へと渡す（ステップＳ２０２）。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにより、認証結果をイベントとして通知する（ステップＳ２０３）。
【００６９】
通知部２１１１は、具体的に次のような処理を行う。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにイベントオブジェクト（ｌｏｇｉｎＥｖｅｎｔ）を指定し呼び出す。その結果、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドは、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたリスナー（イベント受信先）に対して、指定イベントオブジェクトをブロードキャストする。このとき、メモリ上には、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたプラグインＰ２（連携先）が参照可能なライブラリ形式で、認証結果が定義されたイベントクラス（ｌｏｇｉｎＥｖｅｎｔ｛認証ＯＫ｝）が生成される。
【００７０】
なお、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドでは、ブロードキャスト時の受信イベントに対応するイベントオブジェクト（ｅｖｅｎｔＯｂｊ）と、イベント受信時の実行処理（ａｃｔｉｏｎ）とを指定することで、リスナーを登録できる。よって、ａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドにより、連携先のプラグインＰ２を、プラグインＰ１の指定イベントオブジェクト（ｌｏｇｉｎＥｖｅｎｔ）と、プラグインＰ１からのイベント受信時の実行処理（ｄｉｓｐａｌｙ）とを指定して登録しておけば、プラグイン連携時の画面遷移が可能となる。具体的には、次のように処理され画面遷移する。
【００７１】
情報処理装置１００では、プラグインＰ２のＵＩ部２０２が有する受信部２１２２により、プラグインＰ１からの認証結果通知を受信する（ステップＳ３０１）。このとき、受信部２１２２は、イベントクラスから定義された認証結果を取得する。
【００７２】
続いて、受信部２１２２は、イベント受信時の実行処理（ｄｉｓｐｌａｙ）に従って、同ＵＩ部２０２が有する入出力部２２２に認証結果を渡し、認証結果を反映した画面表示を指示する（ステップＳ３０２）。これにより、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される。
【００７３】
情報処理装置１００では、プラグインＰ２のＵＩ部２０２が有する入出力部２２２により、表示画面が生成される（ステップＳ３０３）。その結果、表示装置１０２には、認証結果が反映されたプラグインＰ２の操作画面（画面２）が表示される。
【００７４】
以上のように、本実施形態に係る情報処理装置１００では、プラグインＰのロジック部１０でなくＵＩ部２０により、プラグイン連携時の画面遷移が制御され、ロジック部１０による処理結果がＵＩ部２０を介して連携先へと伝達されることで、画面遷移を伴うプラグイン連携が実現される。
【００７５】
《変形例》
図７に示した機能構成では、連携元のプラグインＰ１が有するＵＩ部２０１から連携先のプラグインＰ２が有するＵＩ部２０２に対して情報を通知する（一方向に情報伝達を行う）ことでプラグイン連携を実現している。
【００７６】
しかし、プラグイン連携機能には、プラグイン間において双方向に情報伝達を行うことで連携動作する構成も考えられる。つまり、連携先と連携元とが入れ替わる構成も考えられる。
【００７７】
以下には、変形例として、プラグイン間において双方向の情報伝達を行うプラグイン連携機能について説明する。
【００７８】
図９は、本変形例に係るプラグイン連携の動作例を示す図である。
本変形例に示すプラグイン連携機能では、例えば、図９に示すような、プラグイン間において双方向に情報伝達を行う連携動作を実現することができる。
【００７９】
まず、プラグインＰ１の画面Ｗ１には、プラグインＰ１のＵＩ部２０１により、識別子（ＩＤ）によりグループ化された３つの設定値（値１，値２，値３）が一覧表示されている。プラグインＰ１は、利用者による画面Ｗ１上の［追加］ボタン押下を受けて、新たな設定値を保存領域（データエリア）に追加する追加イベントを、ＵＩ部２０１からプラグインＰ２のＵＩ部２０２に通知する（図中の（１））。
【００８０】
プラグインＰ２は、追加イベントの通知を受けて、設定値を入力する画面Ｗ２を表示し、プラグインＰ１からプラグインＰ２へと画面が遷移する。プラグインＰ２は、利用者による画面Ｗ２上の識別子及び設定値（ＩＤ：００３，値１：Ｇ，値２：Ｈ，値３：Ｉ）入力と、［保存］ボタン押下とを受けて、ＵＩ部２０２から保存処理の指示を受け付けたロジック部１０２により、設定値を保存領域に追加・保存する（図中の（２））。その保存結果［成功／失敗］は、ロジック部１０２からＵＩ部２０２へと渡される（図中の（３））。その結果、ＵＩ部２０２は、保存結果［成功／失敗］及び保存内容［００３，Ｇ，Ｈ，Ｉ］を、保存結果イベントとして、プラグインＰ１のＵＩ部２０１に通知する（図中の（４））。
【００８１】
プラグインＰ１は、保存結果イベントの通知を受けて、追加された設定値を含む一覧画面Ｗ３を表示し、プラグインＰ２からプラグインＰ１へと画面が遷移する。これにより、プラグインＰ１の表示画面が更新される（画面Ｗ１→画面Ｗ３）。
【００８２】
図１０は、本変形例に係る情報処理装置１００が有する機能構成例を示す図である。
本変形例に係るプラグイン連携機能は、図７と図１０との比較からも分かるように、ＵＩ部２０の画面遷移制御部２１が、通知部２１１及び受信部２１２の両方を有している。本変形では、このような機能構成により、プラグイン間において双方向に情報伝達を行うことができる。
【００８３】
本変形例に係るプラグイン連携機能の処理手順は、次の通りである。
図１１は、本変形例に係るプラグイン連携の詳細な処理手順例を示すシーケンス図である。なお、図１１には、図９に示した連携動作時の処理手順例が示されている。
【００８４】
図１１に示すように、情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する入出力部２２１より、新たな設定値（データ）の追加命令（［追加］ボタン押下）を受け付ける（ステップＳ４０１）。入出力部２２１は、受け付けたデータ追加の通知をＵＩ部２０１が有する通知部２１１１に指示する（ステップＳ４０２）。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにより、データ追加イベントを通知する（ステップＳ４０３）。
【００８５】
通知部２１１１は、具体的に次のような処理を行う。通知部２１１１は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにイベントオブジェクト（ａｄｄＥｖｅｎｔ）を指定し呼び出す。その結果、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドは、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたリスナー（プラグイン２）に対して、指定イベントオブジェクトをブロードキャストする。このとき、メモリ上には、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたプラグインＰ２（連携先）が参照可能なライブラリ形式で、データ追加命令が定義されたイベントクラス（ａｄｄＥｖｅｎｔ｛ｘ｝）が生成される。
【００８６】
情報処理装置１００では、プラグインＰ２のＵＩ部２０２が有する受信部２１２２により、プラグインＰ１からのデータ追加通知を受信する（ステップＳ５０１）。このとき、受信部２１２２は、イベントクラスから定義されたデータ追加命令を取得する。
【００８７】
続いて、受信部２１２２は、イベント受信時の実行処理（ｉｎｐｕｔ）に従って、同ＵＩ部２０２が有する入出力部２２２に、識別子及び設定値の入力を受け付ける画面表示を指示する（ステップＳ５０２）。これにより、プラグインＰ１からプラグインＰ２へと画面遷移（画面１→２）が指示される。
【００８８】
入出力部２２２は、表示画面を介して入力された識別子及び設定値（入力情報）を受け付け（ステップＳ５０３）、受け付けた入力情報［００３，Ｇ，Ｈ，Ｉ］をプラグインＰ２のロジック部１０２が有する処理部１３２に渡し、保存処理の実行を指示する（ステップＳ５０４）。
【００８９】
処理部１３２は、受け取った入力情報を保存領域に保存し（ステップＳ５０５）、保存結果［成功］及び保存内容［ＩＤ：００３，値１：Ｇ，値２：Ｈ，値３：Ｉ］を、ＵＩ部２０２が有する通知部２１１２に渡し、実行結果の通知を指示する（ステップＳ５０６）。通知部２１１２は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにより、実行結果イベントを通知する（ステップＳ５０７）。
【００９０】
通知部２１１２は、具体的に次のような処理を行う。通知部２１１２は、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドにイベントオブジェクト（ｓａｖｅＥｖｅｎｔ）を指定し呼び出す。その結果、ｄｉｓｐａｔｃｈＥｖｅｎｔメソッドは、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたリスナー（プラグイン１）に対して、指定イベントオブジェクトをブロードキャストする。このとき、メモリ上には、イベントを受信するためにａｄｄＥｖｅｎｔＬｉｓｔｅｎｅｒメソッドを介して登録されたプラグインＰ１（連携先）が参照可能なライブラリ形式で、実行結果（結果［成功］の場合は保存内容）が定義されたイベントクラス（ｓａｖｅＥｖｅｎｔ｛００３，Ｇ，Ｈ，Ｉ｝）が生成される。
【００９１】
情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する受信部２１２１により、プラグインＰ２からの実行結果通知を受信する（ステップＳ６０１）。このとき、受信部２１２１は、イベントクラスから定義された実行結果を取得する。
【００９２】
続いて、受信部２１２１は、イベント受信時の実行処理（ｄｉｓｐｌａｙ）に従って、同ＵＩ部２０１が有する入出力部２２１に実行結果を渡し、実行結果を反映した画面表示を指示する（ステップＳ６０２）。これにより、プラグインＰ２からプラグインＰ１へと画面遷移（画面２→１）が指示される。
【００９３】
情報処理装置１００では、プラグインＰ１のＵＩ部２０１が有する入出力部２２１により、表示画面（設定値の一覧画面）が生成される（ステップＳ６０３）。その結果、表示装置１０２には、新たに追加された設定値を含む実行結果が反映されたプラグインＰ１の操作画面（画面１）が表示される。
【００９４】
＜まとめ＞
以上のように、本実施形態に係る情報処理装置１００によれば、連携元のプラグインＰ１のＵＩ部２０１から連携先のプラグインＰ２のＵＩ部２０２に対してロジック部１０２の処理結果を通知し、遷移後の画面表示を指示する。
【００９５】
これによって、本実施形態に係る情報処理装置１００では、ロジック部１０でなくＵＩ部２０により、プラグイン連携時の画面遷移が制御され、ロジック部１０による処理結果がＵＩ部２０を介して連携先へと伝達される。また、プラグイン連携時の情報伝達は、プラグイン間において、連携元から連携先への一方向だけでなく双方向でも行われる。
【００９６】
このように、本実施形態に係る情報処理装置１００では、プラグインＰが有するロジック部１０とＵＩ部２０との独立性が保たれた構成でプラグイン間の連携動作が行える。
【００９７】
ここまで、上記実施形態の説明を行ってきたが、上記実施形態に係る情報処理装置１００が有する「プラグイン連携機能」は、図を用いて説明を行った各処理手順を、動作環境（プラットフォーム）にあったプログラミング言語でコード化したプログラムが、ＣＰＵ１０６により実行されることで実現される。
【００９８】
上記プログラムは、コンピュータが読み取り可能な記録媒体１０３ａに格納することができる。上記記録媒体１０３ａには、例えば、フロッピー（登録商標）ディスク、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびにＳＤメモリカード（SD Memory Card）及びＵＳＢ（Universal Serial Bus）メモリなどがある。
【００９９】
よって、上記プログラムは、上記記録媒体１０３ａに記憶させることで、記録媒体１０３ａを読み取り可能なドライブ装置１０３などを介して情報処理装置１００にインストールすることができる。また、情報処理装置１００は、インタフェース装置１０７を備えていることから、インターネットなどの電気通信回線を用いて上記プログラムをダウンロードし、インストールすることもできる。
【０１００】
また、上記実施形態では、プラグインＰが有するＵＩ部２０の間で行うプラグイン連携時のイベント処理に、ＡｃｔｉｏｎＳｃｒｉｐｔ（Ｆｌａｓｈに使用されるプログラミング言語）のＥｖｅｎｔＤｉｓｐａｔｃｈｅｒクラスに属するメソッドを用いた場合について説明を行ったが、この限りでない。
【０１０１】
最後に、上記実施形態に挙げた形状や構成に、その他の要素との組み合わせなど、ここで示した要件に、本発明が限定されるものではない。これらの点に関しては、本発明の主旨をそこなわない範囲で変更することが可能であり、その応用形態に応じて適切に定めることができる。
【符号の説明】
【０１０２】
１０ ロジック部（プラグインロジック）
１１ 画面遷移制御部（ロジック部側）
１２ 認証部
１３ 処理部
２０ ＵＩ部（プラグインＵＩ）
２１ 画面遷移制御部（ＵＩ部側）
２１１ 通知部（１：プラグイン１，２：プラグイン２）
２１２ 受信部（１：プラグイン１，２：プラグイン２）
２２ 入出力部（１：プラグイン１，２：プラグイン２）
１００ 情報処理装置
１０１ 入力装置
１０２ 表示装置
１０３ ドライブ装置（ａ：記録媒体）
１０４ ＲＡＭ（揮発性の半導体メモリ）
１０５ ＲＯＭ（不揮発性の半導体メモリ）
１０６ ＣＰＵ（中央処理装置）
１０７ インタフェース装置（ＮＩＣ：Network I/F Card）
１０８ ＨＤＤ（不揮発性の記憶装置）
ＡＰ アプリケーション
Ｐｎ プラグイン
ＰＦ プラットフォーム
【先行技術文献】
【特許文献】
【０１０３】
【特許文献１】特開２００９−５４０２７号公報
【特許請求の範囲】
【請求項１】
複数のプラグインを有するアプリケーションが動作する情報処理装置であって、
前記プラグインが、プラグインの表示画面を生成するＵＩ（User Interface）部と、プラグインの機能を実現するための処理を行うロジック部と、を有し、
前記ＵＩ部が、同プラグインのロジック部による処理結果を他のプラグインに通知する通知手段、及び／又は前記処理結果を他のプラグインから受信する受信手段、を有し、
プラグイン間において、
連携元のプラグインが、
前記通知手段により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、
前記連携先のプラグインが、
前記受信手段により、前記通知手段が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインのＵＩ部により表示画面を生成することを特徴とする情報処理装置。
【請求項２】
前記通知手段は、
受信先として登録された連携先のプラグインが前記処理結果を取得可能な通知イベントを生成し、前記連携先のプラグインに対してブロードキャストすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信手段は、
前記通知手段によるブロードキャストにより受信した通知イベントから、連携元のプラグインのロジック部による処理結果を取得することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記連携先のプラグインは、
前記通知手段により、前記連携元のプラグインに対して、同プラグインのロジック部による処理結果を通知し、
前記連携元のプラグインは、
前記受信手段により、前記通知手段が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインのＵＩ部により表示画面を生成することを特徴とする請求項１ないし３のいずれか一項に記載の情報処理装置。
【請求項５】
プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有する複数のプラグインで構成されるアプリケーションが動作する情報処理装置におけるプラグイン連携方法であって、
プラグイン間において、
連携元のプラグインが、
同プラグインのＵＩ部により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、
前記連携先のプラグインが、
同プラグインのＵＩ部により、前記連携元のプラグインが通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成することを特徴とするプラグイン連携方法。
【請求項６】
プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有する複数のプラグインで構成されるアプリケーションが動作する情報処理装置におけるプラグイン連携プログラムであって、
コンピュータを、
プラグイン間において、
連携元のプラグインが、
同プラグインのＵＩ部により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、
前記連携先のプラグインが、
同プラグインのＵＩ部により、前記連携元のプラグインが通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成するように動作させるためのプラグイン連携プログラム。
【請求項７】
請求項６に記載のプログラムを記憶した、コンピュータが読み取り可能な記録媒体。
【請求項１】
複数のプラグインを有するアプリケーションが動作する情報処理装置であって、
前記プラグインが、プラグインの表示画面を生成するＵＩ（User Interface）部と、プラグインの機能を実現するための処理を行うロジック部と、を有し、
前記ＵＩ部が、同プラグインのロジック部による処理結果を他のプラグインに通知する通知手段、及び／又は前記処理結果を他のプラグインから受信する受信手段、を有し、
プラグイン間において、
連携元のプラグインが、
前記通知手段により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、
前記連携先のプラグインが、
前記受信手段により、前記通知手段が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインのＵＩ部により表示画面を生成することを特徴とする情報処理装置。
【請求項２】
前記通知手段は、
受信先として登録された連携先のプラグインが前記処理結果を取得可能な通知イベントを生成し、前記連携先のプラグインに対してブロードキャストすることを特徴とする請求項１に記載の情報処理装置。
【請求項３】
前記受信手段は、
前記通知手段によるブロードキャストにより受信した通知イベントから、連携元のプラグインのロジック部による処理結果を取得することを特徴とする請求項２に記載の情報処理装置。
【請求項４】
前記連携先のプラグインは、
前記通知手段により、前記連携元のプラグインに対して、同プラグインのロジック部による処理結果を通知し、
前記連携元のプラグインは、
前記受信手段により、前記通知手段が通知した処理結果を受信し、受信した処理結果に基づき、同プラグインのＵＩ部により表示画面を生成することを特徴とする請求項１ないし３のいずれか一項に記載の情報処理装置。
【請求項５】
プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有する複数のプラグインで構成されるアプリケーションが動作する情報処理装置におけるプラグイン連携方法であって、
プラグイン間において、
連携元のプラグインが、
同プラグインのＵＩ部により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、
前記連携先のプラグインが、
同プラグインのＵＩ部により、前記連携元のプラグインが通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成することを特徴とするプラグイン連携方法。
【請求項６】
プラグインの表示画面を生成するＵＩ部と、プラグインの機能を実現するための処理を行うロジック部と、を有する複数のプラグインで構成されるアプリケーションが動作する情報処理装置におけるプラグイン連携プログラムであって、
コンピュータを、
プラグイン間において、
連携元のプラグインが、
同プラグインのＵＩ部により、連携先のプラグインのＵＩ部に対して、同プラグインのロジック部による処理結果を通知し、
前記連携先のプラグインが、
同プラグインのＵＩ部により、前記連携元のプラグインが通知した処理結果を受信し、受信した処理結果に基づき、同プラグインの表示画面を生成するように動作させるためのプラグイン連携プログラム。
【請求項７】
請求項６に記載のプログラムを記憶した、コンピュータが読み取り可能な記録媒体。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【公開番号】特開２０１１−１５４４７２（Ｐ２０１１−１５４４７２Ａ）
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願番号】特願２０１０−１４６５４（Ｐ２０１０−１４６５４）
【出願日】平成２２年１月２６日（２０１０．１．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
【公開日】平成２３年８月１１日（２０１１．８．１１）
【国際特許分類】
【出願日】平成２２年１月２６日（２０１０．１．２６）
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＦＬＡＳＨ
【出願人】（０００００６７４７）株式会社リコー (37,907)
【Ｆターム（参考）】
[ Back to top ]