A SOA Approach for Domain-Specific Language Implementation - PowerPoint PPT Presentation


PPT – A SOA Approach for Domain-Specific Language Implementation PowerPoint presentation | free to download - id: 4ffd13-NjY2N


The Adobe Flash plugin is needed to view this content

Get the plugin now

View by Category
About This Presentation

A SOA Approach for Domain-Specific Language Implementation


A SOA Approach for Domain-Specific Language Implementation Shih-Hsi Alex Liu1, Adam Cardenas1, Xang Xiong1, Marjan Mernik2, Barrett R. Bryant3, Jeff Gray4 – PowerPoint PPT presentation

Number of Views:77
Avg rating:3.0/5.0
Slides: 44
Provided by: Facu236
Learn more at: http://www.cs.ua.edu


Write a Comment
User Comments (0)
Transcript and Presenter's Notes

Title: A SOA Approach for Domain-Specific Language Implementation

A SOA Approach for Domain-Specific Language
  • Shih-Hsi Alex Liu1, Adam Cardenas1, Xang
    Xiong1, Marjan Mernik2, Barrett R. Bryant3, Jeff
  • 1California State University, Fresno, USA
  • 2University of Maribor, Slovenia
  • 3University of Alabama at Birmingham, USA
  • 4University of Alabama, USA

  • Background Domain-Specific Languages (DSLs)
  • Challenges of DSL Implementation
  • Existing DSL Implementation methodologies and
  • A SOA Approach for DSL Implementation
  • Case Studies
  • Robot language
  • PPCea
  • FDL
  • Discussions
  • Conclusions

  • A Domain-Specific Language (DSL) is a
    programming/modeling language that shields
    accidental complexity by uplifting the
    abstraction layer to a higher level.
  • A DSL introduces domain-specific constructs and
    notations to facilitate productivity,
    reliability, maintainability and portability.
  • Up to 510 times productivity improvement
  • Decision, analysis, design and implementation
    patterns have been identified to assist DSL
    developers in when and how to develop a DSL.

Background (cont.)
  • Example DSLs include
  • Robot language An imperative DSL that controls a
    (Lego Mindstorm NXT) robot to move in different
    directions and distances.
  • PPCea An imperative DSL that controls parameter
    settings to balance an evolution process toward
    optimization and convergence.
  • Feature description language (FDL) A declarative
    DSL to configure combinations of features.
  • And many others.(e.g., SQL, UNIX shell script,
    MediaWiki templates etc.)

Challenges of DSL Impl.
  • Kosar et al. investigated that
  • DSL implementation using a compiler or
    interpreter pattern may suffer from
    extension/evolution problem
  • Gray et al. also pointed out that
  • DSLs are usually unstable and syntactically
    and/or semantically evolve due to their frequent
    need to represent changes in domain concepts.
  • E.g., A DSL for testing automobile breaks

Challenges of DSL Impl. (cont.)
  • Extension/Evolution When domain concepts change,
    then the lexical, syntactical and/or semantic
    domain constructs need to evolve.
  • Tedious and error-prone.
  • E.g., one new domain statement or one new grammar
    production introduced will affect an existing DSL
    implementation at the lexical, syntactical, and
    semantic levels in different magnitudes.
  • Interoperability A DSL is usually implemented by
    one base language (e.g., Java).
  • What if it is desired to implement a DSL in
    several different base languages?
  • How would these base languages communicate with
    each other?
  • Tool Support When a new DSL is introduced,
    corresponding DSL tools should be supported
    (e.g., DSL debugger). Otherwise, the DSL will
    have fewer opportunities to be adopted.
  • It requires a great amount of endeavor and

Existing DSL Impl. Methodologies
  • AMMA is a platform to implement text-based DSLs
    using a Model-Driven Engineering approach that is
    focused on model transformations.
  • Need to describe abstract syntax, concrete syntax
    and transformation rules of a DSL
  • CoCloRep is a DSL for code clone representation
  • The Generic Modeling Environment (GME) is a
    metamodeling toolkit for developing graphical
  • Metamodel defines a domains syntax, semantics,
    constraints, and presentation
  • A model is an instance (namely, a DSL program)
    that conforms to metamodel
  • Interpreter generates source code from a model or
    executes a model
  • TCPN is a modeling language for time-colored
    Petri net

Existing DSL Impl. Methodologies (cont.)
  • Six DSL implementation patterns are identified
  • Interpreter/compiler patterns utilize
    compiler/interpreter techniques
  • Embedding patterns introduce new DSL constructs
    from an existing General-Purpose Language (GPL)
  • Preprocessor patterns translate DSL constructs
    into a base language
  • Extensible compiler/interpreter patterns add DSL
    optimization rules and code generation in the
    existing compiler/interpreter of a GPL
  • Commercial off-the-shelf patterns utilize
    existing tools and/or notations for a specific
    domain and
  • A Hybrid pattern is the combination of all of the
  • There are many other implementation
    methodologies/tools for DSLs (e.g., Visual Studio
    DSL tools, Eclipse GMF, MetaEdit).
  • These methodologies (not tools) still suffer from
    the aforementioned three challenges

A SOA Approach for DSL Impl.
Step Compiler/Interpreter SOA
Lexical Analysis Tokenize a DSL program into lexemes by JFlex or others WSDL acts as lexemes. XML schema describes the structure and data types of an XML message.
Syntax Analysis Examine a DSL program and construct its grammatical structure by ANTLR, CUP, etc. BPEL engines performs such examination and construction WSDL specifies Web services DSL developers dont define DSL grammars
Semantics Defined by base language Defined in web services
A DSL program Conforms to DSL grammars Written in WS-BPEL
Case Study Robot Language
  • An imperative DSL that controls a (Lego
    Mindstorm NXT) robot to move in different
    directions and distances.
  • The implementation utilizes preprocessing pattern
    that translates its program into leJOS, a base
    language for controlling and communicating w/
  • NXT allows two types of communication USB and
    Bluetooth between two robots or between one robot
    and one controlling device (a desktop or a

Case Study Robot Language (cont.)
  • The SOA-based Robot Language is implemented in
    two ways
  • First Way A web service is introduced
  • Each movement control (e.g., Move Up, Move Down,
    Move Left, or Move Right) is encapsulated in an
  • Each _at_WebMethod invokes the corresponding leJOS
  • The invocations then send the directions and
    distances to another NXT robot, which preloads a
    receiver that performs movement commands
  • Second Way A web service performs leJOS code
    generation at runtime using Java Reflection. The
    code is then loaded to a robot connected w/ the
    desktop via USB.
  • Both ways utilize WS-BPEL to express a sequence
    of movements (i.e., a Robot language program) for
    the robot

Case Study Robot Language (cont.)
  • Experiment 1 A robot is controlled by a
    desktop/laptop using bluetooth/USB connection.
    The robot follows a square and then stops.

Case Study Robot Language (cont.)
  • Experiment 2 One robot is controlled by a
    desktop and a laptop using USB and Bluetooth
    connections, respectively. The two devices send
    controls to the robot in turns. The robot moves
    following the commands from both devices.

Case Study Robot Language (cont.)
  • Evolution/Extension
  • If a new command/control is needed, it can be
    added to a new _at_WebMethod or a new web service
  • E.g., Make Bell Sound
  • If an existing command needs
  • Semantic evolution, we concentrate on editing the
    web service.
  • Lexical and/or syntactical evolution, we
    concentrate on WSDL.
  • Good modularization and good decoupling
    Developers not need to worry too much about
    coordination among lexical, syntactical, semantic
    levels. SOA tools coordinate it for you.
  • Traditional DSL implementation will need to
    revise lexical, syntactical/grammatical, and/or
    semantic levels in different magnitudes.

Case Study PPCea
  • An imperative DSL for Evolutionary Algorithms. It
    controls parameter settings to balance an
    evolution process toward optimization and

1 genetic 2 Round 50 3 r 0 4 while ( r lt
Round ) do 5 g 0 6 tmp 1.0 7 init 8
while ( g lt Maxgen ) do 9 pm (1.0 /
1250.0) (0.0042 / tmp) 10
callGA 11 tmp tmp 2.0 12 g g
Epoch 13 end 14 r r 1 15 end 16 end
Case Study PPCea (cont.)
  • The SOA-based PPCea is implemented as follows
  • WSDL is an XML-based language to describe a
  • It specifies data types, messages, operations,
    port types, bindings, port, and service.
  • For a SOA-based DSL, WSDL can assist with lexical
    analysis and syntax analysis
  • It comprises lexical and syntactical information
    and semantic specification of a web service.

Case Study PPCea (cont.)
Case Study PPCea (cont.)
  • An XML schema describes the structure and
    (domain-specific) data types of an XML message.
  • It is utilized to validate if an XML message
    consumed by a web service follows the specified
    structure and data types.
  • For a SOA-based DSL, XML schema is used to
    validate if XML messages contain valid data.

Case Study PPCea (cont.)
  • W3C defines a web service as a software system
    designed to support interoperable
    machine-to-machine interaction over a network.
  • For a SOA-based DSL, a web service describes the
    semantics of a DSL statement.
  • SOA-based PPCea introduces the web services shown
    on the right.

WS Functional Objectives
Initialize Initialize a population, configure domain-specific parameters
Select Select offspring out of a population following different strategies
Mutate Mutate individual(s) out of a population
Crossover Reproduce offspring out of a population using crossover
Evaluate Evaluate the result of a fitness function
Update Update the values of domain-specific parameters
Entropy Compute the randomness of a population
PPCea (cont.)
  • WS-BPEL is an executable language that has
    various programming constructs to describe the
    execution flow of a business process.
  • For a SOA-based DSL, WS-BPEL describes a DSL
    program as well as primitive domain-specific
    parameters within.

Case Study PPCea (cont.)
  • Four experiments/ implementation alternatives are
  • Exp. (0) is for interpreter-based PPCea
  • Exp. (1) utilizes JAXB to marshal and unmarshal
    messages passed among web services. Symbol tables
    used to store DSL parameters are public to all
    web services. (Note it does Not conform to SOA
  • Exp. (2) utilizes StAX to marshal and unmarshal
    messages. Symbol table impl. is the same Exp. (1)

Case Study PPCea (cont.)
  • Exp. (3) is implemented as follows
  • Interoperability between Java-based and C-based
    web services all but the Init web service is
    implemented in Java.
  • These web services are partner linked by WS- BPEL
    under the Oracle BPEL Process Manager.
  • Symbol tables are replaced by XML message
  • The experiment shows that interoperability and
    tooling support challenges can be overcome by
    using the SOA approach.
  • Oracle BPM provides a very good debugging

Case Study PPCea (cont.)
  • Evolution/Extension
  • If a new DSL statement is needed, it can be added
    to a new _at_WebMethod or a new web service can be
  • E.g., Introduce N-point mutation WS (currently it
    is one-point mutation), and N-point crossover WS
    (currently it is one-point crossover)
  • If an existing DSL statement needs
  • Semantic evolution, we concentrate on editing the
    web service. (E.g., fixed point mutation -gt
    random point mutation)
  • Lexical and/or syntactical evolution, we
    concentrate on editing WSDL if needed.
  • PPCeas grammar evolution will not affect WSDL
    and/or web services
  • SOA-based PPCea has the same implementation
    advantages on evolution and extension as
    SOA-based Robot language.
  • It also shows the solution of interoperability
    and tooling support.

Case Study PPCea (cont.)
  • Experimental Results (Exp. 0 is interpreter-based

Exp. Exe. Time (sec) Memory Usage (byte) Best Fit Avg. Fit Worst Fit
(0) 5.00 7612457 19.39 19.53 19.59
(1) 12.00 9259575 20.61 20.86 21.03
(2) 9.40 10007744 20.64 20.86 21.04
(3) 53.82 2058264576 20.43 20.78 20.96
Case Study FDL
  • Different from imperative languages that utilize
    DSL control constructs to determine how a DSL
    program is executed, domain-specific declarative
    languages instead describe what a program should
    do when executed and the relationships between
    DSL statements
  • A Feature Description Language (FDL) is a
    declarative language that textually describes
    feature diagrams for domain analysis.

Case Study FDL (cont.)
  • The language introduces all-of, one-of, more-of
    and optional feature operations to explore all
    possible configurations along with requires,
    excludes, include and exclude constraints to
    reduce the possibilities

1 Car all (carbody, Transmission, Engine,
Horsepower, opt(pullsTrailer)) 2 Transmission
one-of (automatic, manual) 3 Engine more-of
(electric, gasoline) 4 Horsepower one-of
(lowPower, mediumPower, highPower) 5 include
pullsTrailer 6 pullsTrailer requires highPower
Case Study FDL (cont.)
  • A SOA-based FDL language introduces two web
    services as DSL statements
  • FeatureWS comprises the aforementioned eight
    operations, each of which consumes previously
    generated and current (input) XML messages and
    returns a new combinatory XML message based on
    normalization, variability, expansion and
    satisfaction rules.
  • CompileWS prints out the final combinatory result
    of all possible alternatives.
  • A preprocessing step is also needed to convert
    the example program to XML messages line-by-line.

Case Study FDL (cont.)
FeatureWS WSDL
Case Study FDL (cont.)
2 Transmission one-of (automatic, manual)
A Transmission XML input for FeatureWS
Case Study FDL (cont.)
A SOA-based FDL program written in WS-BPEL
Case Study FDL (cont.)
Output of the FDL program Six constrained car
Case Study FDL (cont.)
  • Evolution/Extension
  • none-of operation identically acts as an exclude
  • For syntactic (but not semantic) evolution,
    SOA-based FDL can be evolved easily by utilizing
    a newly generated WSDL without affecting other
    parts of the implementation.
  • two-of operation
  • Syntactic evolution is done by automatically
    generated WSDL of a new web service.
  • For semantic evolution, most of the rules for the
    all-of operation are reused. A new rule that can
    be realized as a web service is introduced to
    generate a set of two combinatory atomic features
    out of a feature list.
  • Semantic evolution may be considered as
    introduction and/or composition of web services,
    which reflects SOAs advantages.

Discussions Lexical Analysis
  • Traditionally, lexical analyzer tokenizes a DSL
    program into lexemes
  • For SOA approach, there is no need to perform
    lexical analysis
  • WSDL can be regarded as a lexeme to represent the
    web service acting as a domain-specific
  • XML schema within WSDL (or listed separately) can
    be regarded as the data type of domain-specific
    parameters (e.g., population XML schema)
  • For DSL constructs, a number of XML tags and XML
    schema used for SOA-based DSL programs have been
    defined in the WS-BPEL (e.g., if-else, while)
  • For CoCloRep and TCPN, lexemes are defined in

Discussions Symbol Table
  • A symbol table is a containment data structure
    for a compiler to keep track of scope and
    binding information about names.
  • For interpreter-based DSLs, a symbol table is
    usually internally implemented as a hash table
    comprising the aforementioned information.
  • For SOA-based DSLs, symbol table functionality
    cannot be achieved easily (no global sharing).
  • XML message passing between web services is an
  • Each web service creates an internal hash table
    to interpret, validate (against an XML schema, if
    available) and store necessary variable
  • For CoCloRep and TCPN, no symbol table

Discussions Syntactical Analysis
  • Syntax analysis examines a DSL program and
    constructs its grammatical structure based on the
    DSL grammar.
  • For traditional DSL implementation, the main
    effort is to specify compiler/interpreter-based
    DSL grammars in compliance with the selected
    parser generators (ANTLR, CUP etc.)
  • For SOA-based DSLs, WS-BPEL specifications have
    defined grammars. Reinventing SOA-based DSL
    grammars and parsers for Robot language, PPCea
    and FDL are not needed.
  • Yet, WS-BPELs great flexibility may be also
    misused and can result in potential pitfalls.
  • For CoCloRep and TCPN, syntax are defined in

Discussions Semantics and Type Checking
  • Domain-specific statements are wrapped as one or
    more web services.
  • Implementation of DSL web services is not much
    different except
  • An internal commonly shared symbol table is no
    longer valid. Investigation on analyzing the
    scope of domain-specific parameters is needed
    only those that will be needed by most web
    services will be encapsulated in XML messages.
  • There is a need to introduce efficient
    marshalling and unmarshalling algorithms to parse
    the aforementioned XML messages. JAXB is a more
    formal approach an XML schema is used to
    validate and convert between objects and XML
    instances. Conversely, StAX is a more casual but
    efficient way that processes XML as a stream and
    ignores tree construction.

Discussions Tradeoffs
  • Usability and comprehensibility
  • PPCea written in WS-BPEL takes considerable time
    to construct compared to interpreter-based PPCea
  • Declaring domain-specific parameters at the
    WS-BPEL level requires XML schema knowledge, and
    the situation becomes burdensome as the size of
    the program increases.

Discussions Tradeoffs (cont.)
  • Usage of Time and Resources
  • Experimental results of SOA-based PPCea take more
    time and memory usage than the interpreter-based
  • One of the primary reasons is that
    marshalling/unmarshalling are bottlenecks, which
    are unfortunately mandatory components to realize
    Web services and offer interoperability.

Discussions Tradeoffs (cont.)
  • Because there is no symbol table, domain-specific
    parameters in XML messages are exposed to end
  • The benefit is users have power to its
    domain-specific parameters.
  • Yet, the continuing challenge is that misuse or
    potential pitfalls may be introduced by end-users
    if XML schema validation is not involved.

Discussions Tradeoffs (cont.)
  • SOA-based DSLs utilize WS-BPELs grammar and
    engine to parse and execute DSL programs
  • There is no need to introduce lexical analysis
    and syntactical analysis.
  • Yet, WS-BPEL has powerful grammatical constructs,
    it may cause potential pitfalls
  • If a SOA-based DSL user is not knowledgeable,
    potential semantic errors may occur due to
    incorrect usage or improper ordering of Web
    service invocations in a DSL program written in

  • SOA-based DSLs offer five implementation
  • SOA addresses the extension and evolution
    problems at lexical, syntactic and semantic
    levels For new, existing extended, or evolved
    DSL constructs, lexical/syntactic evolution can
    be done by automatically generated WSDL files,
    and semantic evolution is achieved by
    introduction and/or composition of web services.
  • SOA offers interoperable communications among Web
    services implemented in different languages,
    which addresses interoperability concerns of DSL
  • WS-BPEL and WSDL are technology-neutral languages
    that have been adopted by many vendors. It may
    reduce the effort to introduce tools for new or
    existing DSLs.
  • SOA offers improved modularization at the
    lexical, syntactical and semantic levels.
  • Lexical and syntax analyses adopting an
    interpreter or compiler-based DSL implementation
    are no longer needed in SOA-based DSLs.

Conclusions (cont.)
  • SOA-based DSLs may raise potential research
    interests to overcome the tradeoffs surrounding
    the flexibility of WS-BPEL grammars, WS-BPEL
    usability, bottlenecks on XML parsing time, and
    exposed domain-specific parameters.

  • Source code (WS-BPEL, WSDL, Java, C), snapshots,
    and demo videos are available at
  • Any feedback and suggestion is welcome
About PowerShow.com