Questions and --- Questions

The title is a best summary of my chat with Gary Brown, with whom I am designing scribble: we find there are many questions, to begin with. But without good questions how can we do something as bold as designing a new language? Here is a brief summary. I am a bit in a hurry (still working on poor buyers' protocols etc) so I will hurry through today and will augment it later.

All these topics were first suggested from Gary and later we discussed and agreed that they are interesting questions. Isn't it nice?

1: units of description: static or dynamic?

This is about description of behaviour, a unit for describing behaviour of communicating systems. How much can we learn from the existing wisdom? One of the basic paradigms for description units are clsses. Now classes have both static and dynamic sides: if we follow Should we follow behavioural aspects of classes? Perhaps that may not be effective? In modelling we should not be too operational... But where is the bounday?

2: need data types: but what kinds?

This is data types for messages. There are several aspects.

(1) Should we have an intrinsic data type for the language? This can be:

• Something good and widely used: for example UML data models (with some fix in aggregates: a note from Matthew)


• Invent a simple. clean and neutral data type definition for the language.
  

(2) We need --- dearly need --- a language mechanism to incorporate data types from other languages: surely UML, XML schema in general, Java, C#, C++, ML, ....

(3) In all cases it is important that validation of data types is easy --- your description should be consistent, if it says it is carrying integer it should not be carrying a floating point (but such a check may be needed at runtime: consistency however can be checked at runtime). Of course we first of all want description can be easily done.

3. package-structure --- to organise different kinds of description units

OK we need packages. We are talking about millions of description units for a large corporation ----- so there is no question about the need of packages, which are hierarchically organised (usually through a hierarchy of sub-directories or sub-folders in your file system : we can think of graph structure but perhaps this may be too much).

An interesting thing in the context of scribble is we have not only one but multiple kinds of description units. Let's recall:

• Units of global description of behaviour (choreographies: this will also have several kinds including abstract and concrete ones)
• Units of endpoint description of behaviour (this describes how each endpoint will behave) And perhaps you want endpoint description written in other languages such as UML and Java...
  
• Units of data type description (as noted above: this can include how we can import data types from other languages and facilities)
• Units of description of structures/properties of participants (it looks this is not part of data types --- these guys use behavioural description...)
• Miscellaneous descriptions such as bridges to other language/description environments: this also means you can have diverse code units inside your package structures
  

So there are a lot. To make discussions concrete suppose the standard situation where we use data type definitions (say class/interface definitions) together with behavioural descriptions for describing the behaviour of an interacting system. The latter uses the former: how can we organise them?

• Always put a data type definition in the same directory as that of a behavioural definition.
• Put them separately --- since perhaps we want a generic type used in many parts of the package hierarchy for behavioural description.
  

The former is individualism while the latter promotes sharing. In both cases however it looks it is better to have a single hierarchy for all of these unit types and allow a flexible way to designate these units.

One important point: let's start practically, centring on a specific practice --- such as corporate systems modelling with a slant towards EDA. Then something concrete will come out. If we can find something simple and general in a specific setting, at least its basic elements have universality.

Let's consider the possibility that there are several kinds of universality.

4. Why need two kinds of description methods for interaction?

We need endpoint description language: why?

• This is the target of endpoint projection.
• So it becomes a basis of mapping to other languages (such as Java)
• And it may also be used as a prototype code in its own right to be elaborated.

But the most important reason we need this may be because sometimes we need to start from the endpoint behaviour, for example for existing services or by starting from a service used by many independently from its usage by other guys.

My personal view is that when we are defining a global language we may also be defining an endpoint language --- a basic note is we need a good EPP framework for relating them.

5. We need hooks: and mechanisms to use them.

To connect the descriptions to real-world entities we need hooks. Such hooks are associated with validation mechanisms: for example consider the data type import we discussed in 1.
When validating our behavioural description, it mentions UML class model, then it uses UML class model validation for the purpose of checking everything is all right.

This can happen also internally: we have a global description and an endpoint description and our validation engine checks all work fine.

Or this can be about assertions, or design by contract as it is being called. It will check at least assertion annotations are type-correct and syntax-correct --- and as much as possible it can check if the given description has (at least!) a potential to fulfill the requirement given as assertions.

Or suppose we can add other annotations --- security annotations. A consistency check and other validations can be done in this case too.

So we need hooks and a way to make the best of them. We do not have to aim to have a universal language for such description but we need something basic and even if they are bestr realised by scribble-external facility, we wish to capture a basic shape of how these things can work and at least provide a basic facility for basic features we decide upon. So again we do not try to offer something universal but let's remember the basic staple here, a hook and a validation mechanism go hand in hand.

* * *

OK I finish today here. I hope I at least covered all basic items --- if not all details of our conversation. I may augment some of the points in later posts.