Re: Fwd: Re: DAML-S ProcessModel

Hi Michael --

a couple quick points ...

Michael Kifer wrote:

> >>>>> Message from Bijan Parsia <<bparsia@isr.umd.edu> > writes:
>
>     > Me == >>
>     > Sudhir Agarwal <agarwal@aifb.uni-karlsruhe.de> == >
>
>     >>> To support choreography, composition, simulation, verification
>     >>> and similar activities.
>     >>>
>     >>
>     >> OK. And How?
>
>     > Well, the short answer is to direct you to the paper list on
>     > the daml-s site.
>
> Bijan,
>
> can you be more specific about which papers address the aforesaid problems
> in the context AND make essential use of DAML-S process specification
> sublanguage (where all kinds of composition and if-then-else are required).
>
>     >>> >Why should a web service
>     >>> >provider show how his services works?
>     >>>
>     >>> Because I, the client, might have need to coordinate with
>     >>> different phases of some one of his services. For example, if
>     >>> some step of the service requires feedback, authorization,
>     >>> etc. from me, I might want to know when to look for such
>     >>> requests. If it involves transfer of money, I may have fairly
>     >>> complex arrangements to make for this.
>     >>>
>     >>
>     >> Requirements of a web service belong in the preconditions.
>
>     > Maybe not all requirements. Maybe some things are modeled
>     > better eleswhere. We are talking engineering tradeoffs, yes?
>     > As far as I can tell, you didn't consider the needs I outlined
>     > above.
>
>     > What if I *need*, or just *want*, to have fine grained
>     > monitoring of the service your provide. I want *auditability*,
>     > and *oversight*. I don't just want a progress bar.
>
> But for this you don't need to know the exact process model that underlies the
> service. I have seen this argument a few times, but haven't seen a
> concrete use case (beyond general arguments).

>
>
>     > Why do I want these things? Well, first, who cares as long as
>     > I want them? But a rational reason is to coordinated with
>     > other activities. If I'm supposed to pay *at a particular
>     > point* I might want to delay the actual transfer of fund in my
>     > *internal* accounts until the last second.
>
> For this you need to know the constituent subprocesses and constraints
> over them. You don't need to know the exact structure of the process
> (such as if-then-else's and friends).

I don't think Bijan was trying to say that having the exact structure of the
process is the *only way* to enable these things.  And I don't think anyone on the
DAML-S Coalition has tried to argue that it's the only way.  However, it might be
that having the exact structure is easier to work with and/or more familiar and
intuitive for developers.  I'm just saying it might be - I wouldn't know how to
substantiate such a claim.

>
>
>     >> If a client only
>     >> what to know which services participate in a complex service,
>     > it is enough to
>     >> specify a list of participating services.
>
>     > Oh come on. Sure, *if* that's all they want to know. But I
>     > explicitly pointed out that I may want to know *when*, or want
>     > to know which one comes before the other. I may want to
>     > simulate what the service does.
>
> Constraints will tell you what comes before what. I doubt that simulation
> of a service is useful in practice.

I don't see why it would be any less useful than working with constraints, for
most purposes (and I suspect it would be more useful for some purposes).  In fact,
some may feel that it's easier to work with a complete procedural representation
than with constraints.  Roughly speaking I'd think that working with constraints
requires more "reasoning" (of whatever kind) than working with a deterministic
procedural representation.  Also, note that if you can "simulate" a
representation, you can execute it; that is, you  have the potential to use the
execution engine in real-time, on the server side as well as the client side.  I
think that's something that's perceived as having enormous software engineering
value.

> Besides, if you need to simulate a
> service, I don't see what is the added value of describing the process in
> an ontology.

I'd agree with that.

> You can describe it in BPEL4WS for that matter. Your simulation
> would be even more precise.

If you are suggesting that DAML-S composite process representations are more or
less "in the same space" as BPEL workflow representations, then I'd generally
agree.  That is, there's no claim that one would need both in the same system.
(However, I emphasize "more or less", because certainly there are many differences
between the two.)  Note that the work on DAML-S was begun before there was any
BPEL, and also, if I remember correctly, before WSFL was "out there".   Part of
the motivation for the DAML-S composite process representation was simply to have
a style of representation that's consistent with "other stuff" on the semantic
Web, and usable by various Semantic Web reasoning engines and tools.

Regards,
David

>     >> Why all these constructs like
>     >> if-then-else, while etc.?
>
>     > See above.
>
>     > There also definitely seems to be some sort of "customer"
>     > demand. BPEL, WSCI, Web Services Choerography, even DAML-S. Do
>     > you deny the demand?
>
> Yes, this is exactly what I am saying (but seem to be coming to a
> different conclusion than you :-). I can see where BPEL4WS can be used
> here, but I have doubts that "declarative" process specifications a la DAML-S
> can play significant role in semantic Web services. I haven't seen a
> convincing case for this.
>
>         regards
>           --michael

Received on Tuesday, 27 May 2003 10:31:26 UTC