- From: Michael Kifer <kifer@cs.sunysb.edu>
- Date: Wed, 21 May 2003 17:52:28 -0400
- To: bparsia@isr.umd.edu
- Cc: www-ws@w3.org
>>>>> 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).
>> 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. Besides, if you need to simulate a
service, I don't see what is the added value of describing the process in
an ontology. You can describe it in BPEL4WS for that matter. Your simulation
would be even more precise.
>> 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 Wednesday, 21 May 2003 18:02:41 UTC