using dsl for generation of software connectors
DESCRIPTION
The talk presented at ICCBSS 2008.TRANSCRIPT
Tomáš Bureš, Michal Malohlava, Petr Hnětynka
Using DSL for Automatic Generation of Software Connectors
DISTRIBUTED SYSTEMS RESEARCH GROUPhttp://dsrg.mff.cuni.cz/
CHARLES UNIVERSITY IN PRAGUEFaculty of Mathematics and Physics
28.2.2008, ICCBSS 2008, Madrid 2
● Components and Connectors● Connector generation● Proposed connector code generator
– Template system
– Code generation engine
● Conclusion
Outline
28.2.2008, ICCBSS 2008, Madrid 3
● Component● Independent entity implementing some functionality● Provides/requires interfaces
● Typical development cycle– Design
– Implementation
– Deployment
– Execution
● SOFA component system (http://sofa.ow2.org/)
Components
28.2.2008, ICCBSS 2008, Madrid 4
● Why should be a component interested in communication?=> Connectors
– Displace communication matters from components
– Can connect different component technologies
● Connectors
– Design time view
● Model component interaction (communication style, non-functional properties)
● Represent only bindings and their properties
– Implementation view
● Implements interaction with help of some middleware (RMI, JMS,...)● Implements additional services
(logging, benchmarking, ...)
Connectors? Why?
28.2.2008, ICCBSS 2008, Madrid 5
● Automatically during deployment time– Application components are distributed, connected
– All information about application are known...● Distribution of application components● Component interfaces' signatures● Connection requirements, NFP (security, logging,...)
– ... and stored in a high-level connector specification● Generated by a deployment tool
in according to a defined deployment plan
● Input for a connector generator
Connector generation
connector { unit “client_unit” { dock “nodeA” provided port “call” signature “Iservice” nfp “communication_style” “method_invocation” } ...}
28.2.2008, ICCBSS 2008, Madrid 6
Connector architecture
● Connector– Connector units
● Top-level connector elements● Remote bindings (between remote ports)
– Connector elements● Element ports● Primitive/composite● Only local bindings
28.2.2008, ICCBSS 2008, Madrid 7
● Architecture resolver
– Find an architecture of a connector in according to described requirements (H-LCS)
● Source code generation
– Driven by generation script
● Step-by-step process– Generates source code from:
● Low-level connectorconfiguration
● Simple templates– Compile generated code
– Package binaries
Architecture of connector generator
28.2.2008, ICCBSS 2008, Madrid 8
● Architecture resolver
– Find architecture of connector in according to described requirements (H-LCS)
● Source code generation
– Driven by generation script
● Step-by-step process– Generates source code from:
● Low-level connectorconfiguration
● Simple templates– Compile generated code
– Package binaries
Architecture of connector generator
28.2.2008, ICCBSS 2008, Madrid 9
● Low-level connector configuration
– Input for source code generator
– Description of resolved connector architecture:● Describes ports
– Name– Type (provided, required, remote)– Resolved port signature
● List of sub-elements● Bindings between sub-elements● Selects template for implementation
Low level connector configuration
28.2.2008, ICCBSS 2008, Madrid 10
Simple template system
● Simple code templates which are processed by a Java class
– Class just substitutes parts enclosed in % by Java code● Sufficient for primitive connector elements, but for composite
elements Java class generates all code:package %PACKAGE%;imports org...runtime.*;public class %CLASS% implements ElementLocalServer , ElementLocalClient , ElementRemoteServer , ElementRemoteClient { protected Element[] subElements ; protected UnitReferenceBundle[] boundedToRRef; public %CLASS%( ) { } %INIT METHODS% // this part processed by special Java class}
28.2.2008, ICCBSS 2008, Madrid 11
Simple template system
● Simple code templates which are processed by a Java class
– Class just substitutes parts enclosed in % by Java code● Sufficient for primitive connector elements, but for composite
elements Java class generates all code:package %PACKAGE%;imports org...runtime.*;public class %CLASS% implements ElementLocalServer , ElementLocalClient , ElementRemoteServer , ElementRemoteClient { protected Element[] subElements ; protected UnitReferenceBundle[] boundedToRRef; public %CLASS%( ) { } %INIT METHODS% // this part processed by special Java class}
This variable is unfolded into 200LOC by a Java class with 1200LOC!
28.2.2008, ICCBSS 2008, Madrid 12
Issues of the simple template system
● Connector implementation defined at several places
● Java class does not allow syntax checking of generated code– Error prone
● Bad maintainability of generator classes– Large blocks of System.out.println(“...”);
● Solution – new Domain Specific Language (DSL)
28.2.2008, ICCBSS 2008, Madrid 13
● Template system based on a new DSL– DSL describing connector elements
● Should support writing connector implementations in different programming languages
– Should allows easy development (syntax checking, debugging,...)
● Extensible
● Generation framework– Processing DSL
– Generating target source code ● Code per connector element● Independent on a chosen target language
Proposed template system
28.2.2008, ICCBSS 2008, Madrid 14
● Designed new DSL
– Mixture of the meta-language ElLang (element language) and a target language (Java)
● Used MetaBorg method– Allows embedding language into another language
● Connecting selected nonterminals of both languages ● Meta-language ElLang (target language independent)
– Meta-variables
● ${a}, ${a[index]}
– Meta-queries (querying input XML)● ${a.b.c}
– Meta-statements● $set, $if, $include, $foreach, $rforeach
DSL – ElLang basics
28.2.2008, ICCBSS 2008, Madrid 15
● Designed new Domain Specific Language
– Mixture of meta-language ElLang and target language (Java)
● MetaBorg method developed by Stratego/XT group– Allows embedding language into another language– Connecting selected neterminals of both languages
● Defined via SDF● Meta-language ElLang
– Meta-variables
● ${a}, ${a[index]}
– Meta-queries● ${a.b.c}
– Meta-statements● $set, $if, $include, $foreach, $rforeach
DSL – ElLang basics
$rforeach(PORT in ${ports.port(type=PROVIDED)} )$ if ("${PORT.name}".equals(portName)) { Object result = ((ElementLocalServer) subElements[${el[PORT....]}]);
if (isTopLevel) { dcm.reregisterConnectorUnitReference(parentUnit, portName, result); } return result; } else $recpoint$ $final$ throw new ElementLinkException("Invalid port '"+portName+"'."); $end$
Recursive foreach
28.2.2008, ICCBSS 2008, Madrid 16
● Special meta-statements– Simple templates inheritance (extends)
– Extension points ($extPoint$)● Allow define points in a template which can be extended
in a child template
– Method templates● Important for implementing component interfaces
– ! component iface is not known when template is designing !● ElLang has to provides information about methods of an
interface– ${method.name}, ${method.variables}, ...
DSL – ElLang advanced features
28.2.2008, ICCBSS 2008, Madrid 17
● Special meta-statements– Simple templates inheritance (extends)
– Extension points ($extPoint$)● Allow define points in template which can be extended in
a child template
– Method templates● Important for implementing component interfaces
– ! component iface is not known when templates is designing !● Language should provides information about iface
methods– ${method.name}, ${method.variables}, ...
DSL – ElLang advanced features
element console_log extends "primitive_default.ellang" {implements interface ${ports.port(name=in).signature} {
method template {${method.declareReturnValue}
System.out.println("method > ${method.name} < called");
$if (method.returnVar) $${method.returnVar} = this.target.${method.name}(${method.variables});
$else$this.target.${method.name}(${method.variables});
$end$
//generates return statemene if it is needed${method.returnStm}
} }}
28.2.2008, ICCBSS 2008, Madrid 18
● ElLang-J = an instance of ElLang– For generating Java code
● Connector element template:
DSL – element template structure
package ${package};import org . . . runtime .* ;
element console_log extends “primitive_default.ellang” { public ${classname} { /* constructor */ }
implements interface ElementLocalClient { public void bindElPort(String portName , Object target ) { /* ... */ } } implements interface ${ ports.port (name=line).signature} { method template { /* ... */ } }
28.2.2008, ICCBSS 2008, Madrid 19
● Java part– Prepares low-level connector configuration (L-LCC)
● Description of connector element internals
– Calls source code generator implemented in Stratego
● Stratego part– Implemented in Stratego language
● In fact compiled C-source code
– Generates source code● From template written in ElLang-J● From L-LCC passed from Java part of generator
Generator architecture
28.2.2008, ICCBSS 2008, Madrid 20
● Developed at Delft University of Technology, Netherlands
● Tool set – Grammar tools
● SDF – Syntax Definition Formalism● Pretty printers● Grammar definitions (Java, C/C++, XML, ...)
– Program transformation language Stratego● Input represented as Abstract Syntax Tree (AST)
– Term representation of AST called ATerm● Based on rewriting of AST via strategies
Stratego/XT
28.2.2008, ICCBSS 2008, Madrid 21
● How does it work?
Stratego/XT - architecture
28.2.2008, ICCBSS 2008, Madrid 22
● Implementing action interface
– Therefore it can be used as a new action in connector element build script
– Rewrites low-level connector configuration into XML and passed it to Stratego part
● Bridge between Java and Stratego:
– JNI bridge
– Shell bridge (execute connector generator)
Generator - Java part
28.2.2008, ICCBSS 2008, Madrid 23
● Pipe line of several small transformation components
– Input XML preprocessor
– Template parser
– Template evaluation
– Target code generator
– Query component● All of them transform and
produce AST
Generator – Stratego part
28.2.2008, ICCBSS 2008, Madrid 24
● Provides access to input XML (contains L-LCC)– Simple queries à la XPath
● Traversing XML– ${ports.port.name}
● conditions– ${ports.port(name=call).signature}
● Returns signature of port called “call”● Count operator
– ${elements.element#count}● Returns number of sub-elements
Stratego part – query component
28.2.2008, ICCBSS 2008, Madrid 25
● Pipe-line of evaluation modules– Processing extends statements
– Processing imports statements
– Template adjustment● Normalization of statements with different notations
– e.g. If -> If-Else ( in ATerms: If(cond,body) -> If(cond, body, []))
– Queries evaluation
– Meta-statements evaluation
● Resulting AST is transformed into target code
Stratego part – evaluation component
28.2.2008, ICCBSS 2008, Madrid 26
Evaluation
● Integrated in our SOFA component model– It works :-)
● But it is suitable for any component model– And even for non-component based systems
28.2.2008, ICCBSS 2008, Madrid 27
● Advantages
– Simple template system allowing easy writing of connector implementations
● Generic solution● Allows syntax checking
– Extensible template language● Allows defining new clones of ElLang in according to
specified requirements (e.g. ElLang-C#)– Solutions is not invasive - proposed source code generator
can be used just by modifying a build script controlling a connector generation
● Disadvantages
– Stratego/XT is C-based, rest of generator is in Java
Evaluation (pros and cons)
28.2.2008, ICCBSS 2008, Madrid 28
● Byte code manipulation– To avoid need of javac (~SDK) during deployment
process
– Pre-compiled templates into binary form (templated bytecode)
● Fast template evaluation
● Simplifying connector implementation– Merging generated Java classes
● Implementing ElLang for other target languages (e.g. ElLang-C#)
● Simplifying method templates
Future work
28.2.2008, ICCBSS 2008, Madrid 29
Comments & Questions
Thank you for your attention!