Re: P-services interface in Strawman OPES Charter

On Tue, 13 Jul 2004, Markus Hofmann wrote:

> Alex Rousskov wrote:
>
> > We know how poor humans are at writing bug-free code.  I think that
> > being able to validate much of P code off-line is an essential rule
> > language feature that we should strive to preserve. Unfortunately,
> > that seems to require informing the interpreter of service interface,
> > independent of P code itself.
>
> You start convincing me... Could any of the existing service
> description languages (WSDL?) be of help? Abbie was suggesting this
> before I believe...

Yes, and (after reading the corresponding Content Networking
chapter:), I also suspect that we can reuse WSDL core. This will
require some serious work on our part though. Current WSDL profiles
are based on SOAP and MIME(?), not OCP. We will have to define an
OCP-specific profile and then define how WSDL/OCP can be used to
describe OCP-speaking services for P interpreters.

I can see benefits, but I do not know whether the whole scheme will
work -- it all depends on how flexible WSDL core is, how many
W3C-centric assumptions are in that core. Since this is not a trivial
exercise, it may be a good idea to add P-services interface as a
chartered work item, possibly without a separate deliverable since we
already have multiple "document(s)" for P-related specs.

> I see the following options:
>
> (1) Rely on the rules authors to specify the correct parameters
>      and don't do any offline checking -> no mechanisms for service
>      description needed
> (2) Have an OPES specific "service interface description language"
>      (maybe similar to function declarations in some programming
>      languages?) -> would be part of the rules language (?)

Yes.

> (3) Rely on an existing solution and require OPES services to be
>      described in this language -> nothing to do for us other than
>      refering to existing solution.

... Other than defining how to apply that existing solution
(e.g., WSDL) to OCP-speaking services. AFAIK, OCP-speaking services
cannot be described using any existing WSDL profile. We will need to
build one. This makes (2) and (3) equivalent, unless (2) assumes
service interface declaration *in P*.

Declaring services natively in P is good because it does not require P
interpreter to know another language/interface like WSDL.  Declaring
services in WSDL is good because it allows P interpreter to easily
interoperate with both classic Web Services speaking SOAP and
OCP-speaking services (in theory).

Ideally, you want to obtain the declaration from another, independent
source. In case of Java or C++, that source would be a library
header/interface file. If we use P declarations, we can encourage
service writers to supply them off-line (just like C library writers
supply header files with the library) and even runtime via OCP (to
kill buggy invocation calls before they generate data traffic on the
wire).

> Now, my feeling this that this already goes into discussing the
> solution, I don't see a need to specify any of this in the
> re-charter.  The proposed charter text seems to cover and allow for
> this work, so I would assume we're ok in this respect.

I am worried that if we want to define WSDL profile for OCP, some of
us (or some of IESG) will find that extending W3C technology like WSDL
is out of current charter scope. We do not know whether using WSDL is
the right way to go, but should we just mention that we need to

	Define P-services interface, based on existing interface
	description standards like WSDL, if possible, or OPES-specific
	description otherwise.

Thanks,

Alex.