The talk presented at ICCBSS 2008.

1. Using DSL for Automatic
Generation of Software Connectors
Tomáš Bureš, Michal Malohlava, Petr Hnětynka
DISTRIBUTED SYSTEMS RESEARCH GROUP
http://dsrg.mff.cuni.cz/
CHARLES UNIVERSITY IN PRAGUE
Faculty of Mathematics and Physics

2. Outline
● Components and Connectors
● Connector generation
● Proposed connector code generator
– Template system
– Code generation engine
● Conclusion
28.2.2008, ICCBSS 2008, Madrid 2

3. Components
● Component
● Independent entity implementing some functionality
● Provides/requires interfaces
● Typical development cycle
– Design
– Implementation
– Deployment
– Execution
● SOFA component system (http://sofa.ow2.org/)
28.2.2008, ICCBSS 2008, Madrid 3

4. Connectors? Why?
● 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, ...)
28.2.2008, ICCBSS 2008, Madrid 4

5. Connector generation
● 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 connector {
unit “client_unit” {
in according to dock “nodeA”
provided port “call”
a defined deployment plan signature “Iservice”
nfp “communication_style”
● Input for a connector generator “method_invocation”
}
...
}
28.2.2008, ICCBSS 2008, Madrid 5

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 6

7. Architecture of connector generator
● 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 connector
configuration
● Simple templates
– Compile generated code
– Package binaries
28.2.2008, ICCBSS 2008, Madrid 7

8. Architecture of connector generator
● 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 connector
configuration
● Simple templates
– Compile generated code
– Package binaries
28.2.2008, ICCBSS 2008, Madrid 8

9. Low level connector configuration
● 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
28.2.2008, ICCBSS 2008, Madrid 9

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 10

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 This variable is unfolded
ElementLocalServer , into 200LOC by a Java
ElementLocalClient , class with 1200LOC!
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

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 12

13. Proposed template system
● 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
28.2.2008, ICCBSS 2008, Madrid 13

14. DSL – ElLang basics
● 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
28.2.2008, ICCBSS 2008, Madrid 14

15. DSL – ElLang basics
● Designed new Domain Specific Language
Mixture of meta-language
– Recursive foreach ElLang and target language (Java)
● MetaBorg method developed by Stratego/XT group
$rforeach(PORT in ${ports.port(type=PROVIDED)} )$
if (quot;${PORT.name}quot;.equals(portName)) { into another language
– Allows embedding language
Object Connecting selected neterminals of both languages
– result = ((ElementLocalServer) subElements[${el[PORT....]}]);
● Defined via SDF
if (isTopLevel) {
● Meta-language ElLang
dcm.reregisterConnectorUnitReference(parentUnit, portName, result);
}
– Meta-variables
return result;
} else $recpoint$
● ${a}, ${a[index]}
$final$
throw new ElementLinkException(quot;Invalid port 'quot;+portName+quot;'.quot;);
– Meta-queries
$end$
● ${a.b.c}
– Meta-statements
● $set, $if, $include, $foreach, $rforeach
28.2.2008, ICCBSS 2008, Madrid 15

16. DSL – ElLang advanced features
● 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}, ...
28.2.2008, ICCBSS 2008, Madrid 16

17. DSL – ElLang advanced features
● Special meta-statements
element console_log extends quot;primitive_default.ellangquot; {
– Simplemethod interfaceinheritance (extends)
implements
templates ${ports.port(name=in).signature} {
template {
${method.declareReturnValue}
– Extension points ($extPoint$)
System.out.println(quot;method > ${method.name} < calledquot;);
● Allow define points in template which can be extended in
a child template
$if (method.returnVar) $
${method.returnVar}
– Method templates
= this.target.${method.name}(${method.variables});
$else$
● Important for implementing component interfaces
this.target.${method.name}(${method.variables});
$end$
– ! component iface is not known when templates is designing !
● Language shouldreturn statemene if it is needed
//generates provides information about iface
${method.returnStm}
methods
}
}
– ${method.name}, ${method.variables}, ...
}
28.2.2008, ICCBSS 2008, Madrid 17

18. DSL – element template structure
● ElLang-J = an instance of ElLang
– For generating Java code
● Connector element template:
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 18

19. Generator architecture
● 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
28.2.2008, ICCBSS 2008, Madrid 19

20. Stratego/XT
● 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
28.2.2008, ICCBSS 2008, Madrid 20

21. Stratego/XT - architecture
● How does it work?
28.2.2008, ICCBSS 2008, Madrid 21

22. Generator - Java part
● 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)
28.2.2008, ICCBSS 2008, Madrid 22

23. Generator – Stratego part
● 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
28.2.2008, ICCBSS 2008, Madrid 23

24. Stratego part – query component
● 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
28.2.2008, ICCBSS 2008, Madrid 24

25. Stratego part – evaluation component
● 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
28.2.2008, ICCBSS 2008, Madrid 25

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 26

27. Evaluation (pros and cons)
● 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
28.2.2008, ICCBSS 2008, Madrid 27

28. Future work
● 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
28.2.2008, ICCBSS 2008, Madrid 28

29. Comments & Questions
Thank you for your attention!
28.2.2008, ICCBSS 2008, Madrid 29