The XML used for the SCA Assembly model is structurally quite simple but very extensible; almost every element support extension elements and the specification itself uses substitution groups to allow specific types of implementation and binding to replace/extend key elements. Further, the model itself makes reference to artifacts located outside the XML instance (such as WSDL definitions, Java classes and other SCA artifacts like componentType sidefiles) that are needed to build up the complete representation of an application.
To handle this extensibility and the external artifacts, in Tuscany we have chose to use a streaming approach to parsing based on the Java StAX framework. Rather than load XML artifacts into objects using a data binding technology such as SDO or JAXB, the loader framework provides a mechanism for extension to register their willingness to parse any XML element. As the XML file is read, elements are dispatched to registered loaders who can then handle the stream in any way they choose. As part of processing the stream, they can also read any associated artifacts especially those that may be needed later during the configuration loading process (such as WSDL definitions).
To partipate in the loading process, an extension should provide a component that implements the StAXElementLoader interface and should register that component with the framework's StAXLoaderRegistry during initialization.
To add the loader to the runtime configuration a <component> definition is added in a SCA Assembly file:
The extension is added to the system by including this fragment on the classpath as a resource with the name system.fragment.
Loaders handle extensions' elements contained in SCA Assembly files. A loader is an implementation of StAXElementLoader that registers itself with the runtime's StAXLoaderRegistry. Extensions contribute loaders by including a <component> definition in a system.fragment file on their classpath.