Alex Rousskov wrote:
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;
There is "customaziation" with respect to service invocation and
"customaziation" of the services themselves. In my opinion, the former
one is in scope for "P", the latter not. Customaziation of the actual
action is part of the service, and not of the rules.
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.
The scope of OPES is to enable such separation "over a distance", i.e.
define the protocols and mechanisms that will allow you to have the
services remote from the OPES processor. The WG is not in the business
of specifying a "local runtime environment".
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?
Why does customaziation of the services have to happen through "P"? I
don't disagree with the need to customize services, I just see that
separate from specifying when to invoke a service. This allows me to
keep my rules language simpler, and for someone else to come up with a
highly efficient "service-customization language".
-Markus