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@xxxxxxxxxxxxxxxxxxxxxxx]
> 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.
> >
> >
>
>