Fractal Component Model

and its support in Java

Eric Bruneton, Theirry Coupaye,

Matthieu Leclercq, Vivien Quéma,
and Jean-Bernard Stefani

slides by Minhazur Rahman

 Agenda
• Motivation
• Fractal Component Model Overview
– Components and Bindings
– Levels of Control
– Type System
– Instantiation and Control
• JULIA
– Instantiation
– Mixin
– Interceptors
• Evaluation
– Qualitative
– Quantative
• Conclusion
 Component Based Software
• Development of Software by assembly of
pre-existing functional or logical software
components into larger pieces of software.
• Communication across the components
made possible with a well-defined interface
or interfaces for each component.
• Support pre-runtime adaptation in order to
suit arbitrary deployment environments.
• With meta-programming techniques can
hide complexity in handling non-functional
30/11/09
aspects in system eg. Fault tolerance. 3
 Problems with Existing Component
Based Frameworks
• Limited support for extension and
adaptation of the components as pointed out
by recent studies.
• Prevents dynamic introduction of different
control facilities for components such as its
non-functional aspects.
• Degree of configuration versus performance
and space consumption trade-offs are not an
Application Developer's prerogative.
30/11/09 4
 A possible solution in Fractal
• A hierarchical, extensible, reflective, open
Component Model to implement, deploy, and
manage complex software systems like
middleware.
• Supported in Java by means of an extensible
software framework
• Introspection and reconfiguration capabilities
to monitor, deploy, configure the system
• Extensible set of reflective capabilities
ranging from no reflective feature at all
30/11/09
(black box) to user-defined controllers. 5
 Components and their Bindings
• The Fractal component is composed of a
membrane and a content.
• Contents may be further composed of
components (nested) that eventually would
contain application specific code.
• Membrane provides a causal representation of
the contents that allows introspection and
reconfiguration of its features.
• Controllers in the membrane allow life-cycle
operations, and tuning of parameters that alter
behaviour of components.
30/11/09 6
 Components and their Bindings contd
• Membranes may have
interceptors that add
additional behaviour to
invocations.
• Communication across
components achieved by
primitive bindings (same
address space) and
composite bindings.
• Composite bindings may
be across arbitrary number
of interfaces, span
30/11/09
different address spaces. 7
 Shared Component
• An original feature of the
Fractal component model is
that a given component can be
included in several other
components. Such a
component is said to be shared
between these components.
• The Undo Component is
shared across Menu
Component & the Toolbar
component.
• In this way state may be shared
30/11/09 across components. 8
 Levels of Control
• Fractal being “open” allows arbitrary forms of
membranes with different control semantics
• As per specification lowest level of control is a
black box component comparable to POJO.
• At the next level is the Component interface
that enables clients to discover the other
interfaces.
• At higher levels of control Fractal can expose
increased introspection and intercession
capabilities via the controllers like
Attribute, Binding, Content, 
30/11/09 9

Life­cycle etc.
 Instantiation
• Fractal model defines factory components
that can create new components.
• Generic component factories can create
generic factories while standard factory
components may create only one kind of
factory
• Type of the component, and membrane
description are to be given to the Generic
component factory.
30/11/09 10
 JULIA Framework
• A small but efficient Java implementation of
Fractal.
• Facilitates the construction of software with Fractal
components by providing an extensible set of
control objects.
• Application developer free to choose and assemble
the controller implementations to build membrane
of component.
• Continuum from static configuration to dynamic
reconfiguration.
• Can be used on constrained JVMs like KVM,
30/11/09 11
J2ME.
 Data Structures in Julia
• Objects that implement
the component interfaces
are in white.
• Objects that implement
the membrane of the
component in dark and
light gray.
• Objects that implement
the content part of the
component (not shown
in the diagram).
30/11/09 12
 Instantiation of a JULIA Component
• creation of the component interface objects for
controller, interceptor, and content objects.
• initialization of the impl references between the
component interfaces objects and the content
controller, and interceptor objects;
• creation of an InitializationContext, and set
up of this context, with reference to the previous
objects;
• initialization of the controller and interceptor
objects by calling their initFcController
method,with the previous InitializationContext
object as parameter
30/11/09 13
 Motivation to use Mixin Classes
• Potential number of configurations vary
exponentially with the number of variants tunable
by controllers.
• To provide all of these implementations by class
inheritance are hence not feasible on account of the
effort involved and code duplication.
• AOP may be used to solve the above problem of
combinatorial explosion. But it means no new
control aspects can be added once the system is
built and delivered.
• Julia uses mixins to address these modularity and
extensibility issues.
30/11/09 14
 Use of Mixin in Julia
• Instead of using Java
extensions like Jam to
programming mixin
classes, they are written
in pure Java.
• the_super_prefix is
used to denote the
methods that are
overridden by the mixin
classes.
30/11/09 15
 Mixed Class Generated by ASM
• The mixed class
generated is shown.
• The mixed classes are
generated directly in byte
code form with ASM with
MixinClassGeneratorClass

30/11/09 16
 Interceptors in Julia
• Most control aspects also need a Non-generic hook
part that must be weaved into the user code.
• Unlike controller classes they are not handwritten,
but are generated in compiled form using ASM
library.
• The interceptor class generator takes the name of a
super class, the name of the application specific
interface, and one or more aspect code weavers.
• The output is the interceptor class which has
implemented all methods in the application specific
interface and transformations performed by the
aspect weavers
30/11/09 17
 Interceptors in Julia contd
• Several aspects can be managed by single
interceptor object.
• the aspects managed by the interceptor objects
of a given component can all be specified by the
user when the component is created.
• Julia has built in aspect weavers to manage life-
cycle and trace aspects.
• User may extend Julia by providing their own
code weavers.

30/11/09 18
 Support for constrained environments
• The size of the Julia runtime (35 kB, plus 10 kB for
the Fractal API), which is the only part of JULIA
(175 kB as a whole) that is needed at runtime, is
compatible with the capabilities of most
constrained environments.
• JULIA can be used in environments that do not
provide the Java Reflection API or the ClassLoader
class.
• The JULIA classes that are needed at runtime,
mostly use the J2ME, CLDC profile APIs.
30/11/09 19
 Quantitative Assessment
• Message-oriented middleware (MOM) is a
client/server infrastructure that generally relies on
asynchronous message-passing.
• Configurability in MOMs have not been
emphasised and usually implement fixed APIs.
• Hence, same functionalities an non-functional
properties for all event disseminations. This results
in reduced scalability and not suitable for
constrained environments.

30/11/09 20
 DREAM
• DREAM (Dynamic Reflective Asynchronous
Middleware), a framework for the construction of
asynchronous middleware, which relies on JULIA
was built.
• DREAM was used to re-engineer JORAM an
open-source Java Messaging Service (JMS)-
compliant middleware.
• DREAM composed of Fractal components and
expected to overcome limitations with typical
MOM vendors.

30/11/09 21
 A Bit About JORAM
• JORAM incorporates a 100% pure Java
implementation of JMS 1.1 APIs.
• JORAM comprises two parts: the ScalAgentMOM
and a software on top of it to support JMS.
• ScalAgent MOM is a fault-tolerant platform,
written in Java, and based on Autonomous software
agents.
• ScalAgent MOM was re-implemented using
DREAM with its main structure preserved.

30/11/09 22
 Configurability Assesment
• Non-functional properties could be easily changed.
Modifications that would have to be done by
recompiling the code could now be done at
runtime.
• Easier to change System configurations like the
number of active components encapsulated in the
agent server.

30/11/09 23
 Contrasts with Related work.
• Unlike Fractal most component models do not
share state.
• most component models provide little support for
reflection (apart from elementary introspection, as
exemplified by the second level of control in
FRACTAL.
• With respect to industrial standards such as EJB
and CCM, FRACTAL constitutes a more flexible
and open component model which does not embed
predetermined non-functional services. Moreover,
its is possible to implement such services in Fractal
30/11/09 24
 Contrasts with Related work contd

• Lack of tailoribility and extensibility in industry

standards like EJB, CCM. Fractal-Julia's
approach to component based software is not
via programming language extensions. Julia is
relatively small library with bytecode
generators/manipulators(ASM).

30/11/09 25
 Combining Aspects and Components

• Aspectualization or aspect based refactoring is

moving code that implements cross-cutting
concerns to aspects.
• The mixin and aspect code generators in Julia
provide a lightweight, flexible means to
aspectualization of components, i.e to isolate the
code implementing cross cutting concerns
across the component.
• However, Julia does not seek to provide as
much language support as AspectJ does.
30/11/09 26
 Conclusion
• Proponents of Fractal believe that static and
dynamic configurability that Fractal provides
would facilitate adaptability and manageability
• Among future work, the investigation of
dynamic aspect weaving techniques to augment
or complement the JULIA toolset would add
further flexibility
• Formal specification of the Fractal model and
assessing its correctness with formal verification
tools.
30/11/09 27
 Questions?

30/11/09 28