On Tue, 29 Jun 2004, Markus Hofmann wrote:
It moves functionality I would expect from a service itself into the
rules language!
I believe I understand your concerns.
The outcome of this discussion will have a paramount effect on initial
P specs and, with some luck, on P success. So let's proceed with care.
We are trying to find the right scope for P. We all agree that P is
used for selecting services based on messages. We all have an
understanding of what a typical service does to a message (block,
filter, or modify). We all realize that a lot of customizations (i.e.,
using logic and data specific to a local service invocation
environment and to the message itself) may be required to adapt the
message correctly; some of those customizations might be quite
complex. We may disagree on where some of those customizations should
be taking place and how they should expressed.
Rather than building all these fine-grained capabilities into the
rules language itself, I would prefer a very simple rules langueage
that allows me to invoke services - all the logic and more
fine-grained rules are part of the service.
The whole reason we want to have callout servers is to move services
out to a separate server. Are we now trying to move some of the
processing complexity back into the OPES processor in form of a
highly programmable, compelx rules language that allows
"programming" of actions?
I believe you highlighted the core of our problems and also hinted at
the solution!
Here is a key question: Why do we have OPES service as a distinct
entity? Why do we not simply talk about OPES processors that somehow
adapt messages? Calling a piece of code a "service" does not make it
more efficient. Placing a piece of code on a separate box is not
always a good idea (or we would not have software libraries and
integrated appliances).
I believe the primary reason we logically isolate services from
processors is that we expect and want many services to be standardized
and commoditized (based on their functionality, separately from OPES
processors). Folks will be able to plug in the "best" virus filtering
service, the "best" translation service, the "best" mobile rendering
service, etc., all selected among many standardized offerings.
If services are not easily pluggable/interchangeable, if there are
only a few vendors building a few services, then we are wasting our
time here. IETF WG should not be concerned with technologies that
support just a few vendor products.
So what? Well, if our operating environment is a large set of
standardized and commoditized services, then those services cannot be
efficiently customized by service _manufacturers_!
For example, most customers today cannot buy a customized version of a
disk drive or motherboard for their PC. They can select from a variety
of models that will all comply with a few standards for size, voltage,
and functionality. Manufacturers of drives and boards cannot know
exact user needs and have to ship with reasonable defaults.
Now, if customizations are essential, but OPES services cannot be
customized by their manufacturers, and the number of manufacturers is
large, there are two sane customization options for OPES
administrators:
- customize OPES processor using a common rule language:
if (message meets some condition) then
apply(some service to message)
- customize OPES service using a common service-customization language:
if (message meets some condition) then
apply(some service function to message)
Note that an OPES administrator will end up writing pretty much the
same kind of rules in either case. That is, regardless of what is
customized (processor or service), the same rule language is needed!
In summary, we cannot assume that commoditized services will be
customized by their manufactures and, hence, we cannot "offload"
customization complexities from P to manufacture-specific
languages/solutions. Same for OPES processors. We have to support
those customizations in P, which may be used to customize OPES
processors and/or services.
Do you agree with the above logic?
If yes, here is the next logical step. Given a set of commoditized
OPES processors, commoditized OPES services, and a single rule
language to configure/customize them, what should the minimal scope of
that language be? I believe the answer is that "the language should be
good enough for expressing all common OPES customizations" simply
because that language is the _only_ customization interface an OPES
administrator will have.
For our work to make sense in IETF setting, we must accommodate common
customizations _natively_ in P. We must not rely on processors or
services to provide OPES administrators with non-standard ways of
doing some part of that customization. Commoditized processors and
services will not have non-standard interfaces, and an IETF WG should
not care about markets where there are just a few vendors and those
vendors are using a few proprietary interfaces.
Is there a flaw in the above logic?
Please note that the above does not give us the answer for, say,
whether P should support user-defined functions or full regular
expressions. However, it may give us a framework to derive those
answers:
- If user-defined functions are essential for
matching messages with services, then P must have them
- If full regular expressions are essential for
matching messages with services, then P must have them
We just need to debate whether X is essential for a good matching
interface. If it is essential, it must be supported natively in P.
In the absence of such a framework, we now have to debate two things:
- whether X is essential for a good matching interface
- whether X has to be supported natively in P or as
a part of some custom service or processor knob
Sorry for such a long message. I could not find a shorter way to
express this idea. Hope it makes sense.
Please comment.
Thanks,
Alex.