FRACTAL ADL
vs. SOFA CDL
presentation prepared by
Tomáš Opluštil
December 2003
materials used include Fractal ADL Tutorial, Simple Fractal ADL Tutorial,
Fractal ADL API documentations and examples within the Fractal distribution
– all of them can be found at http://fractal.objectweb.org
SOFA vs. Fractal – General Remarks
Fractal and SOFA: similar abstractions,
different background and primary goals
SOFA – support of distributed computing, CORBA
inspiration
o language independent, modules, specification
and implementation versioning, global interface
and implementation repositories, massive code
generation, connectors, complex deployment
descriptors, behavior protocols
o Fractal – practical serviceability first, with minimal
additional effort
everything optional, basic capabilities only –
with optional extensions, minimum additional
files, no user-editable generated files, strong
focus on Java, transparent handling of service
interfaces, a lot of supportive subprojects
o
Status & Purpose of Fractal ADLs
Purpose: to facilitate the assembly and
deployment of individual Fractal applications
o
SOFA CDL – stores information in a global repository
Status: optional
their task can be performed directly “by hand”
to large extent independent of the core Fractal c.m.
specification (not even mentioned there)
ADL parser is a Fractal application(!) – part of the
Fractal Subproject 4: Tools
o SOFA CDL – an integral part of the SOFA/DCUP c.m.
Two official alternative ADLs
Fractal ADL
Simple Fractal ADL
Fractal ADL Overview
An XML based Architecture Description Language
Advantages
a full-featured ADL alternative
specified in a standardized way – using XML DTD
takes advantage of common XML approaches
easily extensible
amenable to to automated processing (e.g. XSLT)
Disadvantage (compared to Simple Fractal ADL)
poorly human-readable for larger applications
Based on three main constructs to specify
component types (combine CDL frames & CDD)
primitive templates (combine CDL primitive arch.& CDD)
composite templates (combine to CDL compound arch.
& DD)
Component Types – Example
<component-type name=“TesterType“>
<provides>
<interface-type name="m" signature="Main"/>
</provides>
<requires>
<interface-type name=“log" signature=“LogInterface"/>
</requires>
</component-type>
SOFA CDL frame syntax
frame TesterType
{ provides: Main m;
requires: LogInterface log;
};
Component Types – General Structure
<component-type name=“…“ extends=“…”>
<provides>
<interface-type name=“…" signature=“…“ contingency=“…”
cardinality=“…”/>
...
</provides> ...
<requires>
<interface-type name=“…" signature=“…“ contingency=“…”
cardinality=“…”/> ...
</requires> ...
</component-type>
signature: optional only when overriding an existing interface type
definition
contingency: mandatory or optional
cardinality: single or collection
“optional” means: given interface does not have to be bound
o
similar to the SOFA CDL’s “exempt” in architectures
“collection” means: given interface can be bound multiple times
o
in SOFA CDL inofficially possible using connectors
Primitive Templates – Example
specify a Java class and a component that class implements
<primitive-template name=“LoggerArch“ implements=“LoggerType”>
<primitive-content class=“LoggerImpl”>
<controller>
<attributes signature=“LoggingAttributes”>
<attribute name=“Header” value=“-> “/>
<attribute name=“Count" value=“1"/>
</attributes>
</controller>
</primitive-template>
SOFA CDL Syntax
architecture LoggerArch implements LoggerType primitive
{ property string Header;
property int Count;
};
Primitive Templates – General Structure
<primitive-template name=“…“ implements=“…” extends=“…”>
<primitive-content class=“…”>
<controller>
<attributes signature=“…“>
<attribute name=“…” value=“…”/>
...
</attributes>
<template-controller desc=“…”>
<component-controller desc=“…”>
</controller>
</primitive-template>
implements can be omitted only when extends is defined
template/component controllers can specify the controller descriptor of
the template component/of the component it instantiates
Composite Templates – Example
a type a component implements, its set of subcomponents and a set of bindings
recommended: first – a type, subsequently – extended by implementation
not all components have to be acutally instantiated; only to bind mandatory interfaces
<composite-template name=“logdemo“ implements=“RootType”>
<composite-content>
<components>
<component name=“tester” type=“TesterType”>
<component name=“logger” type=“LoggerType”/>
</components>
<bindings>
<binding client=“this.m” server=“tester.m”>
<binding client=“tester.log” server=“logger.log”>
</bindings>
</composite-content>
</composite-template>
<composite-template name=“logdemoArch“ extends=“logdemo”>
<composite-content>
<components>
<component name=“tester” implements=“TesterImpl”>
<component name=“logger” implements=“LoggerImpl”/>
</components>
</composite-content>
</composite-template>
SOFA CDL Form of the Example
architecture CUNI::logdemo implements RootType
{
inst ::TesterType tester;
inst ::LoggerType logger;
subsume
m to tester:m;
bind tester:log to logger:log;
};
deployment descriptor excerpt
<architecture_ref>::CUNI::logdemo</architecture_ref>
<frame_ref>RootType</frame_ref>
<version>0.0.1</version>
<cdl_entities>
<entity cdlname=“logdemo::LogdemoInterface” javaname=“...”/>
....
</cdl_entities>
<component_ref inst="tester“ arch="CUNI::Tester” version=“0.1"/>
<component_ref inst="logger" arch="CUNI::Logger” version=“0.1”/>
...
Composite Templates – General Structure
<composite-template name=“...” implements=“...” extends=“...”>
<composite-content>
<components>
<component name=“...” type=“...” implementation=“...” >
...
</components>
<bindings>
<binding client="..." server="..."/>
...
</bindings>
<sharing>
<shared-component path="..." ref="..."/>
...
</sharing>
</composite-content>
<controller>
<attributes signature=“...”>
<attribute name=“...” value=“...”/>
...
</attributes>
<template-controller desc=“...”>
<component-controller desc=“...”>
</controller>
</composite-template>
Rules and semantics similar to the case of primitive-template
Shared element – component designed by path must be replaced by the component
designed by ref
path and ref are slash-separated paths relative to current template
External Templates
A name that can be used to retrieve an already instantiated
component
The exact mechanism to retrieve is not specified
e.g. JNDI, RMI registry, ...
Corresponds to TemplateFactory.createFcTemplate
(ComponentIdentity) whose instantiateFc method returns
an already instantiated component
General structure:
<external-template name=“…“ implements=“…”>
<reference name=“…”>
</external-template>
reference – the name to be used to retrieve the already
existing component
org.objectweb.fractal.api.bootstrap is reserved
Fractal ADL Parser
A Fractal composite component
Independent of specific Fractal implementations
Loads type and template definitions
Creates corresponding ComponentType objects and
Template components
Structure of ADLParser in the API documentation
Files - .fractal – split for individual defintions
reuse in big projects
Launching an application:
Constructing the Fractal ADL parser component itself
Parser parser= Launcher.getBootstrapParser()
2.
Loading the template of the application
1.
ComponentIdentity tmpl= parser.loadTemplate(logdemoImpl)
Instantiating and and starting the template
ComponentIdentity comp=
Fractal.getTemplate(tmpl).instantiateFc();
Fractal.getLifeCycleController(comp).startFc();
3.
Inheritance semantics in Fractal ADL
Based on XML inheritance rules
“e” extends “f” => merging “e” into “f”
“e” extends “f” attributes => union of
attributes, in case of collision extending
value overrides
Subelements (recursively):
have the attribute “name”: merging of “e”
subelement to “f” subelements
provides, attributes, components, binding (“client”
attribute gives the “name”), sharing (“ref” attribute)
otherwise: merge of “e” subelements into “f”
colliding subelements
Simple Fractal ADL – Overview
alternative Fractal ADL
more concise & readable syntax than XML
version
less powerful
no component sharing
no attribute values specification
no external templates
close matching of XML-based ADL structure
the component type directly inside its definition
Fractal users’ comments expected
some limitations may be removed
Simple Fractal ADL – Interface Types
Like interface instances in CDL frames
General structure:
role contingency? cardinality? signature iface_name
role: provides / requires
contingency: optional / mandatory
cardinality: single / collection
signature: fully qualified corresponding Java interface name
iface_name: name identifying given interface in Fractal
Simple: provides mandatory single org.foo.Main main;
XML-based: <provides> <interface-type name="main“
signature="org.foo.Main" contingency="mandatory“
cardinality="collection"/> </provides>
SOFA: provides: org::foo::Main main;
Simple Fractal ADL – Component Types
Like CDL frames
General structure:
type typeName (extends superTypeName)? {ifaceTypeDef +}
ifaceTypeDef – sequence of interface type definitions
inheritance semantics as in XML-based ADL
Example:
Java interface
type RootType
type ClientType extends RootType
{ provides Main m;} { requires org.foo.Service s; }
<component-type name="ClientType" extends="RootType">
<requires>
<interface-type name="s" signature=“org.foo.Service"/>
</requires>
CDL
</component-type>
proposed
interface
frame RootType
{ provides: Main m; };
frame ClientType inherits RootType
{ requires: org::foo::Service s; };
Simple Fractal ADL – Primitive Components
Like primitive architectures in SOFA CDL
Types either externally or directly inside the definition
General structure:
primitive primName is className implements typeName;
primitive primName is className (implements
typeName)?
{ interface-type-definition*
(template-controller is tmplCtlrName)?
(component-controller is compCtlrName)? }
...CtrlName: names of the template/component conroller definitions
meaning depends on a Fr. implementations – in Julia, aliases in
julia.cfg
former form – only when default template and component
controllers used
SOFA CDL
frame definition inside primitive architectures not allowed
o real java names in the deployment descriptor
o only functional interfaces considered
o
Primitive Components – Example
primitive ClientArch is ClientImpl implements ClientType;
external type
primitive ClientArch is ClientImpl
definition version
{
provides mandatory single Main m;
direct type
requires mandatory single org.foo.Service service;
definition
}
SOFA CDL syntax
architecture ProvName::ClientArch implements ClientType primitive;
<primitive-template name=“ClientArch”implements=“ClientType”>
<primitive-contents class=“ClientImpl”>
XML-based
</primitive-template>
syntax
<primitive-template name="ServerImpl" implements="ServerType">
<primitive-content class="ServerImpl"/>
<controller>
<attributes signature="ServiceAttributes">
Cannot be
<attribute name="Header" value="-> "/>
expressed by
<attribute name="Count" value="1"/>
</attributes>
simplified syntax
</controller>
</primitive-template>
Simple Fractal ADL – Composite Components
Like compound architectures in SOFA CDL
General structure:
composite cName (implements tName)?
{ interface-type-definition*
(contains compName as localName;)*
(binds client-interface to server-interface;)*
(template-controller is compCtlrName)?
(component-controller is compCtlrName)? }
compName – name of either primitive or composite
sudbcomponent
Differences from SOFA CDL (not mentioned)
subcomponents – not types (frames) but directly “architectures”
o ties – all are called “bind”
o keyword this used to denote current component
o dot is used instead of colon to separate components from ifaces
o
Composite Components – Example
composite WreppedClientArch implements ClientType
{ contains ClientArch as clientSubc;
simple Fractal
binds this.m to clientSubc.m;
ADL syntax
binds clientSubc.s to this.s;
}
SOFA CDL syntax
architecture ProvName::WreppedClientAchr implements ClientType
{
inst ::ClientType clientSubc;
delegate m to clientSubc:m;
XML-based
subsume clientSubc:s to s;
syntax
};
<composite-template name="WrappedClientArch" implements="ClientType">
<composite-content>
<components>
<component name="clientSubc" type="ClientType”
implementation="ClientImpl"/>
</components>
<bindings>
<binding client="this.m" server="clientSubc.m"/>
<binding client="clientSubc.s" server="this.s"/>
</bindings>
</composite-content>
</composite-template>
Simple Fractal ADL Parser
standard parser – does not parse simple ADL
separate parser (as a Fractal component)
only one file: architecture.adl
Launching simple ADL parser:
1. A standard bootstrap parser obtained
Parser parser = Launcher.getBootstrapParser();
2. SimpleADL parser template loaded
Component rTmpl = parser.loadTemplate
("org.objectweb.fractal.adl.SimpleADLParser");
3. SimpleADL parser component instantiated
Component rComp =
Fractal.getFactory(rTmpl).newFcInstance();
4. SimpleADL parser component is started
Fractal.getLifeCycleController(rComp).startFc();
5. Parser interface is obtained, replacing original parser
parser = (Parser) rComp.getFcInterface("parser");
SOFA vs. Fractal ADLs – General Summary
Fractal ADL optional, more alternatives
o SOFA CDL mandatory, a single version
Fractal ADL parser – called from within a code and just loads
the top-level application component
o SOFA CDL compiler – called externally with a .cdl file as a
parameter and transfers the specification information to a TIR
and optionally a behavior protocol verifier
Fractal ADL combines architecture description and
configuration information (names of classes, attribute values, ...)
o SOFA CDL only specification information,
configuration/implementation information in deployment
descriptors
Fractal ADL – no description of interfaces (Fractal IDL – a part
of the core Fractal 2.0 specification)
o SOFA CDL includes interface definitions
SOFA vs. Fractal ADLs – Abstraction Summary
Fractal ADL component types – set of interfaces with their roles and
additional information (cardinality, contingency, ...)
o SOFA CDL frames – set of interfaces with roles, cardinality and
contingency information not explicitly defined
Fractal ADL primitive templates – a component type and name of the
Java class plus additional configuration information (controllers, e.g.
attributes and their values)
o SOFA CDL primitive architecture – an implemented frame;
information about implemented files (CDDs) and the to-be-edited Java
files themselves (archBuilder and archImpl) are generated
Fractal ADL composite templates – a component type, a set of
subcomponents including shared ones, a set of bindings, additional
configuration information (controllers, e.g. attributes);
subcomponets= primitive or composite components
o SOFA CDL compound architectures – an implemented frame, a set
of subcomponents (no shared subcomponets), a set of bindings
o subcomponets= frames, i.e. types, replaced with architectures in
the deployment descriptor
SOFA vs. Fractal ADLs – Inheritance Summary
Fractal ADL, XML-based, component types – single inheritance
with merging semantics
Fractal ADL, simplified, component types – single inheritance
with merging semantics
o SOFA CDL frames – originally no inheritance, proposed multiple
inheritance with explicit renaming
Fractal ADL primitive templates – single inheritance with merging
semantics
Fractal ADL, simplified, component types – no inheritance (yet?)
o SOFA CDL primitive architectures – no inheritance
Fractal ADL composite templates – single inheritance with
merging semantics
Fractal ADL, simplified, component types – no inheritance (yet?)
syntactic sugar only with no correspondence in the model, too
complicated
o SOFA CDL compound architectures – originally no inheritance,
proposed multiple inheritance with explicit renaming, replacing of
subcomponents and replacing of ties
Possible Attitudes to Inheritance in Fractal
1. Not to become involved at all
Fractal – different purpose from SOFA, some inheritance already
established, inheritance used for different purposes from CDL
2. Propose another alternative Fractal ADL – based on the
SOFA CDL syntax
fits the lots-of-options view promoted by Fractal creators, helps to
migrate SOFA users to Fractal ☺, creators will more likely to agree
with incorporating the parser to the Fractal distribution
BUT – who will implement it?! (time consuming task)
3. Propose changes in the main (XML-based) Fractal ADL
the argument about combining interfaces (thus increasing weight)
and purer composition still holds even in Fractal; preferably within
a package of changes (together with protocols?)
BUT – significant changes required (syntactical – not as attribute
but as elements – and semantical – including naming conflicts
solution (implicit, e.g. latest-ancestor precedence) or explicit)
4. Give feedback proposing changes in the simplified Fractal ADL
Users’ feedback is expected BUT the motivation not to incorporate
it is keeping simplicity
Conclusion
Fractal ADLs
two standard alternatives
practically usable
in many aspects (abstractions, ...) similar to SOFA but not
fully (include features of SOFA DDs)
inheritance in component specifications established but
not much attention is devoted to it (follows standard rules
for extending XML elements)
SOFA
possible inspiration for more precise definitions
(optionality, contingency, ...)?
possible inspiration for creating serviceable “light-weight
SOFA”?
Absence inheritance in CDL frames and architectures is a
missing feature!