The notion of a protocol becomes important when two or
more parties communicate with each other, forming a
collection of message exchanges of a specific duration (3
millisecond; 3 seconds; 3 hours; 3 years; 30 years). A
protocol is followed by Alice, Bob and Carol at some time
on some date in March 2010 in London; and the same
protocol will be followed by Ann, Ben and Charlie at
another time, all of them staying in say Mars. But what
does it mean their interactions follow a protocol? 
How protocols can be described 

Before that, we may start from this question, the
same question we posed in the case of diplomacy: why
may protocols be important in communicating systems?
This time we are not in diplomacy: we are in
communicating systems. But the reason is essentially
the same: without protocols, a predefined way to
interact with each other, it is hard to do a
meaningful interaction: they simply cannot
communicate effectively, since they do not know when
the other parties will send their data, what kind of
data, through which channels, etc,. it is too costly
to carry out communications based on guess works and
frequent mistakes. Simply, it is not feasible as an
engineering.

So we need protocols, each of which represents an
agreement on the ways interactions proceed among
participants. But we have not said in what ways and
to what details we may as well describe such
agreements; how a design of communicating systems
will look like when we position this idea at the
centre of design and description methodologies; and
how the resulting framework may be used concretely in
actual software development in communication systems.
Without having concrete images about these points, we
cannot answer your concrete concerns, whether such a
method can indeed reduce the construction time,
leaving designers to other more productive
activities.


The descriptive basis for sequential computing
developed over many decades is not only just
useful for the system whose major mode is {\em
  data} (e.g. objects) and {\em operation on data}
by programs (e.g. through method calls); it is
also a fundamental part of describing large
distributed systems. After all, any
large-scale system involves sequential part:
whatever we do, sequential calculation {\em is} an
essential part of computation, from reading items
from a data structure (say XML document),
transforming a datum to another form and yet
another, constructing a stream of video data,
writing to and reading from a database and getting
an ack. When we do a sorting of an array (which
can be done in parallel), we wish to obtain the
final sorted data from the initial unsorted data:
there is a sequential phase change between them.
%%
Practically this means that we need to integrate
the methodology for modelling and programming
communicating distributed processes with what
people took pains to create as modelling
methodologies for sequential programs and data
structures over years. 



But this does not mean we are going to merge oil and
water. This integration should be 
about distilling the best wisdom from traditional
methodologies, positioning them in their right place in
general software development methodologies, and obtain a
unifying framework. This is not just an ideal: if not,
we cannot teach that methodology to people in
Chennai, Tokyo, London, Beijing, Paris, ... as we are
teaching modelling and programming methodologies for
sequential programs now. 