Some of us have wondered what it was about. We came across pi in
maths and I remember doing a lot of calculus both in maths and
Newtonian physics, but combined?? Any way, here is an extract of an
interview of Mr. Ross-Talbot by the CIO of a major bank (now, that
must be a first for an interviewer - does he secretly aspire to start
a TV career?):
<< So causality started to trouble me, and I was looking for ways of
understanding the fundamentals of interaction, because these
subscriptions to events and the onward publishing of an event really
have to do with an interaction between different services or different
components in a distributed framework.
Many years before I did any of this, I studied under Robin Milner, the
inventor of the pi-calculus, at Edinburgh University. I came back to
the pi-calculus at Enigmatec and started to reread all of my original
lecture notes, and then the books, and finally started to communicate
with Robin himself. It then became quite obvious that there was a way
of understanding causality in a more fundamental way.
One of the interesting things in the pi-calculus is that if you have
the notion of identity so that you can point to a specific interaction
between any two participants, and then point to the identity of an
onward interaction that may follow, you've now got a causal chain with
the identity token that is needed to establish linkage. This answered
the problem that I was wrestling with, which was all about causality
and how to manage it.
At Enigmatec, we told the venture capitalists we were doing one thing,
but what we actually were doing was building a distributed virtual
pi-calculus fabric in which you create highly distributed systems and
run them in the fabric. The long-term aim was to be able to ask
questions about systems, and the sorts of questions that we wanted to
know were derived from causality. For example: Is our system free from
livelocks? Is our system free from deadlocks? Does it have any race
conditions?
These are the sorts of things that consume about half of your
development and test time. Certainly in my experience the worst
debugging efforts that I've ever had to undergo had to do with timing
and resource sharing, which showed up as livelocks, deadlocks, and
race conditions. Generally, what Java programmers were doing at the
time to get rid of them, when they were under pressure, was to change
the synchronization block and make it wider, which reduced the
opportunity for livelocks and deadlocks. It didn't fix the problem,
really; what it did was alleviate the symptom.>>
You can find this at:
http://www.acmqueue.com/modules.php?name=Content&pa=showpage&pid=370
If there still remain gaps in your comprehension, I am sure Steve will
point you to a suitable fount of knowledgeable.
Gervas
SPONSORED LINKS
| Computer software | Computer aided design software | Computer job |
| Soa | Service-oriented architecture |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
