A SOA Approach for Domain-Specific Language Implementation Shih-Hsi “Alex” Liu 1, Adam Cardenas 1, Xang Xiong 1, Marjan Mernik 2, Barrett R. Bryant 3,

A SOA Approach for Domain-Specific Language

Implementation

Shih-Hsi “Alex” Liu1, Adam Cardenas1, Xang Xiong1, Marjan Mernik2, Barrett R. Bryant3, Jeff Gray4

1California State University, Fresno, USA2University of Maribor, Slovenia

3University of Alabama at Birmingham, USA4University of Alabama, USA

IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010

Outlines Background: Domain-Specific Languages (DSLs) Challenges of DSL Implementation Existing DSL Implementation methodologies and

tools A SOA Approach for DSL Implementation Case Studies

Robot language PPCea FDL

Discussions Conclusions


Background

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 5~10 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


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 promotion.

Challenges of DSL Impl. (cont.)


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 DSLs. Metamodel defines a domain’s 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


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 above. 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 don’t 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.

NXT allows two types of communication: USB and Bluetooth between two robots or between one robot and one controlling device (a desktop or a laptop).


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 @WebMethod Each @WebMethod invokes the corresponding leJOS APIs. The invocations then send the directions and distances to

another NXT robot, which preloads a receiver that performs movement commands accordingly

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.

USB

Bluetooth


Case Study: Robot Language (cont.) Evolution/Extension:

If a new command/control is needed, it can be added to a new @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 convergence.

1 genetic2 Round := 50;3 r := 0;4 while ( r < Round ) do5 g :=0;6 tmp := 1.0;7 init;8 while ( g < Maxgen ) do9 pm := (1.0 / 1250.0) + (0.0042 / tmp);10 callGA;11 tmp := tmp * 2.0;12 g := g + Epoch13 end;14 r := r + 115 end16 end genetic


Case Study: PPCea (cont.) The SOA-based PPCea is implemented as

follows: WSDL is an XML-based language to describe

a service. 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 introduced: 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 ideology.)

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 passing.

The experiment shows that interoperability and tooling support challenges can be overcome by using the SOA approach.

Oracle BPM provides a very good debugging functionality.


Case Study: PPCea (cont.) Evolution/Extension:

If a new DSL statement is needed, it can be added to a new @WebMethod or a new web service can be created.

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 -> random point mutation)

Lexical and/or syntactical evolution, we concentrate on editing WSDL if needed.

PPCea’s 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

PPCea :

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 pullsTrailer6 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



2 Transmission : one-of (automatic, manual)

A Transmission XML input for FeatureWS



A SOA-based FDL program written in WS-BPEL



Output of the FDL program: Six constrained car alternatives


Case Study: FDL (cont.) Evolution/Extension:

none-of operation: identically acts as an exclude constraint.

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 SOA’s 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 statement. 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 metamodel.


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

alternative. Each web service creates an internal hash table to

interpret, validate (against an XML schema, if available) and store necessary variable information.

For CoCloRep and TCPN, no symbol table introduced.


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-BPEL’s great flexibility may be also misused

and can result in potential pitfalls. For CoCloRep and TCPN, syntax are defined in

metamodel


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 approaches.

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 users.

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-BPEL’s

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 WS-BPEL.


Conclusions SOA-based DSLs offer five implementation advantages:

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 implementation.

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.


Questions? Source code (WS-BPEL, WSDL, Java, C#),

snapshots, and demo videos are available at http://zimmer.csufresno.edu/~shliu/research

Any feedback and suggestion is welcome: [email protected]

A SOA Approach for Domain-Specific Language Implementation Shih-Hsi “Alex” Liu 1, Adam Cardenas 1, Xang Xiong 1, Marjan Mernik 2, Barrett R. Bryant 3,

Documents