Re: Fwd: Re: DAML-S ProcessModel

David, thanks for the clarifications.
I still have my doubts regarding the role of complete process
specification in SWS. Concrete comments within.

> 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.


This is precisely my point: I haven't seen anybody substantiating such a
claim with anything concrete.

I also disagree that a procedural program is easier to reason about than
about a set of constraints. Typically you want to derive temporal
relationships or cost constraints. For the first, you have to analyze a
procedure to extract what a logical constraint system gives you with much
less effort. As to deriving cost constraints from procedural programs --
good luck to you! ;-)


> >     >> 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.

If you are talking about a human developer who would look at the
procedural service definition and write an application to interact with
that service then I agree. However, what does all this have to do with
*semantic* (automated) web services?

Note: I do agree that complete service definitions a la BPEL are useful
for (non-semantic, low-tech :-), current state-of-the-art) services.
But my current thinking is that semantic WS have no use for all that, so
it is perhaps not worth the effort until somebody makes a convincing
(or any!) semantic case for complete WS definitions (and shows where it is
superior to the constraint-based approach).

As far as the concept of semantic web services is an extension of regular
web services, procedural definitions will be there. But I doubt that they
are of much use for a semantic engine.


> > 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.

I believe that WSFL was out there before, but it doesn't matter.  I don't
blame DAML-S for trying to develop its own representation. Back then things
were just starting and it was unclear what will be needed in the
future. But I find it interesting that nobody managed to make a convincing
use case for this feature in the years since. So, it might be time to
reconsider. 

I am not talking about revising this issue in DAML-S, but it is food for
thought this within our joint Sem Web Services Language committee.



	regards
	  --michael  


> 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 15:41:44 UTC