Abstract Platforms & Interaction Design

I'm busy reviewing some journal papers, and (without pre-empting the contents) it's got me thinking.

There always seems to be a tension in MDD/MDA when designing abstract interactions. Some approaches assume that it's best to expose only the kinds of interactions available in a class of platforms in the PIM modelling language: e.g. "sychronous call" in the modelling langauge represents "method call" and "operation invocation", and other kinds of synchronous calls that behave much the same. Similarly, "async message send" can represent "oneway operation", "queued message", etc.

Other approaches like to have more abstract interactions in the PIM modelling language, and then map or refine these into more complex interactions in a lower level model, until finally the constructs in the implementation language can be used directly. It allows for an abstract design to be implemented in more diverse ways, on more classes of platforms. e.g. an interaction can be designed that results in values being shared by two or more components in the system without specifying who initiated the interaction, or how many messages are passed, or whether they are synchronous or asynchronous. This seems to me to be a better approach as it frees the designer from the fairly rigid paradigms imposed by platforms such as Java remote method calls, MOM, etc, while still allowing any of these platforms to be used for implementation (within limits - hopefully well specified or easily discoverable).

BUT, the drawback of this approach is that when one of the established platform paradigms (like transactional method call with user-defined and systems exceptions) is actually exactly what the designer wants. I'm talking about when its properties are what's needed by the application domain, not because the style of interaction is necessarily available in the target platform. In this case the abstract interaction paradigm is usually a pain in the butt, as a complex arrangement of messages and constraints on those messages is needed to "simulate" the required interaction.

The solution seems to be to allow patterns of simple abstract interactions which are equivalent to the common platform interaction constructs to be available as templates in the abstract language, so that (a) the designer who knows what they need can call it by name, and use it without construction from primitives, and (b) easy, reusable, perhaps formally proven, mappings can be made available to platforms that support this construct natively. And that (c) more complex, reusable, perhaps formally proven, mappings are available to platforms which do not support it natively. (And perhaps additional well-formedness rules that must apply to the abstract design need to be applied when the non-native mappings are used).

In short, let's not throw out the well-understood interactions styles that are directly implemented in some concrete platforms when we introduce abstract platforms, because sometimes they are an exact match for the semantics of the application.