Domain-Specific Languages and Web Services

This past week, in my graduate class we discussed “system integration and agreement at the semantics level”. My class is about “web services”, a subject which I have been covering in a variety of ways in the past two three years.

In one offering, I covered the languages and the technologies in great detail.

In another, I saw the subject very generally (as an integration technology) and I asked the class to develop an integration project; that time, most students decided to use/learn REST APIs and we ended up talking a lot about a variety of web-based user-interaction REST-based tools.

Next, I decided to devote a substantial part of the class to “services science” readings, examining the overlap between web-services technologies and the issues around developing and offering services, based on software.

This year, I started with an introduction to software architecture, then moved through a review of middleware technologies for distributed-software development, then discussed WS* and REST, and reached the point of discussing the semantic-web vision and current state-of-affaires last week.

Among my favorites over the years have been the papers in the 1995 interoperability issue of the ACM surveys, and especially Frank Manola’s paper on “Interoperability Issues in Large-Scale Distributed Object Systems”. The core idea of that really nice short paper was that different types of middleware support different degrees of interoperability and assume different types of agreement between the to-be-integrated software systems.

• For example, at the most basic level, a marshalling/umarshalling middleware guarantees the interoperation of two systems at the level of “exchanging values” when the systems in question agree at the level of data representation.
• Remote-procedure-call middleware guarantees the interoperation of two systems at the level of “invoking each other’s procedures”; to that end, in addition to be able to exchange values (as operation names and parameters), the to-be-integrated systems must also agree on a (set of) basic message-exchange workflow(s)
• And then we have the vision of semantic interoperability, which requires agreement at the level of semantics, so that each object shared by interoperating systems enables semantically consistent inferences by each of these systems.

Reviewing this idea in class, we talked a lot about how semantics might be defined:

• in terms of a vocabulary, whether closed or systematically extendible (so that data tuples across systems can be mapped);
• in terms of a data model, potentially hierarchically organized in a taxonomy (so that properties of data elements can be transferred across systems based on inferences relying on the data-model relations); or
• in terms of a full-fledged ontology, where inferences can be made on the basis of  rules defining invariants within and constraints across data elements.

This discussion helped me rethink the methodology behind (a couple of) our recent project(s) where we have been developing (a) a multilayer domain-specific language for characterizing a domain and the various systems in it, (b) a web-service infrastructure for maintaining this model and extending it to cover more systems in the domain by mapping the system-specific domain models to the general language, and (c) web services for querying the data model in a manner that makes the underlying distributed infrastructure transparent to the issuer of the query.

It seems to me that this particular methodology (as exemplified in SociQL, Diego Serrano’s thesis work) represents a sweet spot in the quest for semantic integration, including

1. the SociQL language at three levels of abstraction
   • the basic level of SociQL defines a closed data model (a few terms and relations among them) in terms of which social systems can be understood
   • at the next level refinements of the basic data model can be expressed to specify the system-specific data models; these refinements are guided by the semantics of the basic level – in fact, they have to be specializations of this basic model
   • at the third level we have the actual data across the various systems
2. services to populate the third level of SociQL by invoking system-specific data-access procedures, whether they are web-service APIs or SQL queries, and
3. services to extend the second level of SociQL by defining mappings of data models of new social systems to the basic SociQL level.

In this methodology, the semantics is not explicit (not declared in a formal language); instead it is captured in the web services that map new systems (and their data models) on SociQL. This is both a shortcoming (in principle, explicit semantics make system more explainable and maintainable) and an advantage (since it allows “malleable” software implementations to map systems to the shared SociQL model).

I am not quite happy with the clarity of this document (and I will need to keep working on it on my head) but it just feels like it is maturing and I hope it was not too prematurely born and it does not read terribly mishappen.