Won't that info be available while "discovering a service" ie., your
(following) first addendum item ?
- Defining how available services become known
to the rules language interpreter? (At least
OCP-speaking services)
Good question. It all depends on the result of service discovery. If
the result of service discovery is service ID and IP:port pair, then
no. If the result of service discovery is service ID, IP:port pair,
and complete service profile, then yes. I assumed the former context.
I assume the latter context ;-) Atleast that is what is done for web service
discovery.
In many cases, the service interface will be hard-coded in some OPES
processor configuration file, avoiding any dynamic discovery. The
question is, do we want to be able to write a P interpreter that only
understands one (standard) service interface description (possibly
supplied by the service vendor) as opposed to supporting multiple
non-standard description formats (also possibly supplied by service
vendors)?
And, even if we declare standardizing service interface description
out of WG scope, we still must document how an invocation call in P is
translated into OCP commands, right?
How about supporting non-std interfaces as additional module?
For example (pl forget the syntax for now):
Services.invoke(serviceA,1,2);
// Invokes the std OCP service, serviceA - OCP service supported by default.
import ICAPService // A special module that supports invoke method on ICAP
services
ICAPService.invoke(serviceB);
Geetha