-----Original
Message-----
From: David Anderson
[mailto:dja@xxxxxxxxxxx]
Sent: Thursday, July 25, 2002
12:05 PM
To: ietf-openproxy@xxxxxxx
Subject: To chain or not to chain
Hi,
I’ve been lurking
on this list for several months. I have no idea what the protocol is for
introducing myself and whether or not I’m allowed to speak up – as
my company is not a member of the OPES group. However, until recently I worked
at Sprint, where my team issued an RFP for an “Intermediation”
system earlier this year i.e. a customer requirement for an open pluggable edge
server. I know a lot about this topic as my team at Sprint built a working
prototype of such a system and implemented micropayments and other
intermediation functions. We demoed this at the Sprint Developers Conference in
Las Vegas, during October 2001.
I have watched this
debate about callout chaining for some time. I would like to make several
observations and identify what I believe to be several underlying and unspoken
assumptions in the group.
1.No one has ever mentioned whether or not chaining is a real market
requirement.
It seems
to be assumed that the market does not know what it wants or whether it needs
this technology. It is being designed by technologists. However, there does
exist a marketing requirements document from a large telco. Sprint published
one.
2.Functional versus Procedural coupling
The
argument around chaining can be abstracted down to whether or not callouts can be
loosely coupled and functionally cohesive, or whether procedural coupling is
required. This is the 30 year old debate in software engineering about
procedural versus functional decomposition.
There
appears to be an underlying assumption that the switching cost of invoking a
callout is high. If this were so, then procedural coupling would produce a
performance enhancement by reducing the number of redundant switching
calculations. However, if the switching cost of invoking a callout is low, in
comparison to the processing time of the individual callout functions, then
there is little performance improvement to be achieved from procedural coupling
i.e. chaining.
To
decide whether chaining is worth the cost of the protocol overhead and the need
for the callout server, to act as an OPES server (in order to chain), the group
must decide whether the switching cost of invoking an OPES callout from the
flow of the network, is significant. It would appear that determining whether
or not this is significant cannot be achieved until a first cut of the
specification is agreed and the performance can be determined.
Hence,
it would seem too early to make a call on whether or not chaining is
worthwhile.
3.Functional versus Procedural design
Is
chaining even needed? To understand this, we must evaluate whether or not
procedural designs will emerge. We must look to the uses and the usage of an
OPES system and decide whether chaining seems likely.
For
example, let’s imagine the mainline network is http. We are interested in
switching http requests or responses for two reasons: micropayments – pay
per click, subscribe to a set or URLs e.g. New York Times Today; automatic form
fill – a la MS Passport without the application layer interface, i.e. no
need to re-write the URL with a defined set of name value pairs for identity.
Those are just two examples. At the last count my team had 11 applications for
an OPES style system.
Now
consider whether it is likely that we would switch on the same URL for two
different applications, i.e. is it likely that the same URL which needs a
micropayment challenge, would also require a form fill?
The
underlying assumption on this list is that it is too early to second guess the
market and the possible usage of OPES. Hence, the specification should be as
flexible as possible. However, flexibility comes at a cost. It adds complexity,
risk and time to market.
IMO,
providing an OPES 1.0 spec which allows functional callout is a major step
forward. It might be better to take the option theory approach and decide to
keep your options open regarding chaining. There is no guarantee that the
market needs chaining. If later there is demand then exercise your option and
build it into a subsequent version of the specification.
Regards,
David
......
David J. Anderson
Director of Engineering
::4thpass
83 S. King Street, Suite 100, Seattle, WA 98104
phone (206) 749 9070, ext 110
e-mail dja@xxxxxxxxxxx
-----Original Message-----
From: Abbie Barbir
[mailto:abbieb@xxxxxxxxxxxxxxxxxx]
Sent: Thursday, July 25, 2002 7:52
AM
To: Markus Hofmann; Hilarie Orman,
Purple Streak Development
Cc: ietf-openproxy@xxxxxxx
Subject: RE: Chaining of Callout
Servers
good points so far,
I also think that chaining will also add difficulties
on tracing.
I could think of various scenarios
where loops may occur in the chanied callout servers due
to programming errors (or server
failures).
On the otherhand, I could also see the benefits of
chaining if it is done right.
However, My personal opinion at this stage of the game
is to start simple with an eye on expansion, so basically let us start with no
chaining and keep this option open for later.
abbie