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, USA
2University of Maribor, Slovenia
3University of Alabama at Birmingham, USA
4University of Alabama, USA
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.)
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 promotion.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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

IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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).
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
Bluetooth
USB
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
Case Study: PPCea
 An imperative
DSL for
Evolutionary
Algorithms. It
controls
parameter
settings to
balance an
evolution
process toward
optimization
and
convergence.
1
2
3
4
5
6
7
8
9
genetic
Round := 50;
r := 0;
while ( r < Round ) do
g :=0;
tmp := 1.0;
init;
while ( g < Maxgen ) do
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 genetic
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
Case Study: PPCea (cont.)
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 domainspecific parameters
Entropy
Compute the randomness of a
population
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 domainspecific
parameters within.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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)
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 WSBPEL 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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 onepoint 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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
Case Study: FDL (cont.)
FeatureWS’ WSDL
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
Case Study: FDL (cont.)
2 Transmission : one-of (automatic, manual)
A Transmission XML input for FeatureWS
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
Case Study: FDL (cont.)
A SOA-based FDL program written in WS-BPEL
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
Case Study: FDL (cont.)
Output of the FDL program:
Six constrained car alternatives
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 domainspecific 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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 endusers if XML schema validation is not
involved.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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 domainspecific parameters.
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010
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:
shliu@csufresno.edu
IEEE 6th World Congress on Services. Miami, FL, USA. July 5-10, 2010