EIPs in ROC

Randy Kahle has recently written a blog entry which artfully expresses the thinking behind the yearnings for a new ROC (Resource Oriented Computing) language. I suspect that most ROC users would be happy just to see a better syntax for module creation but, as Randy points out, a ROC language should provide a better way to conceptualize the information flow through the system.

I've thought for some time now that what's missing in NetKernel is an abstraction of the higher level patterns of information flow through spaces; an implementation of EIPs (Enterprise Integration Patterns) for ROC. EIPs in ROC could be made manifest in a couple of ways, the simplest being to express the pattern as a particular composition of existing space elements. This approach, however, strikes me as analogous to expressing a pattern in an assembly language without macros: too detailed and hard to repeat correctly. A more powerful solution would be to express some of the simpler EIPs in ROC by encoding them directly as new types of overlays. The most recent overlays, such as the Pluggable overlay and the Branch-Merge overlay, seem to be attempts to encapsulate such patterns of usage. Sadly, these fall far short of the simplicity and beauty that they could have if they were not mired in the grammar-less verbosity of XML. (1)

Please note that, by saying "patterns" (inherent in EIP above) I mean something more abstract and more encompassing than the existing recipes for the connection and interaction of spaces, which are labeled as "Module / Space Patterns" in the NetKernel documentation. While these recipes are a step in the right direction, their level of granularity seems too small to express anything but the simplest EIP. In addition, their descriptions focus on the mechanics of space interconnection and it's very hard to elicit how they can be composed into EIPs.

A new ROC language built around Enterprise Integration Patterns would allow ROC programmers to concentrate on solving their application problems by focusing on the high-level, logical flow of information through the system. Such a language would include, at a minimum, the ability to compose, connect, and visualize some base set of EIPs.  An additional ability to implement arbitrary EIPs would be extremely powerful but might require that the existing facilities to build modules and factories be enhanced, simplified, and canonized into a clean API (re: this forum discussion fragment). If the new ROC language were to eschew XML and to rely on a simple syntax, I feel this would be a huge win. Finally, I believe that a new language built around EIPs would greatly contribute to the usability and adoption of NetKernel and ROC.

1. It's interesting to speculate on the reasons why there are not more higher-level patterns and why they are not easy to spot in NetKernel's standard module. I think the principle of Linguistic Relativity is at work here; the idea that the structure of a language affects the ways in which its users conceptualize their world.