The Distribution Retreat Day

Two weeks ago, a group of us met up for one day in London to discuss Object Distribution: how we go about the process of designing and developing distributed systems. This page introduces some of our conclusions and reflections from that day.

Here too are some pictures of our deliberations…

After some discussion, we decided to tackle a simple system handling stock control over two sites, a sales office in London and a warehouse in Leeds. We worked on the problem in groups of three half the morning, then met up to discuss findings; we then did the same in the afternoon. We agreed to write up our reflections to discuss with others.

I've organised the contributions only in order of size, larger (more substantial??) first.

• Paul Dyson has produced an interesting and detailed exposition of what the teams did, and his conclusions from and about the sessions.
• John Daniels has several incisive reflections on the design process.
• Kevlin Henney had a rather novel approach to diagramming, and produced some interesting and offbeat conclusions.
• John has also done further research into Java Beans; it seems our understanding of their behaviour was incorrect.
• Charles Weir has some comments on the direction of technology, and on tackling the specification before cranking up the notational methodology…
• David Harvey has several comments on the format and approach we used. He also includes a book recommendation.
• Tony Willoughby provided an executive summary of his learning.
• Alan Wills has been working on a worked example of the problem. He promises something for us to comment on RSN.
• Alan has also provided a paper and slide show from a colleague, Matthew West, about the role of components in the enterprise - these may be of interest.
• We're collecting links to related work on the subject. Any contributions welcome.

This page will change; I have some photos from the workshop, and I welcome other reflections or contributions.

We all agreed to spend a while thinking what we'd like to tackle next. Here are our conclusions.

What I’d like to do next is to build the system. We profess belief
that the devil is in the detail but we only really took a high-
level view of how we might build the system. Also, understanding
the relative merits of MTS, EJB, CORBA, etc. means building with
them (or simulated versions of them).

I’d also like to involve a few people who know how to do the
distribution element of the system even if they’re not so familiar
with objects and ORBs. If there are any ‘ready made’ patterns to be
had then these are the people that have them.

I am interested in exploring the implementation details of a real
(small) problem.  Especially the best way to deal with a component
that needs to share its information between several locations.  An
example is the order cpt in the problem we worked on, knowledge of
which was needed in both London and Leeds.  We had a choice between
1) migrating the object,
2) giving partial views of it in each location,
3) transferring data about it.

The solution we adopt will depend on the amount of information to
be shared and the technology we are using.

I suggest we build some partial implementations of the simplified
problem, using several different technologies (specifically, CORBA,
DCOM and Java RMI), and compare the solutions. To do this we need
to

1.   specify the simplified problem
2.   Specify some available solution strategies (e/g object
     migration, etc.)
3.   Implement several solution/technology combinations, and
     compare them along various axes - implementation complexity,
     performance, robustness, scalability, etc.

This will all take time!  Some of it we could do individually,
meeting perhaps in a month to compare ideas/solutions.

Here are my specific proposals for "what next".

1. Define some terms, using a "think tank" session. I note that the
Butler  Component Based Design forum are also going to attempt this
- we might  assist/pre-empt them. As well as component-related
terms, we should define  precisely what we mean by distribution.

2. Ignore distribution and create two designs for our example
problem (or  another, better, problem). One design should be
strongly entity based, the  other strongly service based. Then
examine the impact of distribution. Is  this what Paul and Andy did
at their OT workshop? I think it would help to  implement the
designs, but I don't see it as essential.

3. Assuming that we discover from (2) that you can't ignore
distribution,  hold a session specifically to examine clustering
techniques.

My need is to see a real concrete design for one particular
distribution  strategy. I would therefore like to have another day
working on a design,  with perhaps someone playing the role of
combined client/architect, making  (arbitrary) decisions about
contentious matters, so we can get on with  detailed design. I feel
that leaping into code would waste a lot of time,  and not teach me
more than a detailed design would.

I entered into the retreat process with a mission: I wanted to know
what a distributed object should look like, and how it should
behave. So I visualised the result as a set of 'patterns', 'styles'
or something of that ilk.  Paul's workshop at OT98 tried us on two
possibilities; there must be many more.

The workshop day helped me a bit; we discussed several familiar
technologies (Beans, Lotus Notes, XML); that expands the options
rather dramatically.  But I don't really feel I've got that far.

I don't believe I'd learn much from trying to implement a 'toy'
system.  I'd rather leverage our combined dozens of man-years of
experience implementing distributed systems.  So what I personally
would choose to do is:

1.   Gather together a collection of people with a quorum who have
  been majorly involved with developing at least one successful
  system.  Try to get the domains as varied as possible: Distributed
  DB access, 3-tier, industrial control, Internet web services,
  Intranet services, distribution to share processing over many
  servers, etc.  I'd include non-OO experts too.
 
2.   As a group, brainstorm (1) as many possible patterns of
  interaction as possible, and (2) different categories of
  distributed applications from the list we're familiar with.
 
3.   As groups, match the two categories together, identifying what
  considerations would choose us to use one mechanism rather than
  another.  What are the unexpected problems encountered?  Which ones
  will combine? How does each pattern deal with the 8 areas of
  ghastliness?  Etc.
 
4.   Working together, then individually, summarise the conclusions
  for circulation.

I'm not sure that spending effort implementing the systems we proposed 
would tell us anything. To make it realistic, we'd need to devote a great 
deal of effort to the simulation framework...and in the end, all we'd have 
is a feeling for how easy it is to simulate distributed architectures. I'd 
like to propose instead that we share what experience we _do_ have in 
building distributed systems: both war stories from the projects we've 
been involved with, and comments on effective use of specific technologies. I 
don't think we should be downbeat about this - I'm sure between us we must 
have substantial amounts of hard-won wisdom.

What form should this knowledge sharing take? I suggest we each prepare a 
short document outlining one or more aspects of our experience: we might 
then spend some time (perhaps over several meet-up sessions, perhaps by 
email, perhaps by wiki (if someone wants to set one up for the group) 
cross-examining the witnesses. It's important to keep a record of this 
(which is why the wiki solution would work so well). Though I wouldn't 
want to forgo the opportunity for beer and chat...