Fractal is a modular, extensible and programming language agnostic component model that can be used to design, implement, deploy and reconfigure systems and applications, from operating systems to middleware platforms and to graphical user interfaces. The goal of Fractal is to reduce the development, deployment and maintenance costs of software systems in general, and of ObjectWeb projects in particular.
The Fractal component model has the following important features:
- recursivity : components can be nested in composite components (hence the "Fractal" name).
- reflectivity : components have full introspection and intercession capabilities.
- component sharing : a given component instance can be included (or shared) by more than one component. This is useful to model shared resources such as memory manager or device drivers for instance.
- binding components : a single abstraction for components connections that is called bindings . Bindings can embed any communication semantics from synchronous method calls to remote procedure calls
- execution model independance : no execution model is imposed. In that, components can be run within other execution models than the classical thread-based model such as event-based models and so on.
- open : extra-functional services associated to a component can be customized through the notion of a control membrane.
• components (type) definition and configuration (instantiation);
• runtime management including dynamic reconfiguration.
The Fractal specification is the foundation of Fractal. It defines the component model and the Application Programming Interface (API), i.e. the Fractal programming model. The Fractal component model provides a homogeneous vision of software systems structure with a few but well defined concepts and exhibits distinguishing features such as recursion with sharing and reflection. These features allow:
• A uniform management of both so-called business and technical components;
• A uniform management of resources (data, caches, pools, protocols, connections…), activities (threads, transactions, processes…) and domains (security, persistence…);
• And finally a possible component-based approach throughout the software lifecycle: development, deployment, and production (runtime management).
The Fractal Model
The Fractal Component Model can be seen as a recursive and reflexive extension of an ODP-like
object model:
• Components can only interact with their environment through operations at identified access points called interfaces which can be of two main sorts: server (provided) and client (required). Some bindings must be established between components (more precisely between their interfaces) so that they can interact. Bindings are communication paths than can be local, distributed, secured… Component interfaces are kept separate from implementations, and bindings are exteriorized from components so as to support flexibility.
• The model is fully recursive. A component is composed out of two parts: a controller and content. The content of a component is composed of (a finite number of) other components, which are under the control of (the controller of) the enclosing component. The model allows components to appear at an arbitrary level. The recursion ends up with components with an empty content that directly encapsulate objects. Recursion is crucial with respect to the scalability of component-based systems.
• The model allows for component sharing. Different components may have overlapping content: hence a component may be shared by several distinct enclosing components. The exact semantics of the resulting configuration is determined by an encompassing component that encloses all the relevant components in the configuration.
• The model is fully reflexive. It allows a programmatic manipulation of software architectures. Fractal components are runtime entities (they are manifest during system execution) that exhibit introspection and
intercession capabilities: they provide (meta)information and constructs which allow applications to dynamically access and manipulate their structure – expressed in terms of containment and binding relationships – and behaviour.
Framework Implementations
Fractal is not a product. It should be understood as an architectural abstract framework used as a
basis for a family of concrete frameworks. A concrete Fractal framework is made of the Fractal
interface as defined by the Fractal Specification, together with a Fractal implementation. Distinct
framework providers may provide concurrent implementations. Fractal comes with a Reference
Implementation in Java (named Julia) that can be used to check the compliance of alternative Fractal
Implementations or Fractal Systems (i.e. built upon Fractal).
Framework Extensions
Various kinds of framework extensions may eventually be incorporated in Fractal:
• Configuration extensions based on languages and tools such as graphical point-and-click
component configuration and deployment tools, Architecture Description Languages (ADL),
persistent component repositories…
• Composition extensions such as behavioural composition, contractual composition. Recall
that the basic composition mechanism based on containment relationships and bindings as
defined by the Fractal Component Model is referred to as structural composition.
• Management extensions such as models, languages and associated administration tools
for supervision, diagnosis…
Framework Specialisations
Various personalities may be eventually defined and incorporated in Fractal such as JMX, EJB, CCM or Web Services. As in Jonathan, a personality is a set of normalised Application Programming Interfaces (API).
