Domain Specific Languages.

[toby.considine@fac.unc.edu]

Meditate on them, consider them, google them. 

Definition:

A domain-specific language is a programming language tailored specifically to an application domain: rather than being general purpose it captures precisely the domain's semantics. A DSL-based development methodology addresses the need for increasing domain specialization in the software engineering field. Domain-specific languages allow the concise description of an application's logic reducing the semantic distance between the problem and the program.
(Diomidis Spinellis)

http://www.dmst.aueb.gr/dds/pubs/jrnl/2000-JSS-DSLPatterns/html/dslpat.html

Why use a DSL?
(btw, a GPL is a general purpose language)
Easier programming 
Because of appropriate abstractions, notations and declarative formulations, a DSL program is more concise and readable than its GPL counterpart. Hence, development time is shortened and maintenance is improved. As programming focuses on what to compute as opposed to how to compute, the user does not have to be a skilled programmer. For example, in the case of recompilation, writing a program to explicitly test all file modification times in order to incrementally rebuild a system would clearly be lengthy, tedious and error-prone, as opposed to using a makefile. 
Systematic re-use 
Most GPL programming environments include the ability to group common operations into libraries. Though some are standard libraries, re-use is left to the programmer. On the other hand, a DSL offers guidelines and built-in functionalities which enforce re-use. Additionally, a DSL captures domain expertise, either implicitly by hiding common program patterns in the DSL implementation, or explicitly by exposing appropriate parameterization to the DSL programmer. Thus, any user necessarily re-uses library components and domain expertise. 
Easier verification 
Another important advantage of DSLs is that they enable more properties about programs to be checked. In contrast to a GPL, the semantics of a DSL can be restricted to make decidable some properties that are critical to a domain. For example, make reports any cycle in dependencies and thus totally prevents non-termination (assuming the individual actions do not loop). 
Although all DSL features listed above address important software engineering concerns, they do not say much about the way applications based on DSLs should be structured. In fact, DSLs strongly suggest particular software architectures.

http://compose.labri.fr/documentation/dsl/dsl_overview.php3

http://www-106.ibm.com/developerworks/blogs/dw_blog_comments.jspa?blog=352&entry=53398


So why am I talking DSLs to this group?

What we are constructing when we have application fabric consisting of web service end-points is an application based upon a Service Oriented Architecture (SOA). SOA and SOAP are becoming so intertwined that some have proposed (horrors!) that the acronym be redefined as simply the SOA Protocol.

Within this realm, the realm wherein people are constructing large architectures, with many SOAP end points, there is some focus on recognizing a quality SOAP end-point.  Even without knowing the domain-specific knowledge, there are things that the practitioner can recognize as being part of a quality implementation.

I have suggested previously that one way to recognize a quality XML dialect is that it is pre-adapted for easy transformation for consumption by its peer realms (i.e. oBIX to GBXML).

Now I am suggesting another one, one that is creeping into the SOA-oriented BLOGS across the internet: A quality XML Realm when implemented as a SOA end-point may be indistinguishable from a DSL.