2016/05/28 - Apache Tuscany has been retired.

For more information, please explore the Attic.

 
 Apache Tuscany > Home > SCA Overview > SCA Java > Java SCA Documentation Menu > SCA Java Extension Development Guide > Mike Edwards Ramble through Adding a New Implementation Type User List | Dev List | Issue Tracker  

Adding a New Implementation Type

(3rd May 2007) I wanted to get the Spring and BPEL implementation types running with the new Tuscany Java core.  This page and those hung off it are my ramblings as I go through the process of building the code for these implementation types.  I hope that these will help anyone else who wants to venture down the path of adding an implementation type.  Beware that I make no claims as to great insight or special knowledge - and I am sure that there will be things that I have not tackled.

Associated with this general page is a set of pages dedicated to Adding the Spring Implementation Type where specifics relating to the Spring implementation are described.

Basic Information about code for an Implementation Type 

To create a Module which supports an Implementation Type, you need to implement a series of interfaces to the Tuscany Core, plus a set of related files which declare your Module to the core:

  • xxxModuleActivator class, which implements the ModuleActivator interface
  • ModuleActivator file, which identifies your code to the core as providing an implementation type
  • xxxArtifactProcessor class, which processes the XML for an implementation type
  • xxxImplementation class, which represents a runtime instance of the implementation type

How does a Implementation Type Module declare the XML that it handles?

For an Implementation Type module, it is going to handle the XML <implementation.xxx.../>, which is a child of a <component.../> element in the SCDL.

How does the module indicate to the core that it handles the <implementation.xxx.../> element?

This is done through the xxxArtifactProcessor.getArtifactType() method.  This method returns a QName for the XML element that it implements (ie a combination of the Namespace and the Element name of the element). 

The QName for the implementation type is read by the core at the point where the xxxModuleActivator class invokes the addArtifactProcessor() method of the StAXArtifactProcessorExtensionPoint for the core Registry, typically in the start() method of the xxxModuleActivator class.

xxxModuleActivator class

Called when the Tuscany core is loading, starting and stopping the Module which provides the implementation type.

Implements ModuleActivator interface, with 3 methods:

  • start
  • stop
  • getExtensionPoints

Of these, start() is the most important - it seems possible to get by with the other 2 doing nothing.

start() handles: 

  • Registration of xxxArtifactProcessor, which handles the <implementation.xxx..../> XML
  • Registration of xxxImplementationProviderFactory, which is a factory class for xxxImplementation objects, which represent instances of the implementation type provided by the module
  • Creation of objects of various types that may be required by the xxxArtifactProcessor and xxxImplementationProviderFactory classes

The ModuleActivator file 

This must be placed into the location

META-INF/services/org.apache.tuscany.spi.bootstrap.ModuleActivator

... this will be under the Resources directory in the source tree

The file contains the class name for the implementation of your Module, eg:

# Implementation class for the ExtensionActivator for module Foo
org.apache.tuscany.implementation.foo.FooModuleActivator

The xxxArtifactProcessor class

This class is called to deal with the XML in the composite SCDL files which relates to the implementation type - ie. <implementation.xxx.../>

The class is passed an XML stream which it reads and parses out the contents of the <implementation.xxx.../> element, principally getting all of the attributes and child elements (if present).

When the information has been parsed out, the xxxArtifactProcessor class creates an xxxImplementation object which represents the runtime component corresponding to the implementation.xxx element.

One other step that is handled by the xxxArtifactProcessor class is the resolution of the componentType for the component - teasing out its services, references and properties.  This is either done by introspection of the implementation (instance) or via reading a componentType side file. 

xxxImplementation class

The xxxImplementation class represents the implementation instances themselves.

Implements the org.apache.tuscany.assembly.Implementation interface 

website stats