The pluggability for Tuscany runtime extensions

[Raymond Feng <en...@gmail.com>]

Hi,

As the core moves away from using SCA composite to compose the Tuscany 
system, we have been working on a simple way to extend the Tuscany system.

1) Define an ExtensionPointRegistry [1]

public interface ExtensionPointRegistry {
    <T> void addExtensionPoint(Class<T> extensionPointType, T 
extensionPoint);
    <T> T getExtensionPoint(Class<T> extensionPointType);
    void removeExtensionPoint(Class extensionPoint);
}


The extension point is identified by the interface. It can be defined by the 
Tuscany system or runtime modules. For example, BuilderRegistry, 
IntrospectionRegistry are two extension points.

2) The pluggability is contracted by the following interface: [2]

public interface ModuleActivator {
    Map<Class, Object> getExtensionPoints();
    void start(ExtensionPointRegistry registry);
    void stop(ExtensionPointRegistry registry);
}

The ModuleActivator represents a module that plugs into the Tuscany system. 
Each module should provide an implementation [3] of this interface and 
registry the implementation class by defining a file named as 
"META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator" [4]. The 
content of the file is the class name of the implementation. The 
implementation class must have a no-arg constructor. The same instance will 
be used to invoke all the methods during different phases of the module 
activation.

During bootstraping, the following sequence will happen:

1) All the module activators will be discovered by the presence of 
META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator
2) The activator class is instantiated using the no-arg constructor.
3) ModuleActivator.getExtensionPoints() is invoked for all modules and the 
extension points contributed by each module are added to the 
ExtensionRegistry.
4) ModuleActivator.start(ExtensionRegistry) is invoked for all the modules. 
The module can then get interested extension points and contribute 
extensions to them. The contract bwteen the extension and extension point is 
private to the extension point. The extension point can follow similar 
patterns such as Registry. If it happens that one extension point has a 
dependency on another extension point, they can linked at this phase.

During shutting down, the stop() method is invoked for all the modules to 
perform cleanups. A module can choose to unregister the extension from the 
extension points.

Feedbacks are welcome.

Thanks,
Raymond

[1] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ExtensionPointRegistry.java

[2] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ModuleActivator.java

[3] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/java/org/apache/tuscany/container/crud/CRUDModuleActivator.java

[4] 
http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/resources/META-INF/services/org.apache.tuscany.spi.bootstrap.ModuleActivator 


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org

Re: The pluggability for Tuscany runtime extensions

[Jean-Sebastien Delfino <js...@apache.org>]

Raymond,

I think this is good and simple to understand, but have some further 
comments inline :)

Raymond Feng wrote:
> Hi,
>
> As the core moves away from using SCA composite to compose the Tuscany 
> system, we have been working on a simple way to extend the Tuscany 
> system.
>
> 1) Define an ExtensionPointRegistry [1]
>
> public interface ExtensionPointRegistry {
>    <T> void addExtensionPoint(Class<T> extensionPointType, T 
> extensionPoint);
>    <T> T getExtensionPoint(Class<T> extensionPointType);
>    void removeExtensionPoint(Class extensionPoint);
> }
>
>
> The extension point is identified by the interface. It can be defined 
> by the Tuscany system or runtime modules. For example, 
> BuilderRegistry, IntrospectionRegistry are two extension points.

I would suggest to rename these BuilderExtensionPoint and 
IntrospectionExtensionPoint. Also it would be good adopt a consistent 
pattern for these ExtensionPoints. I already started with some of these 
which now have addExtension / removeExtension methods.

>
> 2) The pluggability is contracted by the following interface: [2]
>
> public interface ModuleActivator {
>    Map<Class, Object> getExtensionPoints();
>    void start(ExtensionPointRegistry registry);
>    void stop(ExtensionPointRegistry registry);
> }

Do we really need a Map? or can this just be an array?

>
> The ModuleActivator represents a module that plugs into the Tuscany 
> system. Each module should provide an implementation [3] of this 
> interface and registry the implementation class by defining a file 
> named as 
> "META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator" 
> [4]. The content of the file is the class name of the implementation. 
> The implementation class must have a no-arg constructor. The same 
> instance will be used to invoke all the methods during different 
> phases of the module activation.
>

Can we rename this package to org.apache.tuscany.bootstrap. I think that 
we are currently using *.spi.* inconsistently, for example 
ModuleActivator is in an *.spi.* package, but BuilderRegistry is not, 
and both are SPIs, and finally all model interfaces are part of the SPIs 
too. Since pretty much all these interfaces are SPIs anyway, could we 
just remove the *.spi.* fragment?

> During bootstraping, the following sequence will happen:
>
> 1) All the module activators will be discovered by the presence of 
> META-INF/services/org.apache.tuscany.spi.bootstrp.ModuleActivator
> 2) The activator class is instantiated using the no-arg constructor.
> 3) ModuleActivator.getExtensionPoints() is invoked for all modules and 
> the extension points contributed by each module are added to the 
> ExtensionRegistry.
> 4) ModuleActivator.start(ExtensionRegistry) is invoked for all the 
> modules. The module can then get interested extension points and 
> contribute extensions to them. The contract bwteen the extension and 
> extension point is private to the extension point. The extension point 
> can follow similar patterns such as Registry. If it happens that one 
> extension point has a dependency on another extension point, they can 
> linked at this phase.
>
> During shutting down, the stop() method is invoked for all the modules 
> to perform cleanups. A module can choose to unregister the extension 
> from the extension points.
>
> Feedbacks are welcome.
>
> Thanks,
> Raymond
>
> [1] 
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ExtensionPointRegistry.java 
>
>
> [2] 
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/core-spi/src/main/java/org/apache/tuscany/spi/bootstrap/ModuleActivator.java 
>
>
> [3] 
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/java/org/apache/tuscany/container/crud/CRUDModuleActivator.java 
>
>
> [4] 
> http://svn.apache.org/repos/asf/incubator/tuscany/java/sca/modules/host-embedded/src/test/resources/META-INF/services/org.apache.tuscany.spi.bootstrap.ModuleActivator 
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
> For additional commands, e-mail: tuscany-dev-help@ws.apache.org
>
>


-- 
Jean-Sebastien


---------------------------------------------------------------------
To unsubscribe, e-mail: tuscany-dev-unsubscribe@ws.apache.org
For additional commands, e-mail: tuscany-dev-help@ws.apache.org