Re: Is Systems Software Research Irrelevant?

[Sundar Narasimhan <address@hidden>]

   Real component architectures, in the sense of an architecture that lets 
   two programs interoperate
   even if the programs were written by disparate people in disparate 
   places under very different
   adminstrative environments, require *more*, not *less*, declarative 
   semantics.  CORBA and
   RMI are just a start; at least they give names to operations and specify 
   input and output types.
   The whole WSDL/UDDI/SOAP path is a somewhat improved version of the 
   same.  But even
   that's really not good enough for a lot of things, because the above 
   technologies only deal
   in single request-response interactions, whereas a lot of real 
   interactions have a lot more steps
   than that.  You need to have what eXcelon's BPM product (what I used to 
   work on) calls
   "collaboration definitions", also known as the BPSS stuff in the ebXML 
   standard.  These
   are basically declarations of choreography of messages: A sends a foo to 
   B, and then B
   sends a bar to A, and then A might send either a baz or a frob to C, and 
   so on (picture
   a little flow chart). And the protocols have to allow for asynchronous 
   communication, too.

Dan: I think of CLR as standing somewhat opposite to this view, and
must say that I find merits in what both you propose and what CLR and
other "infer the interface from the binary" approaches propose. The
basic problem (to me at least) is that the semantics of operations and
the co-ordination (what you call choreography -- which is really a
uni-dimensional expression, usually by a programmer, of what the
expected sequence of operations is) is left either "unspecified", or
worse, specified in artifacts that are not in-the-source -- such as
IDL/WSDL files etc. In this sort of situation, you run into problems
of "who will maintain the "choreography" file and ensure that the code
gets regenerated when it changes" etc. Precisely the same sort of
problems faced by the UML community -- where much time/energy have
been used to solve the "round-trip problem" (real designers and
researchers don't use UML still, do they? :)

I've never understood this fascination with "arbitrary
composability" of software units. The engineering envy that software
designers/implementors have has done us all a great dis-service don't
you think (why do people want to treat software as a bunch of bricks)?