~~CLOSETOC~~
<html><font color=#990000 size="+2"><b>Domain Specific Language Tutorial</b></font></html>

A [[wp>Domain-specific language | domain-specific language]] (DSL) allows users to express data processing logic using terms and taxonomy relative to a busines or problem that they are trying to solve.  For example instead of a general purpose SQL query like ''SELECT Employees from HR.Employee WHERE status = 'active''' a DSL query may simply say ''LIST ACTIVE EMPLOYEES''.  Adapting the language to utilize business terms and taxonomy allows business users with low technical skills to be more effective at solving business problems and implementing solutions without knowledge of underlying technology details.  It also allows a business to make use of common semantics and terminologies across departments and business functions, putting everyone on the same page.

Domain-specific languages are often developed as part of a specialized system and have typically required programmers with a high degree of domain expertise and programming skills to design them. This happened because traditional language processors that understand and interpret complex language-like commands have been difficult to write, until now.

The StreamScape application engine provides a flexible and open language processor that allows users to create their own language and query constructs, mapping such language verbs, called [[wp>Morpheme|morphemes]] to Service Call parameters.  This capability separates language definition from functional implementation.  For the first time, system developers can present a domain-specific, business oriented language to their customers (the business users) without the need for complex and time-consuming application development.

Language processors are context-specific, meaning that each service can have its own set of language commands (morphemes) and the RPL scripting environment will automatically combines all commands into a unified language.  For instance, using the example above, lets assume that a Human Resources employee would like to find out a list of all active employees, package them as an HTML document and E-Mail the list to a group.

A developer may create an application fabric service called ''HRQuery'' which allows users to call a number of methods that return information from an underlying HR system.  The methods may include additional options to save contents as an HTML document.  The developer may then start an instance of this service for the business user (lets say its Joe).  Our service will be called ''HRQuery.Joe'' and the user will be able to access it via SLANG. 

Lets also assume that another developer has already created an E-Mail service called EMail that allows users to specify a person or group to send E-Mails to and allows them to specify attachments. There is one Main instance of this service called ''EMail.Main''. The actual underpinnings of access to an E-Mail server or the HR system are hidden from the business user, yet all the functionality has been exposed via a set of //domain-specific morphemes// that are part of each individual service's language processor.

In our example the business user may write a script like the following to get the job done:

<code dsql>
  use HRQuery.Joe
  LIST ACTIVE EMPLOYEES SAVE AS HTML @ C:\mydocs\activeUsers.html
  use EMail.Main
  SEND MAIL TO hr-users@acme.com SUBJECT 'Latest Active Employee List' ATTACH C:\mydocs\activeUsers.html
  use ..
</code>

The DSL engine allows users to expose functionality mash-ups, providing true re-use of services.  A business user does not need to know much about the location of the services, their capabilities or how to call them.  No workflow or orchestration engine is required to assemble services into a process.  And the entire script can be submitted via Web Browser or even abstracted further by wrapping its execution in a function.

If users need additional control a simple web-based user interface may be created that will generate and run the language requests.  Note that in this case the web developer also does not need to know anything about the underlying systems, service architecture or how to do server-side programming.

====DSL Processor Overview====

====Building a Syntax Tree====

====Mapping Morphemes to Service Calls====

====Sample Service Call====

====Passing Values between Service Calls====

