On Wed, 14 Jul 2004, Geetha Manjunath wrote:
Alex Rousskov wrote:
On Tue, 13 Jul 2004, Markus Hofmann wrote:
Alex Rousskov wrote:
- Defining an interface between rules language
and service (at least OCP-speaking service)
How to pass parameters to services? How to
get the result of service application, including
errors, back to the language/program?
I would consider passing of parameters and getting results back into
the language/program in scope. Any other thoughts?
I agree. Supporting just that in a general way is already difficult!
We are talking about any P program being able to pass any parameters
to any service in scope (e.g., any OCP-speaking or perhaps
WSDL-describable OPES service). How will P interpreter know what
parameters are available? Which parameters are optional? What are their
types?
<stripped>
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.
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?
Thanks,
Alex.