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:[email protected]] 
> 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.
> >
> >
> 
>