Re: atomic services with no effects or outputs

Well, for simple sequential service compositions this may be the case, 
however when we think about complex services(which most of the real life 
services would be) being composed and executed concurrently, there may 
be interdependencies and therefore specification of preconditions and 
effects become necessary.

Regards,

Monika

Chintan Patel wrote:

>
> What i believe is that the Services for which the composition task can 
> be handled by "Genie" by just matching the Input/Output(IO) Concepts 
> without considering the PreConditions and Effects(PE) then i believe 
> there is no harm in not specifying the PE for those atomic Services.
>
> comments ?
>
> Regards,
> Chintan
>
> ================
> Graduate Research Assistant
> School of Interdisciplinary Computing and Engineering
> University of Missouri - Kansas City
> Kansas City - MO -64110
>
> Ph : 816-931-9981 (R)
>     816-235-2396 (O)
>
>
>
>
>
>> From: Monika Solanki <monika@dmu.ac.uk>
>> To: Mithun Sheshagiri <mits1@cs.umbc.edu>, www-ws@w3.org
>> Subject: Re: atomic services with no effects or outputs
>> Date: Fri, 21 Mar 2003 22:03:49 +0000
>>
>> Just an info: there is a note in the comment tag of the file that 
>> states:
>>
>> NOTE: This is a sketch; not a complete example
>>
>> The example therefore can be made more sell sufficient.
>>
>> For effective service composition, I agree with you, that ideally the 
>> IOPEs of every collaborating service would have to be exposed. I am 
>> not sure at this moment, if and how these should be made mandatory, 
>> in some way in the service description. Probably a parser 
>> encapsulating certain rules could be used. However there is little 
>> that can be achieved without the IOPEs.
>>
>> Regards,
>>
>> Monika
>>
>> Mithun Sheshagiri wrote:
>>
>>>
>>> Hi all,
>>>        There are several atomic services described in the 
>>> CongoProcess file that neither have outputs nor effects. I was 
>>> wondering how can these services be of use to us (entities other 
>>> than the author). In my understanding services either provide you 
>>> with some information (e.g.. ISBN lookup service with the ISBN 
>>> number as the output) or do some world altering activity (e.g. the 
>>> ExpressCongoBuy service whose execution results in the book being 
>>> shipped to its destination). The former has an output and the latter 
>>> has some effect. Here the output or effect implies some sort of a 
>>> change.
>>> If a service does not indicate a change of state (i.e., if it does 
>>> not have i/e) then how can someone who discovers the service use it 
>>> (say for composition). Something does change when the service is 
>>> executed but the service does not reveal it. I would like to draw an 
>>> analogy between such services with methods that have return type 
>>> "void". Take the example of a program that implements a counter. The 
>>> increment method in this program returns void after incrementing the 
>>> counter. I further name the method foo. If I advertise this method 
>>> as a web service how will one use it since he/she has no idea about 
>>> its internal workings. But if I return a message (add an 
>>> effect/output) that says "Counter_Incremented" then won't it be much 
>>> easier to comprehend what the service does (assuming there is a 
>>> Genie that maps Counter_Incremented to an my concept of counter 
>>> increment)..
>>> What I make out of this is that as long as I don't provide an output 
>>> or effect, only I, as the writer of the program can use it. By 
>>> describing the effect, I describe the service to the extent that 
>>> someone else might be able to use it.
>>> Do I make any sense or have I completely lost it.
>>>
>>> mithun
>>>
>>>
>>
>> -- 
>> >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
>> Monika Solanki
>> De Montfort University
>> Software Technology Research Laboratory
>> Hawthorn building, H00.18
>> The Gateway.
>> Leicester LE1 9BH, UK
>>
>> phone: +44 (0)116 250 6170 intern: 6170
>> email: monika@dmu.ac.uk <mailto:monika@dmu.ac.uk>
>> web: http://www.cse.dmu.ac.uk/~monika/ 
>> <http://www.cse.dmu.ac.uk/%7Emonika/>
>> >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
>> "NOTE: The information transmitted is intended only for the person or 
>> entity to which it is addressed and may contain confidential and/or 
>> privileged material. Any review, retransmission, dissemination or 
>> other use of, or taking of any action in reliance upon this 
>> information by persons or entities other than the intended recipient 
>> is prohibited. If you received this in error, please contact the 
>> sender and delete the material from any computer"
>>
>>
>
>
> _________________________________________________________________
> Add photos to your e-mail with MSN 8. Get 2 months FREE*.  
> http://join.msn.com/?page=features/featuredemail
>

-- 
 >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
Monika Solanki
De Montfort University
Software Technology Research Laboratory
Hawthorn building, H00.18
The Gateway.
Leicester LE1 9BH, UK

phone: +44 (0)116 250 6170 intern: 6170
email: monika@dmu.ac.uk <mailto:monika@dmu.ac.uk>
web: http://www.cse.dmu.ac.uk/~monika/ 
<http://www.cse.dmu.ac.uk/%7Emonika/>
 >**<>**<>**<>**<>**<>**<>**<>**<>**<>**<
"NOTE: The information transmitted is intended only for the person or 
entity to which it is addressed and may contain confidential and/or 
privileged material. Any review, retransmission, dissemination or other 
use of, or taking of any action in reliance upon this information by 
persons or entities other than the intended recipient is prohibited. If 
you received this in error, please contact the sender and delete the 
material from any computer"