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!