oh, thanks! i really misunderstood this point. i read your(?) article at
http://www.eclipsezone.com/articles/extensions-vs-services/ again and
found that i was a candidate for "common misconceptions" ..
thanks for opening my mind in this area ;-)
Toni
knowing this, a scalability comparism gets more interesting of cause ;-)
Neil Bartlett schrieb:
Toni,
Sorry but you were misinformed. Check out the package
org.eclipse.core.runtime.dynamichelpers, and the class
ExtensionTracker etc. Extensions certainly can be installed an
uninstalled dynamically.
A reason for this misconception is that, prior to Eclipse 3.0, the low
level runtime was non-OSGi based and could not handle dynamic
installation and uninstallation of bundles. The OSGi Service Layer
would also be non-dynamic if it didn't have the Module Layer and
Lifecycle Layer beneath it.
I would really like to discuss the specific concern of scalability,
rather than extensions vs services in general terms.
Regards,
Neil
On 30 Apr 2007, at 11:35, Toni Menzel wrote:
The last thing I heard from "Eclipse Extension Registry" is that it
does not provide dynamic bindung/unbinding at all.
It greatly benefits from caching bindings initially found but "polls"
the resources as needed (lazy resource provisioning).
But when it comes to really attach/detach OSGI Services the whole
registry needs a rebuild ("rebuild" might be wrong.. but at least it
is what is force for example when starting eclipse with -clean option)
This lack of dynamic behaviour makes this registry not comparable to
osgi services in my opinion. (i've heard that this is a concept from
pre-osgi times at eclipse 2.x)
if someone has more experience with this extension registry, please
clarify. I would like to know more about it, too ;-)
regards,
Toni
Neil Bartlett schrieb:
All,
A criticism that I have heard about the OSGi Service Layer,
particularly in discussions where it is compared with the Eclipse
Extension Registry, is that services "do not scale".
I would like to pin down exactly what is meant by this, and try to
quantify:
a) How bad the problem is, if it exists
b) Whether the problem can be fixed by an implementation, or is
intrinsic to the design
c) Whether and how the Eclipse Extension Registry achieves
better scalability.
The problem I have is that "scalability" can mean so many things.
For example it might mean that service registry lookup time becomes
unfeasible when the total number of services becomes very large.
It's difficult to see how a single lookup could be worse than
linear, so presumably the problem here is when lookups must be done
repeatedly -- and if this is the case, would some form of caching or
indexing help? Alternatively the problem might the dynamic "churn"
that the Spring-OSGi guys are so concerned about, i.e. when
dependent services are added and removed so quickly that a
significant amount of time is spent merely reacting to
ServiceListener events rather than doing useful work. But surely the
same problem would affect extensions?
It seems to me that one potential difference is scoping. In Eclipse,
an extension point defines a search scope, and the definer of the
extension point tends scans the registry for extensions contributed
to that particular point. This means an O(n) operation, with n being
the number of extensions contributed to the extension point.
With OSGi services, one can simulate a scope simply by adding a
registration property to the service. If the service registry knew
that this property was being used for scoping, then it could create
an index for it. However, the registry does not have such knowledge,
so in theory it needs to perform an O(n) search where n is the size
of the entire registry. However this is only a guess; I haven't
examined the source code or performed any benchmarks.
Would anybody like to comment on whether and why they think that
OSGi services either do or do not scale?
Thanks,
Neil
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
_______________________________________________
OSGi Developer Mail List
[email protected]
http://www2.osgi.org/mailman/listinfo/osgi-dev
