Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Equinox » OSGI Service vs Plugin extension point
OSGI Service vs Plugin extension point [message #111377] Tue, 03 June 2008 03:22 Go to next message
Roland Tepp is currently offline Roland Tepp
Messages: 336
Registered: July 2009
Senior Member
Hi everybody,

I have just recently come to learn and appreciate the elegance of OSGI
services. I like them a lot and see many places where I would rather use
services instead of extension points as I've done so far.

However, there are questions of service discovery and activation that
make me weary of services.

That is - if I have a plugin that provides an implementation of a
service, how do I make sure that the service gets loaded.

As much as I understand of services - a service can only become
available, when the bundle it is contained in, instantiates and
registers the service. How do I ensure that the bundle that contains the
service gets loaded?

On the other hand - providing the extension point always implies code
specifically reading the plug-in extension registry and instantiating
the classes defined in the extension definition. This involves a lot
less magic than service activation and is much easier to understand and
follow.

I guess what I am heading at with my question is - what are the best
practices and recommendations of designing and implementing an
extensible service oriented platform in OSGI?

How can I ensure that certain services are started on platform startup,
while still allowing the implementations of these services to be
pluggable by replacing the bundle in deployment.

Better yet, I want to have some services that are only available when
their defining bundle is deployed and be ignored otherwise...

--
Roland Tepp
Re: OSGI Service vs Plugin extension point [message #111675 is a reply to message #111377] Tue, 10 June 2008 09:23 Go to previous messageGo to next message
Kees Pieters is currently offline Kees Pieters
Messages: 24
Registered: July 2009
Junior Member
Hi Roland,

I have been facing the same problems, and my own estimation is that OSGI services are still quite young and need to mature a bit more.
From my own experiences (which are probably not going to be best practices), I have come to rely on the default activations of plugins, so if something goes wrong there, then I treat it as a big failure.
Secondly the activation sequence of plugins can help you to ensure that certain plugins are started before others. This is also quite reliable.
Thirdly -and this is where I leave best OSGI practices, I guess-, is that I have made some service helpers that run in a separate thread, that wait for services to be registered. This way I can include time-outs when services fail to register and I can gracefully terminate equinox, or conversely decide that it is ok to keep monitoring (which is seldom the case, by the way).
The helpers implement Callable or Runnable interfaces, and basically do little more than wait until a service returns a non-null value.
The way things will probably be going is that there will be extensions that represent OSGI services. This way you can check beforehand what services will be available (through the extension registry) and then make informed decisions on the actual starting of services. Currently you would have to implement this yourself (I believe).

Maybe this may help you in your quest!

Kees
Re: OSGI Service vs Plugin extension point [message #111704 is a reply to message #111675] Tue, 10 June 2008 11:07 Go to previous messageGo to next message
Danail Nachev is currently offline Danail Nachev
Messages: 110
Registered: July 2009
Senior Member
If you are using services, you need to make sure that the bundle which
is supposed to register the service is in ACTIVE state. You can use the
osgi.bundles property to specify which bundles are to be active after
startup.

You may want to check out the Declarative Services specification, part
of the OSGi spec. They provide similar mechanism to extension points -
they register/fetch references to services via declarative approach.

BR,
Danail

Kees Pieters wrote:
> Hi Roland,
>
> I have been facing the same problems, and my own estimation is that OSGI services are still quite young and need to mature a bit more.
> From my own experiences (which are probably not going to be best practices), I have come to rely on the default activations of plugins, so if something goes wrong there, then I treat it as a big failure.
> Secondly the activation sequence of plugins can help you to ensure that certain plugins are started before others. This is also quite reliable.
> Thirdly -and this is where I leave best OSGI practices, I guess-, is that I have made some service helpers that run in a separate thread, that wait for services to be registered. This way I can include time-outs when services fail to register and I can gracefully terminate equinox, or conversely decide that it is ok to keep monitoring (which is seldom the case, by the way).
> The helpers implement Callable or Runnable interfaces, and basically do little more than wait until a service returns a non-null value.
> The way things will probably be going is that there will be extensions that represent OSGI services. This way you can check beforehand what services will be available (through the extension registry) and then make informed decisions on the actual starting of services. Currently you would have to implement this yourself (I believe).
>
> Maybe this may help you in your quest!
>
> Kees
Re: OSGI Service vs Plugin extension point [message #111798 is a reply to message #111704] Thu, 12 June 2008 05:55 Go to previous messageGo to next message
Roland Tepp is currently offline Roland Tepp
Messages: 336
Registered: July 2009
Senior Member
Hi Danail and Kees,

Thanks for you answers.

Danail - does using declarative services somehow mean that my declared
services will be automagically activated (along with the bundles they're
declared/implemented in)?

Or do I still have to "activate" the bundles with osgi.bundles property
in order for them to be started?

If it is the latter, then the only benefit I can see from using declared
vs. coded services is that starting/stopping declared services is
handled by the framework and I do not have to write explicit bundle
activator code to manage all that.

Danail Nachev kirjutas mulle midagi seesugust:
> If you are using services, you need to make sure that the bundle which
> is supposed to register the service is in ACTIVE state. You can use the
> osgi.bundles property to specify which bundles are to be active after
> startup.
>
> You may want to check out the Declarative Services specification, part
> of the OSGi spec. They provide similar mechanism to extension points -
> they register/fetch references to services via declarative approach.
>
> BR,
> Danail
>
> Kees Pieters wrote:
>> Hi Roland,
>>
>> I have been facing the same problems, and my own estimation is that OSGI services are still quite young and need to mature a bit more.
>> From my own experiences (which are probably not going to be best practices), I have come to rely on the default activations of plugins, so if something goes wrong there, then I treat it as a big failure.
>> Secondly the activation sequence of plugins can help you to ensure that certain plugins are started before others. This is also quite reliable.
>> Thirdly -and this is where I leave best OSGI practices, I guess-, is that I have made some service helpers that run in a separate thread, that wait for services to be registered. This way I can include time-outs when services fail to register and I can gracefully terminate equinox, or conversely decide that it is ok to keep monitoring (which is seldom the case, by the way).
>> The helpers implement Callable or Runnable interfaces, and basically do little more than wait until a service returns a non-null value.
>> The way things will probably be going is that there will be extensions that represent OSGI services. This way you can check beforehand what services will be available (through the extension registry) and then make informed decisions on the actual starting of services. Currently you would have to implement this yourself (I believe).
>>
>> Maybe this may help you in your quest!
>>
>> Kees

--
Roland Tepp
Re: OSGI Service vs Plugin extension point [message #111804 is a reply to message #111798] Thu, 12 June 2008 07:12 Go to previous messageGo to next message
Danail Nachev is currently offline Danail Nachev
Messages: 110
Registered: July 2009
Senior Member
Roland,

You'll need to make sure the bundles are activated, but:

1) you don't need explicit registration code
2) your components/services are lazy initialized - which is one of the
big advantages of extension registry over service registry and it is
mitigated by this
3) the complexity of dealing with service registry dynamics are either
hidden in the DS implementation itself (static references) or they are
greatly simplified (dynamic references).

BR,
Danail

Roland Tepp wrote:
> Hi Danail and Kees,
>
> Thanks for you answers.
>
> Danail - does using declarative services somehow mean that my declared
> services will be automagically activated (along with the bundles they're
> declared/implemented in)?
>
> Or do I still have to "activate" the bundles with osgi.bundles property
> in order for them to be started?
>
> If it is the latter, then the only benefit I can see from using declared
> vs. coded services is that starting/stopping declared services is
> handled by the framework and I do not have to write explicit bundle
> activator code to manage all that.
>
> Danail Nachev kirjutas mulle midagi seesugust:
>> If you are using services, you need to make sure that the bundle which
>> is supposed to register the service is in ACTIVE state. You can use the
>> osgi.bundles property to specify which bundles are to be active after
>> startup.
>>
>> You may want to check out the Declarative Services specification, part
>> of the OSGi spec. They provide similar mechanism to extension points -
>> they register/fetch references to services via declarative approach.
>>
>> BR,
>> Danail
>>
>> Kees Pieters wrote:
>>> Hi Roland,
>>>
>>> I have been facing the same problems, and my own estimation is that
>>> OSGI services are still quite young and need to mature a bit more.
>>> From my own experiences (which are probably not going to be best
>>> practices), I have come to rely on the default activations of
>>> plugins, so if something goes wrong there, then I treat it as a big
>>> failure.
>>> Secondly the activation sequence of plugins can help you to ensure
>>> that certain plugins are started before others. This is also quite
>>> reliable. Thirdly -and this is where I leave best OSGI practices, I
>>> guess-, is that I have made some service helpers that run in a
>>> separate thread, that wait for services to be registered. This way I
>>> can include time-outs when services fail to register and I can
>>> gracefully terminate equinox, or conversely decide that it is ok to
>>> keep monitoring (which is seldom the case, by the way).
>>> The helpers implement Callable or Runnable interfaces, and basically
>>> do little more than wait until a service returns a non-null value.
>>> The way things will probably be going is that there will be
>>> extensions that represent OSGI services. This way you can check
>>> beforehand what services will be available (through the extension
>>> registry) and then make informed decisions on the actual starting of
>>> services. Currently you would have to implement this yourself (I
>>> believe).
>>>
>>> Maybe this may help you in your quest!
>>>
>>> Kees
>
Re: OSGI Service vs Plugin extension point [message #112005 is a reply to message #111804] Fri, 13 June 2008 03:08 Go to previous messageGo to next message
Roland Tepp is currently offline Roland Tepp
Messages: 336
Registered: July 2009
Senior Member
Okay,

But what about referencing these services from the runtime code?

I still need a handle on BundleContext to get my hands on the service
instance (or service tracker).

Which implies that I'll have to scatter explicit references to bundle
activators throughout my code - which I am not really a big fan of.

When moving classes or packages between bundles or splitting bundles,
there is scores of manual error prone work to do to re associate classes
with their new bundle activators (I've been through that and I must say,
I've developed somewhat of an allergy towards it)


Danail Nachev kirjutas mulle midagi seesugust:
> Roland,
>
> You'll need to make sure the bundles are activated, but:
>
> 1) you don't need explicit registration code
> 2) your components/services are lazy initialized - which is one of the
> big advantages of extension registry over service registry and it is
> mitigated by this
> 3) the complexity of dealing with service registry dynamics are either
> hidden in the DS implementation itself (static references) or they are
> greatly simplified (dynamic references).
>
> BR,
> Danail
>
> Roland Tepp wrote:
>> Hi Danail and Kees,
>>
>> Thanks for you answers.
>>
>> Danail - does using declarative services somehow mean that my declared
>> services will be automagically activated (along with the bundles they're
>> declared/implemented in)?
>>
>> Or do I still have to "activate" the bundles with osgi.bundles property
>> in order for them to be started?
>>
>> If it is the latter, then the only benefit I can see from using declared
>> vs. coded services is that starting/stopping declared services is
>> handled by the framework and I do not have to write explicit bundle
>> activator code to manage all that.
>>
>> Danail Nachev kirjutas mulle midagi seesugust:
>>> If you are using services, you need to make sure that the bundle which
>>> is supposed to register the service is in ACTIVE state. You can use the
>>> osgi.bundles property to specify which bundles are to be active after
>>> startup.
>>>
>>> You may want to check out the Declarative Services specification, part
>>> of the OSGi spec. They provide similar mechanism to extension points -
>>> they register/fetch references to services via declarative approach.
>>>
>>> BR,
>>> Danail
>>>
>>> Kees Pieters wrote:
>>>> Hi Roland,
>>>>
>>>> I have been facing the same problems, and my own estimation is that
>>>> OSGI services are still quite young and need to mature a bit more.
>>>> From my own experiences (which are probably not going to be best
>>>> practices), I have come to rely on the default activations of
>>>> plugins, so if something goes wrong there, then I treat it as a big
>>>> failure.
>>>> Secondly the activation sequence of plugins can help you to ensure
>>>> that certain plugins are started before others. This is also quite
>>>> reliable. Thirdly -and this is where I leave best OSGI practices, I
>>>> guess-, is that I have made some service helpers that run in a
>>>> separate thread, that wait for services to be registered. This way I
>>>> can include time-outs when services fail to register and I can
>>>> gracefully terminate equinox, or conversely decide that it is ok to
>>>> keep monitoring (which is seldom the case, by the way).
>>>> The helpers implement Callable or Runnable interfaces, and basically
>>>> do little more than wait until a service returns a non-null value.
>>>> The way things will probably be going is that there will be
>>>> extensions that represent OSGI services. This way you can check
>>>> beforehand what services will be available (through the extension
>>>> registry) and then make informed decisions on the actual starting of
>>>> services. Currently you would have to implement this yourself (I
>>>> believe).
>>>>
>>>> Maybe this may help you in your quest!
>>>>
>>>> Kees

--
Roland Tepp
Re: OSGI Service vs Plugin extension point [message #112098 is a reply to message #112005] Mon, 16 June 2008 03:43 Go to previous message
Danail Nachev is currently offline Danail Nachev
Messages: 110
Registered: July 2009
Senior Member
You are correct, you'll need to get hold of BundleContext and use it for
service instance retrieving. It is a question of good design to arrange
your code, so that there aren't references to BundleActivator all over
your code. Perhaps, the best thing is to use dependency injection
(dealing with services is done in BundleActivator and related classes).
The remaining classes don't care how they receive their dependencies.

Or

Use DS, which takes care of this for you.

BR,
Danail

Roland Tepp wrote:
> Okay,
>
> But what about referencing these services from the runtime code?
>
> I still need a handle on BundleContext to get my hands on the service
> instance (or service tracker).
>
> Which implies that I'll have to scatter explicit references to bundle
> activators throughout my code - which I am not really a big fan of.
>
> When moving classes or packages between bundles or splitting bundles,
> there is scores of manual error prone work to do to re associate classes
> with their new bundle activators (I've been through that and I must say,
> I've developed somewhat of an allergy towards it)
>
>
> Danail Nachev kirjutas mulle midagi seesugust:
>> Roland,
>>
>> You'll need to make sure the bundles are activated, but:
>>
>> 1) you don't need explicit registration code
>> 2) your components/services are lazy initialized - which is one of the
>> big advantages of extension registry over service registry and it is
>> mitigated by this
>> 3) the complexity of dealing with service registry dynamics are either
>> hidden in the DS implementation itself (static references) or they are
>> greatly simplified (dynamic references).
>>
>> BR,
>> Danail
>>
>> Roland Tepp wrote:
>>> Hi Danail and Kees,
>>>
>>> Thanks for you answers.
>>>
>>> Danail - does using declarative services somehow mean that my declared
>>> services will be automagically activated (along with the bundles they're
>>> declared/implemented in)?
>>>
>>> Or do I still have to "activate" the bundles with osgi.bundles property
>>> in order for them to be started?
>>>
>>> If it is the latter, then the only benefit I can see from using declared
>>> vs. coded services is that starting/stopping declared services is
>>> handled by the framework and I do not have to write explicit bundle
>>> activator code to manage all that.
>>>
>>> Danail Nachev kirjutas mulle midagi seesugust:
>>>> If you are using services, you need to make sure that the bundle which
>>>> is supposed to register the service is in ACTIVE state. You can use the
>>>> osgi.bundles property to specify which bundles are to be active after
>>>> startup.
>>>>
>>>> You may want to check out the Declarative Services specification, part
>>>> of the OSGi spec. They provide similar mechanism to extension points -
>>>> they register/fetch references to services via declarative approach.
>>>>
>>>> BR,
>>>> Danail
>>>>
>>>> Kees Pieters wrote:
>>>>> Hi Roland,
>>>>>
>>>>> I have been facing the same problems, and my own estimation is that
>>>>> OSGI services are still quite young and need to mature a bit more.
>>>>> From my own experiences (which are probably not going to be best
>>>>> practices), I have come to rely on the default activations of
>>>>> plugins, so if something goes wrong there, then I treat it as a big
>>>>> failure.
>>>>> Secondly the activation sequence of plugins can help you to ensure
>>>>> that certain plugins are started before others. This is also quite
>>>>> reliable. Thirdly -and this is where I leave best OSGI practices, I
>>>>> guess-, is that I have made some service helpers that run in a
>>>>> separate thread, that wait for services to be registered. This way I
>>>>> can include time-outs when services fail to register and I can
>>>>> gracefully terminate equinox, or conversely decide that it is ok to
>>>>> keep monitoring (which is seldom the case, by the way).
>>>>> The helpers implement Callable or Runnable interfaces, and basically
>>>>> do little more than wait until a service returns a non-null value.
>>>>> The way things will probably be going is that there will be
>>>>> extensions that represent OSGI services. This way you can check
>>>>> beforehand what services will be available (through the extension
>>>>> registry) and then make informed decisions on the actual starting of
>>>>> services. Currently you would have to implement this yourself (I
>>>>> believe).
>>>>>
>>>>> Maybe this may help you in your quest!
>>>>>
>>>>> Kees
>
Previous Topic:missing constraint import package sun.rmi.registry
Next Topic:change 'plugins' dir name
Goto Forum:
  


Current Time: Wed Jul 30 07:13:50 EDT 2014

Powered by FUDForum. Page generated in 0.02897 seconds