On Wed, 30 Jun 2004, Markus Hofmann wrote:
There is "customaziation" with respect to service invocation and
"customaziation" of the services themselves.
Agreed!
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 agree that it would be nice to separate the two, but I am not sure
it is possible.
Can you come up with an example of OPES processor selecting a service
using some simple P rule and then configuring that service using
something other than P? I would like to see if the task of configuring
the service can be somehow kept separate from invoking that service...
Let's call the service-configuration language "S". Suppose we have
service "foo", with three parameters: "a", "b", and "z".
You do not foresee something like the "encapsulated" code below, do
you?
// P code starts is here
if (message meets criteria) then {
service := services.find("foo"); // still P code
service.configure(<![SCODE[> // P code ends here
a = 1; // S code to be passed to the service
b = 2; // S code
z = message.size; // S code accessing P objects??
<]SCODE]>); // P code resumes here
call service(message.body); // P code
}
Or perhaps you assume that we can configure services statically,
regardless of the message context?
// services configuration file written in S
foo.a = 1;
foo.b = 2;
//foo.z = message.size; // cannot be done, no context!
-----------
// rules file written in P
if (message meets criteria) then {
service := services.find("foo");
call service(message); // S config loaded; how to set foo.z?
}
Or is there a better way? Please give an example of how to configure a
dynamically selected service in S without tainting P.
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".
The customaziation of the services have to happen in P (natively or
through embedding S code as in the first example above) because P code
is the only place where we know both the service and its invocation
context. We cannot configure the service before we know what the
service is. And even if we have a static list of services, service
configuration may require knowing the invocation context.
Here is another example calling (and configuring) an HTTP-unaware
content scanning service that needs to know the content MIME type:
if (http.message.mime == "application/exe") then
call services.scan("Windows binary", http.message.body);
else
if (http.message.mime == "text/html") then
call services.scan("HTML page", http.message.body);
How can the above selection/configuration be done without tainting P?
Thanks,
Alex.
P.S.
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".
OPES deals with communication protocols (which could be used between
agents on the same "host", different "hosts", or "distant hosts",
whatever the "host" means). This should not affect our discussion
though.