I will add to BJ's comments ... Both the OSGi service registry and the Eclipse extension registry are dynamic. The difference is the lifecycle of an OSGi service vs. an Eclipse extension/extension points.
Eclipse extensions/extension points exist as long as a bundle is RESOLVED. Extensions can also be added/removed dynamically by code but a vast majority are defined statically in a bundle's plugin.xml file. OSGi services can only exist while a bundle has a valid BundleContext (i.e while it is STARTING/ACTIVE/STOPPING) and they can be added/removed dynamically by code. Since a majority of extensions/extension points are defined statically in a bundle's plugin.xml the state of the extension registry depends directly on the set of RESOLVED bundles. If a framework implementation caches the bundle resolution state then the static extensions/extension points can be cached based on the bundle resolution cache. In Eclipse the extension registry cache is read before anything in the system touches the extension registry to add a listener or query an extension point. The extension registry cache is populated at startup without sending a single event. The OSGi service registry cannot be cached this way. From one launch of the framework to the next there is no way to cache the service registry. Service events MUST be published for every service that is added/removed/modified to the registry. This makes performance of the event delivery bus essential for ServiceEvents. In Equinox we have done some investigation in this area in https://bugs.eclipse.org/bugs/show_bug.cgi?id=151645 In Eclipse one of our top priorities is startup time. During startup we would like to avoid an "event storm" while resurrecting an extension registry with 1000s of extension points and 10000s of extensions. This is done by caching a static copy the extension registry on shutdown. I imagine if you measured the "dynamic" performance of the OSGi service registry vs. the Eclipse extension registry you would find issues with the "dynamic" performance of the extension registry. But in practice the set of bundles installed in Eclipse is constant so we do not focus on the dynamic performance of the extension registry as much. The OSGi registry is always dynamically populated at startup and the framework must publish all the service events while it is populated. Any time you are dealing with large numbers of events and large numbers of listeners there is potential for performance issues. We have a similar issue in EventAdmin in bug https://bugs.eclipse.org/bugs/show_bug.cgi?id=183883. Tom BJ Hargrave/Austin/[EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 04/30/2007 08:05 AM Please respond to OSGi Developer Mail List <[email protected]> To OSGi Developer Mail List <[email protected]> cc Subject Re: [osgi-dev] Scalability of OSGi Services The basic "issue" is that OSGi services only exist when the bundle has been activated (STARTING | ACTIVE | STOPPING). They require the bundle to execute, create the service object and register it. (vanilla service layer without something like Declarative Service, Spring OSGi, iPOJO, etc). So if you have 1000 bundle and 10000 services, there is a lot of work to be done to get those 10000 service all registered. Eclipse Extension point are just data (despite other possible opinions, the extension registry holds no live objects, it only provides helpers to converts a class name into live objects, but running code must call these helpers). You can think of the extension registry as a large DOM with many bundles contributing document snippets to the overall DOM. Since the DOM only contains data, which is very simple to persist, and is defined by static files (plugin.xml), once the DOM is constructed, it can be quickly serialized and deserialized. So a system of 1000 bundles and 10000 extension can be deserialized without loading any code from the 1000 bundles. Also, since they are just data, a bundle only need to be RESOLVED for its contribution to the DOM to be active. Thus Eclipse Extension Points "scale better". But you are comparing grapefruits to oranges. Yes they look rather similar, but they taste different. They are different tools in the arsenal of the programmer. Jeff McAffer did a presentation at EclipseCon 2006 on this and I have started the "definitive" :-) paper on this topic but have not yet finished. I only seem to make any progress when offline and stuck in an airplane... Well JavaOne is coming up, maybe I will make some more progress on the paper :-) BJ Hargrave Senior Technical Staff Member, IBM OSGi Fellow and CTO of the OSGi Alliance [EMAIL PROTECTED] office: +1 386 848 1781 mobile: +1 386 848 3788 _______________________________________________ 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
