↓OSGiサービス・レジストリは公開されたJavaインターフェースのセットに基づいてBundleがObjectを共有レジストリへ公開することを可能にします。公開されたサービスは同じくレジストリ内に付属のサービス・プロパティーを持っています。Schema?を参照)を提供します。namespaceなど)のネストの内側から、又はトップレベルのOSGiエレメントから使用されます。namespaceを使用していることを表します。schemaをデフォルトのnamespaceとして使用する。schemaをインポートし、プレフィクスを設定しています。2.5がインポートされるように指定。Modulesエレメントが定義されたプレフィクスを使用しています(ここでは「osgi」)。namespaceをトップレベルのnamespaceと使用するには下記のように設定します。schemaのプレフィクスです。Modulesのスキーマがデフォルトnamespaceとして使用されます。beansスキーマがインポートされ、プレフィクスによってnamespaceに関連付けられています。2.5がインポートされています。Modulesのエレメントが使用できます。namespaceを使用することは特に便利です。「service」エレメントはOSGiサービスとして公開されているbeanを定義します。少なくとも、公開されるbeanとサービスの型をあらわすインターフェースを指定する必要があります。interface="com.xyz.MessageService"/>「beanToPublish」の名前でcom.xyz.MessageServiceのインターフェースを持つbeanを公開することをあらわします。公開されたサービスは「org.springframework.osgi.bean.name」内に登録された名前(この場合は「beanToPublish」)のサービス・プロパティーを持ちます。「service」エレメントで定義されたbeanは、org.osgi.framework.ServiceRegistration型であり、またOSGiサービス・レジストリに公開されたServiceRegistrationオブジェクトです。beanに名前(id)を与えることによって、必要であればServiceRegistrationオブジェクトを他のオブジェクトにインジェクションすることもできます。interface="com.xyz.MessageService"/>名前のついたbeanを公開する他の方法として、サービス・レジストリに公開されたbeanはサービス・エレメント内の匿名インナーbeanとしても定義されています。5.6「ServiceFactory」契約が尊重されます。scope」が導入されました。scope」のスコープを持ったbeanがOSGiサービスとして公開された場合、1つのbeanインスタンスがOSGiサービス・レジストリを通してそれを参照している各クライアントbundle(公開されているサービスを使用しているbundle)毎に作成されます。サービスを利用している側のbundleが停止されると、それ用に作成されて関連付けられていたインスタンスは破棄されます。scopeのbeanを定義するには単にbean設定のscope属性に設定するだけです。interface」という用語を「サービスの公開しているメソッドの仕様をあらわすもの」と定義しています。単位的にそれはJavaでのinterfaceをあらわしますが、しかし仕様はサービスobjectをclass名で登録することもサポートしています。よって、「サービス」という語句は「class」とも「interface」とも解釈できます。登録され公開されるサービスのインターフェースを定義する方法にはいくつかの選択肢があります。単純なメカニズムは、上記で示したように、完全修飾のinterface名を「interface」識別子に使うことです。複数のネストしたインターフェースの下でサービスを登録する場合、「interfaces」要素が「interface」属性の代わりに使用できます。</osgi:interfaces></osgi:service>「interface属性」と「interfaces要素」を同時に指定することはできません。どちらか一方だけを指定することができます。visibility)「auto-export」を使用している場合、サービスを公開しているbundleに見えている型だけが登録されることに注意するべきです。「auto-export="interfaces"」を使っている場合、親interfaceの「SI」が公開されているbundleのclasspathに乗っていない場合、「SI」はサーポートされるサービス・インターフェースとしては公開されません。同様に、もしサービスクラスがその親からSIを透過的に実装(implements)している場合、設定されているbundleがそのインターフェースをインポートしていなければ、そのクラスは公開されたサービスにとってはunknownとなります。これには率直に違和感を覚えるかもしれませんが、それは実際には「bundle製作者にクラス視界およびパスに対するコントロールを与える」というOSGiの最も強力な特徴のうちの1つです。詳細な説明はFAQを参照してください。「auto-export」属性を使えばobjectのclass階層とインターフェースを解析し、サービス・インターフェースの明示的な宣言をしないで済みます。「auto-export」属性は以下の4つのうちの1つの値をとります。サービスインターフェースの自動検出は行われず、「interface」属性か「interfaces」要素が代わりに必要になります。公開されるbeanのJavaインターフェースタイプでサービスが登録されます。type)と親typeでサービスが登録されます。公開されるbeanの実装型と親typeに加え、継承している全てのインターフェースでサービスが登録されます。「auto-export」と「interface(s)」は互いに排他的ではありません。必要とされるのであれば公表されるインターフェースによる最適な粒度コントロールの為に両方は同時に指定することもできます。前掲のオプションで十分な場合がほとんどだと思われます。サポートする全てのインターフェースをもって自動的に登録するには以下のように設定します。auto-export="interfaces"/>実装されているインターフェースは以下のようであるとします。{}すると、「SubInterface」をサポートするとして登録されたそのサービスは、OSGi内で「SuperInterface」をサポートする検索では該当しないものとして扱われます。この為、これは「interfaces」要素か「auto-export="interfaces"」のいずれかの使用により、明示的に登録されたサービスによってサポートされる全てのインターフェースを公開する事のベスト・プラクティスです。先に説明されているように、公開されるサービスは常に、beanが公開された名前で設定されたorg.springframework.osgi.bean.nameサービスプロパティーとともに登録されます。追加のサービスプロパティーは入れ子になった「service-properties」要素によって設定することが可能です。「service-properties」要素はサービスによって公開されるプロパティーの「key」と「value」の複数のペアを含みます。Filterによって認識可能な型である必要があります。5.5を参照してください。namespaceからの1つ以上の入れ子エントリーから成る必要があります。serviceに登録されたプロパティーを公開する為のサポートを含んでいます。Roadmap?を参照してください。↓Springはサービス・エレメントの明示的な依存性を管理します。サービスとして公開されるbeanが公開される前にコンストラクトされ、設定されることを確実にする、などの為です。サービスが他のコンポーネント(他のサービス・エレメントを含む)に対して暗黙的な依存性を持っていると、それはそのサービスが公開される前に完全に初期化が終わっていなくてはなりません。「depends-on」オプション属性はそれらの依存性を提供する為に使用されます。loaderを通して可視かを規定していません。loaderの明示的なコントロールを可能にします。それはサービス・エレメントの「context-class-loader」オプション属性を使用することによって設定できます。「context-class-loader」に使用可能な値は、「unmanaged(デフォルト)」と「service-provider」です。loaderから見えることを保障します。loaderを扱う為にproxyで置き換えられます。サービスが実装クラスを公開している場合、GCLIBライブラリが必要になります。ranking」を付加することもできます。5.2.5を参照)Bundleがサービス・レジストリ内からサービスを検索したときに条件に合致するサービスが複数ヒットした場合、ランキングが最も高いサービスが返されます。デフォルトのランキング値はゼロです。登録するサービスにランキングをつける場合は、「ranking」オプション属性を設定します。今までのまとめとして、下記のテーブルは属性の名前と取り有る値とその簡単な説明です。loaderがどのように振舞うかを設定します。loaderに対して特別な操作は行われません。pathにあるリソースが見えるように操作されます。Springが自動的にサービス・インターフェースの構造をコントロールできるようにします。デフォルトでこの機能は「disabled(無効)」に設定されています。「interfaces」を設定すると公開されているサービスの全てのJavaインターフェースが自動的に公開されます。classが公開されます。「all-class」が設定されると全てのJavaインターフェースとclassが公開されます。サービスのサービス・ランキングを指定します。デフォルトの値は0です。「service」要素で定義されたサービスはアプリケーション・コンテキストが最初に作成されたときにOSGiサービス・レジストリに登録されます。bundleがstopされアプリケーション・コンテキストが破棄されたときに自動的に登録解除されます。beanを通してそれを可能にします。beanをインラインで定義することによっても可能です。registration時とunregistration時のメソッドの定義。registration時のリスナー・メソッドだけの定義。オプションの「registration-method」属性と「unregistration-method」属性は登録時や登録解除時に実行されるメソッドの名前を設定します。登録時や登録解除時に呼び出されるcallbackメソッドは以下のどちらかのシグネチャと一致している必要があります。serviceProperties);「ServiceType」は他の公開されたサービスと互換性のあるサービス・インターフェースも使用できます。登録時のcallbackはサービスがスタートアップ時に最初に登録されたとき、またはその後に再登録されるときに実行されます。登録解除時のcallbackはその理由の如何にかかわらず、サービスの登録解除プロセス時に実行されます。(例えば含まれるbundleが停止するときなど)Spring-DMは宣言されている「ServiceType」引数型を使用し、それと互換性のあるサービスが登録/登録解除されたときにのみ実行されます。「serviceProperties」は登録/登録解除されるサービスの全てのプロパティーを保持するMapを表します。OSGi仕様との互換性を保つ為、この引数は必要であればjava.util.Dictionaryへキャストすることもできます。我々が思いとどまっている間、Spring-DMのインターフェース「org.springframework.osgi.service.exporter.OsgiServiceRegistrationListener」を「registration-method」や「unregistration-method」の代わりに実装することもできます。aware(Spring-DMを使用した・依存した)」コードになってしまいます。(これはPOJO哲学(POJO主義)に反する事です。)リスナーの為にOsgiServiceRegistrationListenerインターフェースを実装し、カスタムメソッドを宣言することもできます。この場合、最初にSpring-DMインターフェースのメソッドが実行され、次にカスタムメソッドが呼ばれます。supportsはOSGiサービス・レジストリを通してアクセスするサービスを表すbeanの定義をサポートします。この方法でOSGiサービスへの参照(references)はアプリケーションコンポーネントへインジェクションされます。lookup)はサポートに必要なサービス・インターフェース型の検索、それに加えてそれはレジストリ内に公開されているプロパティーと一致するもののオプショナルなフィルター設定に使用されます。あるシナリオにおいて、アプリケーションからの検索条件全てにに該当するある1つのサービスがあります。「reference」要素は要求する使用に該当する1つのサービスへの参照を定義します。pattern)」を使用している場合、全ての該当するサービスへの複数の参照が要求されます。Modulesはそれらの複数の参照をList、またはSetとして管理することをサポートします。「reference」要素はサービス・レジストリ内のあるサービスへの参照を定義するのに使用されます。与えられた条件に対して複数のサービスがマッチすることがあるので、結果得られるサービスは「BundleContext.getServiceReference」の呼び出し結果のサービスとなります。この事は最も高いランキング(ranking)が付けられたサービスが返されるか、もしくはランキングが同じであった場合、サービスIDが最も小さいサービス(フレームワークによって最初に登録されたサービス)が返されることを意味します。5を参照してください。「interface」属性はマッチしたサービスが実装しているべきインターフェースを定義します。例を挙げると、下記の設定は「messageService」beanを定義しており、それにはサービス・レジストリの中で「MessageService」インターフェースを実装しているサービスが選出されます。interface="com.xyz.MessageService"/>下記のサービス定義のように複数のインターフェースを定義したい場合、「interface」属性の変わりに入れ子に「interfaces」要素を定義します。</osgi:interfaces></osgi:reference>「interface」属性と「interfaces」要素を同時に使うことはできません。一度にどちらか一方です。「reference」要素によって宣言されたbeanは設定された、bundleから可視であるインターフェース全てを実装しています。proxying)」と呼ばれています。)登録されたサービス・インターフェースがJavaの(interfaceではなく)class型を含んでいる場合、SpringのAOP実装による3種類の型がサポートされます。(Springのリファレンス・ガイドを参照)端的に言えば、設定されたインターフェースがclass型だった場合(interfaceであっても)、CGLibライブラリが必須で、かつ「final」なメソッドはサポートされません。↓オプショナルな「filter」属性はOSGiフィルター定義を表し、サービス・レジストリ検索の条件をフィルターします。filter="(asynchronous-delivery=true)"/>上記は「MessageService」インターフェースを公開しているOSGiサービスで、かつ「asynchronous-delivery」がtrueに設定されているサービスにだけマッチします。「bean-name」属性は、「service」要素によって公開されたサービスによって自動的に付加される「bean-name」プロパティーにマッチするフィルター定義を表す便利なショートカットです。attribute「MessageService」インターフェースを公開し、かつ「org.springframework.osgi.bean.name」が「defaultMessageService」に設定されているOSGiサービスがマッチします。上記の設定は「Spring-DMが公開したbeanで、MessageServiceインターフェースを実装し、defaultMessageServiceという名前がついているもの」を意味します。declarations)Spring-DMが必須の依存性を検出する為に、全ての入れ子、もしくは内部の「reference」定義は自動生成された名前のトップレベルの「reference」定義に(自動的に)置き換えられます。「cardinality」属性はマッチするサービスが常に必要かどうかを定義します。「cardinality」値が「1..1」(デフォルト)である場合、該当のサービスが常に使用可能であることが求められます。「cardinality」値が「0..1」である場合、該当のサービスが常に使用可能である必要はないことを表します。reference)」とも言われ、デフォルトでは、アプリケーション・コンテキストの生成は参照先が満足されるまで保留されます。Note同じbundleから公開されているサービスを必須サービス参照として宣言することはエラーになります。このような設定はアプリケーション・コンテキスト生成時のデッドロックによるタイムアウトになります。「depends-on」属性は指定されている名前のbeanが生成されるまでサービス参照がサービス・レジストリで参照されないことを設定します。↓OSGiサービス・プラットフォーム・コア仕様(執筆時点での最新のバージョン4.1)では、サービス・レジストリからサービスが要求された時点でサービスのコンテキスト・クラス・ローダーからどの型やリソースが可視かという規定がされていません。Modulesはサービス使用時の明示的なコンテキスト・クラス・ローダーのコントロール機能を提供します。この機能はオプショナルな「context-class-loader」属性を「reference」要素に設定することによって行われます。サービス実行時に、コンテキスト・クラス・ローダーが呼び出し側bundleのclasspath上の型を可視であることを保障します。これはデフォルトの動作です。サービス実行時に、コンテキスト・クラス・ローダーがサービス側で公開されているbundleのclasspath上の型を可視であることを保障します。サービス実行時にコンテキスト・クラス・ローダーの操作を行いません。exporter)Spring-DMは公開側と参照側両方においてのコンテキスト・クラス・ローダー操作をサポートしています。通常は、Spring-DMが公開側と参照側両方で作動している場合、片方でこの機能(コンテキスト・クラス・ローダー操作)が有効になっているべきです。両側でこの機能が動作している場合、呼び出しチェインの最後のものが有効になります。この事は「公開側の設定が有効であれば常に公開側の操作が参照側の設定を上書きする」ということです。↓まとめとして、下記の表は「reference」要素に使用可能な属性名、使用可能な値とその意味を列挙します。<service>要素で公開されているbeanに自動的に付加される「bean-name」プロパティーに対するマッチ条件。サービス参照によりサービスが実行されたときにコンテキスト・クラス・ローダーに何が見えるかを設定する。デフォルトは「client」で、呼び出し側のbundleのclasspathが可視となります。別のオプションとして「service-provider」がありこれは公開側のbundleの、「unmanaged」はコンテキスト・クラス・ローダーに対して何も操作をしないことをそれぞれ表します。参照先のサービスに要求されるcardinality(=濃度?)を設定します。設定を省略した場合、デフォルトが適用されます。「1..1」を設定した場合、参照先のサービスの存在が必須になります。オペレーションが要求されたときの合計待ち時間(単位:ミリ秒)。省略された場合、デフォルトの値がセットされます。「reference」要素で定義されたbeanはアプリケーション・コンテキストの生存期間を通じて変化しません(オブジェクト参照は固定的なものとして続きます)。参照されたOSGiサービスはいつでも起動/終了する可能性があります。必須サービス参照(cardinality属性が「1..1」のもの)の生成は、マッチするサービスの状態が「Available」になるまでブロックされます。オプショナル・サービス参照(cardinality属性が「0..1」のもの)の場合、マッチするサービスの有無にかかわらず、参照は即座に生成されます。Modulesはその参照先のサービスを他のマッチするサービスで置き換えようと試みます。アプリケーションは背後のサービスの状態変化を登録してあるlistenerを通じて通知されるかもしれません。マッチするサービスがない場合、リファレンスは解決されていない状態になります。解決されていない必須サービスは参照が解決されるまでの間それに依存している公開サービス(サービスbean)をサービス・レジストリに対して登録解除状態にします。6.5を参照してください。未解決の参照に対してオペレーションが実行された場合(それがオプショナル参照か必須参照かに関わらず)、実行は参照が解決されるまでブロックされます。「reference」要素のオプション属性の「timeout」値(ミリ秒)はそれに対してタイムアウト時間を設定することができます。「timeout」値が設定され、かつマッチするサービスが時間までに解決されなければ、非チェック例外の「ServiceUnavailableException」が発生します。↓Spring-DMは自動的にマネージド(managed)OSGiサービスをサービス参照に変換できます。bean参照がインジェクションされることになっているプロパティーが「ServiceReference」型(参照にサポートされたサービス・インターフェースの代わりに)を持っていれば、サービス用のマネージドOSGi「ServiceReference」はサービス自体の代わりに注入されるでしょう。マネージド・サービスからServiceReferenceへの自動的な変換。マネージド・サービスが変換無しにインジェクションされる。Noteインジェクションされた「ServiceReference」はSpring-DMによって管理され、参照されている実体のOSGiサービス・インスタンスが変化したときに同時に変化します。APIは2つのインターフェースをオブジェクト順序付け方法の為に定義しています。「Comparable」と「Comparator」です。前者はオブジェクトにより自然な順序付けを提供する為に実装されます。String、Long、Dateが「Comparable」インターフェースの実装の良い例です。自然な順序付けとは異なる方法でソートする場合や、「Comparable」インターフェースを実装していないオブジェクトをソートする場合もあります。そのような場合の為に「Comparator」インターフェースは用意されました。ordering」の章を参照してください。mod_perl/2.0.11。