RE: P work in new charter

Alex,

I agree with your orchestration example. The point here there are other work
that does that, check CDL in W3C and BPEl in OASIS.

I think it is important that we scope the P well before we start the work. 
I really do not see how we can scope well in the charter without fully
understand the do or do nots first.
I is going to be a fine line.


Abbie

-----Original Message-----
From: Alex Rousskov [mailto:rousskov(_at_)measurement-factory(_dot_)com] 
Sent: Wednesday, June 30, 2004 1:13 PM
To: Geetha Manjunath
Cc: OPES WG
Subject: Re: P work in new charter

Geetha,

      I think there are two very different panes of 
discussion/scope, and I failed to identify them clearly in my 
original classification.

1) One pane is whether P can be used to write user-defined
P functions and user-defined collections of P functions.

Markus concerns are that user-defined functions add too much 
complexity. Markus suggests that such complexity can be 
implemented in services using some service-specific 
interfaces. My longish response tried to argue that this 
service-specific loophole is not feasible because services 
will be commoditized and will need to express the same kind 
of selection rules using some standard language. Since what 
we need to express would be the same, we should use one 
language for that, regardless of whether the future will 
place complex rules on processors, services, or both.

2) The other pane is whether P can be used to implement 
services themselves.

I think the answer is that "P can orchestrate adaptations, 
but cannot perform adaptations natively". In other words, all 
message adaptations are performed outside of P. For example, 
the following code should not cause any problems:

      if (message meets some criteria) then {
          services.adaptation1(message); // apply adaptation one
          services.adaptation2(message); // then adaptation two
          services.adaptation3(message); // then adaptation three
      }

The following is still acceptable if HTTP module supports 
header updating operations (which is something we have to decide):

      if (http.message meets some criteria) then {
          http.message.headers.delete("Content-Length");
      }

But implementing http.message.headers.delete() method 
natively in P will not be possible because of P's 
single-assignment semantics, lack of loops, data structures, etc.

Alex.

On Wed, 30 Jun 2004, Geetha Manjunath wrote:

Hi,
I think Alex has put the scoping of 'P' discussion in a

nice way... I

mostly agree with his agruments..

In terms of  what 'P' would enable:
* Rule Specification : The filtering services themselves would be 
provided by vendors (say, virus scanners) while the configuring 
conditions (rules) will be  described/specified using the 'P' rule 
language.
* Writing simple filters/actions: While modifying a message

to be able to

call several commoditized filters may be one of the

examples (Alex), I would

see the need for writing actions more when the actions

themselves are very

simple - may be to just put some additional authentication

controls onto

services, where the OPES processor would just return a 40x

response. It could

also be used to compose output of multiple filters (I

remember a discussion

we had on this mailing list about how pipelining of filters

should function

and so on. This now leaves the decision to the rule

writer). There will be

many more use cases I am sure.
* Writing modules in 'P':  Since a set of rules themselves

may need to be

reused many a times, we may want to create customized

reusable modules in 'P'

.

While the above are under the category of  "#1. How deep

does P reach?

(P scope)", I want to just add on additional option to "#2.

How deep

does our charter reach? (WG work scope)" or an extension to 2c.
(d) defining mechanisms by which a user can communicate rulesets to 
the OPES processor.

Comments Welcome.
(sorry for joining in late on this thread - I was on a

business trip

could not see my emails earlier )

Thanks and regards
Geetha

Alex Rousskov wrote:

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.