FraSCAti Architectural Issues

FraSCAti startup

Problem : Instantiation of component fails. FraSCAti throws Factory Exception (Or a ProcessorException) and the deep cause is a ClassNotFoundException (eg : org.ow2.frascati.implementation.velocity.ImplementationVelocityFCscaPrimitiveFC43bfeb92). This is because the real time compiler (Eclipse JDTcore) is not enabled.

Solution : To avoid this problem, you have to add the Frascati runtime factory dependency in the project POM. eg :

<dependency>
    <groupId>org.ow2.frascati</groupId>
    <artifactId>frascati-runtime-factory</artifactId>
    <version>1.5-SNAPSHOT</version>
</dependency>

FraSCAti in Nuxeo Alternatives

See FraSCAti in Nuxeo Alternatives.

SCA application isolation in FraSCAti

FraSCAti allows to load each SCA application into a separate class loader. This is useful when SCA applications contain classes with same names.

// Instantiate FraSCAti
FraSCAti frascati = FraSCAti.newFraSCAti();
// Get its composite manager.
org.ow2.frascati.assembly.factory.api.CompositeManager compositeManager = frascati.getCompositeManager();

URL urlToJarOfAnScaApplication = new URL("file://..../...jar");
// Create a processing context with a new url class loader containing the jar
ProcessingContext processingContext = compositeManager.newProcessingContext(urlToJarOfAnScaApplication);
// Process the composite
domain.processComposite(new QName("nameOfTheScaComposite"), processingContext);

Warning: The JAR must not be in the classpath running FraSCAti, e.g., with Maven don't not declare a dependency to the jar.

About using SCA apps as deployment model

SCA applications :

• can be run on demand (command line, REST...),
• isolated classloaders

Using it as deployment model of Light applications also impacts their development model. As said at #28 Discovery by parsing SCA composite using FraSCAti parser, we have to package in its zip all referenced classes and composites :

• generic libraries (classes and composites) have to be put in the generic lib/ classloader
• referenced business classes (ex. java interfaces of services consumed - possibly WSDL also ?) have to be put in the zip, possibly on the fly
• and the same for "template business" classes and composites.
• If it were to scale up it would be bad (a lot of identical classes in memory), but given EasySOA Light's prototyping goals it is rather a safe choice. For others (EasiFab, OWT) other, modular (OSGi ?) models are more suited though.
• However that also means there is a clear distinction between developing an business app and developing a template app i.e. developing EasySOA itself, the last one's jars having to go in the lib/ directory.