david,
thanks, very good points.
can u give us the pointer to sprint specifications.
thanks
abbie
-----Original Message-----
From: David Anderson [mailto:dja(_at_)4thpass(_dot_)com]
Sent: Thursday, July 25, 2002 12:05 PM
To: ietf-openproxy(_at_)imc(_dot_)org
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(_at_)4thpass(_dot_)com <mailto:dja(_at_)4thpass(_dot_)com>
-----Original Message-----
From: Abbie Barbir [mailto:abbieb(_at_)nortelnetworks(_dot_)com]
Sent: Thursday, July 25, 2002 7:52 AM
To: Markus Hofmann; Hilarie Orman, Purple Streak Development
Cc: ietf-openproxy(_at_)imc(_dot_)org
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